PostgreSQL Database Server

Database .NET v33 is an innovative, powerful and intuitive multiple database management tool. With it you can easily and intuitive manage your PostgreSQL databases. (Free for non-commercial and a single executable file without installation) Major ... [More] New features from version 32.7 to 33.6: Added support for PostgreSQL 14.1+ Added Bulk Insert mode support for Data Import Added Table size information for Object Explorer Added Custom Database Type Tab Colors support Added Filtering Objects support for All Database types Improved performance of AutoComplete and IntelliSense Improved performance of Batch Insert mode Improved user experience and user interface Improved Asynchronous Processing Improved Data Export and Import Improved Data Browser and Editor Improved SQL Editor Improved Code Manager Performance improvements Updated Npgsql.dll to 5.0.11 Updated the target .NET Framework to 4.7.2 Compatible with Microsoft Windows 11 ...and more The new version is immediately available for download. [Less]

We are excited to announce that pgDay Paris is back for 2022 – live and in person on March 24! That’s right – COVID-19 may have stopped us last year, but this year, we’re back and we’re looking forward to seeing you there. Potential speaker? Got ... [More] an idea for a presentation? We’re now accepting proposals for talks 45 minutes in length, on any PostgreSQL-related topic. Check out our past conferences to get some ideas if you think you might want to give a talk but don’t know where to start. Calls for Papers end on December 31, 2021, and will be evaluated by the selection committee, made up of Carole ARNAUD (Dalibo), Vik FEARING (EDB), and Katie McMILLAN (Snap360). Potential sponsor? If you would like to sponsor pgDay Paris 2022, please visit our sponsorship page to learn more. We welcome your interest and thank you for it. Potential attendee? Registration is now open for anyone wishing to register for the conference. If you’ve attended pgDay Paris before, you’ll know it’s an inclusive, fun event that focuses on making connections – between ideas and between people. For those of you who know how great our event is and want to sign up now, without the schedule yet available, we have a special BLIND rate. There are limited BLIND spots available so grab yours now if you are interested. Finally – if you have any questions about being a speaker, a sponsor, or an attendee, contact us via any of the channels available through our Contact Us page. We look forward to seeing you (in person! and in compliance with COVID-19 regulations!) on March 24. [Less]

EMS Software Development (SQLManager.net) is pleased to announce the new major version of DB Comparer for PostgreSQL - the powerful tool for comparing PostgreSQL databases and discovering differences in their structure. You can download DB Comparer ... [More] for PostgreSQL via the following link What's new in DB Comparer for PostgreSQL 5.0? Support for dark visual scheme added. Added support for SSL connections Work with objects filter considerably improved. Support for Unicode database names added. Excluded objects are saved to the template correctly now. Support of Ed25519 keys implemented for SSH connection. Functions were not processed on analyzing renamed objects. Fixed now. Script for partition tables with different columns is now generated correctly. Schemas with all subobjects can be excluded from the comparison. Many other fixes and improvements. We hope you'll enjoy working with our PostgreSQL tools. [Less]

PGConf NYC 2021 is this Thursday and Friday! That means registration is closing since the conference will be starting! The first community PostgreSQL conference in North America in many months is in New York City this Thursday and Friday! PGConf ... [More] NYC is a non-profit, community-run and PostgreSQL community recognized conference being run by the United States PostgreSQL Association (PgUS). Don't wait any longer to register for this great event happening right in downtown New York City! PGConf NYC delivers two days packed with presentations about PostgreSQL and related technologies, as well as the usual hallway and social track. PGConf NYC is being held December 2nd and 3rd, 2021 in New York City. Registration Follow this link to register for the conference: https://2021.pgconf.nyc/tickets/ Schedule The PGConf NYC 2021 schedule is available here: https://postgresql.us/events/pgconfnyc2021/schedule/ Our talk selection committee, comprised of 5 individuals from 5 different companies, chose these talks as the best of the over 100 sessions which were submitted this year and laid out a great schedule for you! Details of our operations, talk selection committees, policies, and who should attend PGConf NYC is available here: https://2021.pgconf.nyc/about/. Venue Our Venue this year is the fantastic New York Marriott Downtown: https://2021.pgconf.nyc/venue/ Sponsors & Sponsorship As always, we wouldn't be able to put on these great events without the support of our sponsors. This year we are pleased to be able to recognize our Platinum sponsors: EnterpriseDB Corporation - https://www.enterprisedb.com/ Percona, LLC - https://www.percona.com/ Timescale, Inc. - https://www.timescale.com/ and our Gold sponsors: CYBERTEC PostgreSQL International GmbH - https://www.cybertec-postgresql.com Team Cymru - https://team-cymru.com/ Crunchy Data - https://www.crunchydata.com Be sure to check out our site to see all of our sponsors: https://2021.pgconf.nyc/sponsors/ Sponsorship opportunities are still available! Please visit https://2021.pgconf.nyc/becomesponsor/ to review our prospectus. Contact Us Finally, for frequent updates and information related to our conference, please follow our Twitter account: https://twitter.com/PGConfNYC Any questions? Please contact us at [email protected] and we'll be happy to assist. We look forward to seeing everyone in New York City! https://2021.pgconf.nyc/ [Less]

We’re pleased to announce an English version of the “Transition guide to PostgreSQL”. This aims to answer questions from project owners and management about implementing PostgreSQL in place of a commercial solution. The English guide is now ... [More] available on GitHub and contributions are very welcome. It was translated from the French document "Guide de transition à PostgreSQL", which originated from opensource workgroups within French ministries (Mimprod, SILL) and was updated by PGGTIE in 2019. A previous version of this document was also translated into Russian in 2015 by PostgreSQL contributors I. Panchenko and O. Bartunov. The English guide is also being released under the PostgreSQL license, as a thank you to the community. [Less]

PostgreSQL Weekly News - November 28, 2021 Person of the week PostgreSQL Jobs for November https://archives.postgresql.org/pgsql-jobs/2021-11/ PostgreSQL Local Nordic PGDay 2022 will be held in Helsinki, Finland at the Hilton Helsinki Strand Hotel ... [More] on March 22, 2022. The CfP is open through December 31, 2021 here PostgreSQL in the News Planet PostgreSQL: https://planet.postgresql.org/ PostgreSQL Weekly News is brought to you this week by David Fetter Submit news and announcements by Sunday at 3:00pm PST8PDT to [email protected]. Applied Patches Peter Geoghegan pushed: Remove lazy_scan_heap parallel VACUUM comment block. This doesn't belong next to very high level discussion of the tasks that lazy_scan_heap performs. There is already a similar, longer comment block at the top of vacuumlazy.c that mentions lazy_scan_heap directly. https://git.postgresql.org/pg/commitdiff/97f5aef609ce51422934b7dbdba599a7de4dbafd Go back to considering HOT on pages marked full. Commit 2fd8685e7f simplified the checking of modified attributes that takes place within heap_update(). This included a micro-optimization affecting pages marked PD_PAGE_FULL: don't even try to use HOT to save a few cycles on determining HOT safety. The assumption was that it won't work out this time around, since it can't have worked out last time around. Remove the micro-optimization. It could only ever save cycles that are consumed by the vast majority of heap_update() calls, which hardly seems worth the added complexity. It also seems quite possible that there are workloads that will do worse over time by repeated application of the micro-optimization, despite saving some cycles on average, in the short term. Author: Peter Geoghegan [email protected] Reviewed-By: Álvaro Herrera [email protected] Discussion: https://postgr.es/m/CAH2-WznU1L3+DMPr1F7o2eJBT7=3bAJoY6ZkWABAxNt+-afyTA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1a6f5a0e876306293fda697e7820b404d5b93693 Update high level vacuumlazy.c comments. Update vacuumlazy.c file header comments (as well as comments above the lazy_scan_heap function) that were largely written before the introduction of the HOT optimization, when lazy_scan_heap did far less, and didn't actually prune during its initial heap pass. Since lazy_scan_heap now outsources far more work to lower level functions, it makes sense to introduce the function by talking about the high level invariant that dictates the order in which each phase takes place. Also deemphasize the case where we run out of memory for TIDs, since delaying that discussion makes it easier to talk about issues of central importance. Finally, remove discussion of parallel VACUUM from header comments. These don't add much, and are in the wrong place. https://git.postgresql.org/pg/commitdiff/12b5ade9023f3ecaddcbc423a22dc284c91c79f6 vacuumlazy.c: prefer the term "cleanup lock". The term "super-exclusive lock" is an acceptable synonym of "cleanup lock". Even still, switching from one term to the other in the same file is confusing. Standardize on "cleanup lock" within vacuumlazy.c. Per a complaint from Andres Freund. https://git.postgresql.org/pg/commitdiff/276db875d4f9be2911582f367596d444d6986c77 Fujii Masao pushed: Report wait events for local shell commands like archive_command. This commit introduces new wait events for archive_command, archive_cleanup_command, restore_command and recovery_end_command. Author: Fujii Masao Reviewed-by: Bharath Rupireddy, Michael Paquier Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/1b06d7bac901e5fd20bba597188bae2882bf954b Peter Eisentraut pushed: Add ABI extra field to fmgr magic block. This allows derived products to intentionally make their fmgr ABI incompatible, with a clean error message. Discussion: https://www.postgresql.org/message-id/flat/55215fda-db31-a045-d6b7-d6f2d2dc9920%40enterprisedb.com https://git.postgresql.org/pg/commitdiff/d6d1dfcc99e3dd6e70e2a7024924e491bb7a9670 Fix incorrect format placeholders. Also choose better types for the underlying variables to make this more consistent. https://git.postgresql.org/pg/commitdiff/fb5961fd13b1262df280e400645bdf4ed192f058 Remove unneeded Python includes. Inluding and has not been necessary since Python 2.4, since they are included via . Morever, is being removed in Python 3.11. So remove these includes. Reviewed-by: Tom Lane [email protected] Discussion: https://www.postgresql.org/message-id/flat/84884.1637723223%40sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/99e4d24a9d77e7bb87e15b318e96dc36651a7da2 Update comments. Various places wanted to point out that tuple descriptors don't contain the variable-length fields of pg_attribute. This started when attacl was added, but more fields have been added since, and these comments haven't been kept up to date consistently. Reword so that the purpose is clearer and we don't have to keep updating them. https://git.postgresql.org/pg/commitdiff/36cb5e7c512bef394c9288786c62ef0eb1e891ba Álvaro Herrera pushed: Add missing words in comment. Reported by Zhihong Yu. Discussion: https://postgr.es/m/CALNJ-vR6uZivg_XkB1zKjEXeyZDEgoYanFXB-++1kBT9yZQoUw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/67385544ce672a9a53cfd51b39c1ff9048d65585 autovacuum: Improve wording in a couple places. A few strings (one WARNING and some memory context names) in the autovacuum code were written in a world where "worker" had no other possible meaning than "autovacuum worker", but that's long time gone. Be more specific about it. Also, change the WARNING from elog() to ereport(), to add translability. Author: Bharath Rupireddy [email protected] Reviewed-by: Nathan Bossart [email protected] Reviewed-by: Justin Pryzby [email protected] Reviewed-by: Kyotaro Horiguchi [email protected] Reviewed-by: Dilip Kumar [email protected] Reviewed-by: Masahiko Sawada [email protected] Discussion: https://postgr.es/m/CALj2ACX2UHp76dqdoZq92a7v4APFuV5wJQ+AUrb+2HURrKN=NQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/042412879e35791a65509f2786b4954a273466e5 Be more specific about OOM in XLogReaderAllocate. A couple of spots can benefit from an added errdetail(), which matches what we were already doing in other places; and those that cannot withstand errdetail() can get a more descriptive primary message. Author: Bharath Rupireddy [email protected] Reviewed-by: Daniel Gustafsson [email protected] Reviewed-by: Julien Rouhaud [email protected] Discussion: https://postgr.es/m/CALj2ACV+cX1eM03GfcA=ZMLXh5fSn1X1auJLz3yuS1duPSb9QA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/2fed48f48f7f2f7a6d6f6d020f046efe3c249828 Fix determination of broken LSN in OVERWRITTEN_CONTRECORD. In commit ff9f111bce24 I mixed up inconsistent definitions of the LSN of the first record in a page, when the previous record ends exactly at the page boundary. The correct LSN is adjusted to skip the WAL page header; I failed to use that when setting XLogReaderState->overwrittenRecPtr, so at WAL replay time VerifyOverwriteContrecord would refuse to let replay continue past that record. Backpatch to 10. 9.6 also contains this bug, but it's no longer being maintained. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/44bd3ed332d6ad3207f38b3b6deb6083f0baddf5 Document units for max_slot_wal_keep_size. The doc blurb failed to mention units, as well as lacking the point about changeability. Backpatch to 13. Reviewed-by: Kyotaro Horiguchi [email protected] Reported by: [email protected] Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/013bb6c8c0b5b0ac7948d7126685008505b3aa58 Copy-edit vacuuumdb --analyze-in-stages doc blurb. I had made a few typos, and Nikolai Berkoff made a wording change suggestion. Discussion: https://postgr.es/m/VMwe7-sGegrQPQ7fJjSCdsEbESKeJFOb6G4DFxxNrf45I7DzHio7sNUH88wWRMnAy5a5G0-FB31dxPM47ldigW6WdiCPncHgqO9bNl6F240=@pm.me https://git.postgresql.org/pg/commitdiff/dd484c97f55be8336fcb41470768c5b8ae347d13 Harden be-gssapi-common.h for headerscheck. Surround the contents with a test that the feature is enabled by configure, to silence header checking tools on systems without GSSAPI installed. Backpatch to 12, where the file appeared. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/f744519326e1ce4774d0966f7848601a8327eeaa Tom Lane pushed: Probe $PROVE not $PERL while checking for modules needed by TAP tests. Normally "prove" and "perl" come from the same Perl installation, but we support the case where they don't (mainly because the MSys buildfarm animals need this). In that case, AX_PROG_PERL_MODULES is completely the wrong thing to use, because it's checking what "perl" has. Instead, make a little TAP test script including the required modules, and run that under "prove". We don't need ax_prog_perl_modules.m4 at all after this change, so remove it. Back-patch to all supported branches, for the buildfarm's benefit. (In v10, this also back-patches the effects of commit 264eb03aa.) Andrew Dunstan and Tom Lane, per an observation by Noah Misch Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/c4fe3199a6d65212537a59eb0d7e6fad22b9e903 Fix pg_dump --inserts mode for generated columns with dropped columns. If a table contains a generated column that's preceded by a dropped column, dumpTableData_insert failed to account for the dropped column, and would emit DEFAULT placeholder(s) in the wrong column(s). This resulted in failures at restore time. The default COPY code path did not have this bug, likely explaining why it wasn't noticed sooner. While we're fixing this, we can be a little smarter about the situation: (1) avoid unnecessarily fetching the values of generated columns, (2) omit generated columns from the output, too, if we're using --column-inserts. While these modes aren't expected to be as high-performance as the COPY path, we might as well be as efficient as we can; it doesn't add much complexity. Per report from Дмитрий Иванов. Back-patch to v12 where generated columns came in. Discussion: https://postgr.es/m/CAPL5KHrkBniyQt5e1rafm5DdXvbgiiqfEQEJ9GjtVzN71Jj5pA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/0b126c6a4b00972f2f3533e1718bbe297e2851c2 Pacify perlcritic. Per buildfarm. https://git.postgresql.org/pg/commitdiff/db3a660c6327a6df81a55c4aa86e6c0837ecd505 Adjust pg_dump's priority ordering for casts. When a stored expression depends on a user-defined cast, the backend records the dependency as being on the cast's implementation function --- or indeed, if there's no cast function involved but just RelabelType or CoerceViaIO, no dependency is recorded at all. This is problematic for pg_dump, which is at risk of dumping things in the wrong order leading to restore failures. Given the lack of previous reports, the risk isn't that high, but it can be demonstrated if the cast is used in some view whose rowtype is then used as an input or result type for some other function. (That results in the view getting hoisted into the functions portion of the dump, ahead of the cast.) A logically bulletproof fix for this would require including the cast's OID in the parsed form of the expression, whence it could be extracted by dependency.c, and then the stored dependency would force pg_dump to do the right thing. Such a change would be fairly invasive, and certainly not back-patchable. Moreover, since we'd prefer that an expression using cast syntax be equal() to one doing the same thing by explicit function call, the cast OID field would have to have special ignored-by-comparisons semantics, making things messy. So, let's instead fix this by a very simple hack in pg_dump: change the object-type priority order so that casts are initially sorted before functions, immediately after types. This fixes the problem in a fairly direct way for casts that have no implementation function. For those that do, the implementation function will be hoisted to just before the cast by the dependency sorting step, so that we still have a valid dump order. (I'm not sure that this provides a full guarantee of no problems; but since it's been like this for many years without any previous reports, this is probably enough to fix it in practice.) Per report from Дмитрий Иванов. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAPL5KHoGa3uvyKp6z6m48LwCnTsK+LRQ_mcA4uKGfqAVSEjV_A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/b55f2b6926556115155930c4b2d006c173f45e65 Doc: improve documentation about nextval()/setval(). Clarify that the results of nextval and setval are not guaranteed persistent until the calling transaction commits. Some people seem to have drawn the opposite conclusion from the statement that these functions are never rolled back, so re-word to avoid saying it quite that way. Discussion: https://postgr.es/m/CAKU4AWohO=NfM-4KiZWvdc+z3c1C9FrUBR6xnReFJ6sfy0i=Lw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/4ac452e2285da347c75f5960ae211e183a87b57b Michaël Paquier pushed: Add SQL functions to monitor the directory contents of replication slots. This commit adds a set of functions able to look at the contents of various paths related to replication slots: - pg_ls_logicalsnapdir, for pg_logical/snapshots/ - pg_ls_logicalmapdir, for pg_logical/mappings/ - pg_ls_replslotdir, for pg_replslot// These are intended to be used by monitoring tools. Unlike pg_ls_dir(), execution permission can be granted to non-superusers. Roles members of pg_monitor gain have access to those functions. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Nathan Bossart, Justin Pryzby Discussion: https://postgr.es/m/CALj2ACWsfizZjMN6bzzdxOk1ADQQeSw8HhEjhmVXn_Pu+7VzLw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1922d7c6e1a74178bd2f1d5aa5a6ab921b3fcd34 Add support for Visual Studio 2022 in build scripts. Documentation and any code paths related to VS are updated to keep the whole consistent. Similarly to 2017 and 2019, the version of VS and the version of nmake that we use to determine which code paths to use for the build are still inconsistent in their own way. Backpatch down to 10, so as buildfarm members are able to use this new version of Visual Studio on all the stable branches supported. Author: Hans Buschmann Discussion: https://postgr.es/m/[email protected] Backpatch-through: 10 https://git.postgresql.org/pg/commitdiff/b2265d305d81b0c1a2cec6c5b66a190a9e69e853 Remove useless LZ4 system call on failure when writing file header. If an error occurs when writing the LZ4 file header, LZ4F_compressEnd() was called in the error code path of write(), followed by LZ4F_freeCompressionContext() to finish the cleanup. The code as-is was not broken, but the LZ4F_compressEnd() proves to not be necessary as there are no contents to flush at this stage, so remove it. Per gripe from Jeevan Ladhe and Robert Haas. Discussion: https://postgr.es/m/CAOgcT0PE33wbD7giAT1OSkNJt=p-vu8huq++qh=ny9O=SCP5aA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f79962d8264b8d205ce45a8aa11d1b37f9592a81 Fix fstat() emulation on Windows with standard streams. The emulation of fstat() in win32stat.c caused two issues with the existing in-core callers, failing on EINVAL when using a stream as argument: - psql's \copy would crash when using a stream. - pg_recvlogical would fail with -f -. The tests in copyselect.sql from the main test suite covers the first case, and there is a TAP test for the second case. However, in both cases, as the standard streams are always redirected, automated tests did not notice those issues, requiring a terminal on Windows to be reproducible. This issue has been introduced in bed9075, and the origin of the problem is that GetFileInformationByHandle() does not work directly on streams, so this commit adds an extra code path to emulate and return a set of stats that match best with the reality. Note that redirected streams rely on handles that can be queried with GetFileInformationByHandle(), but we can rely on GetFinalPathNameByHandleA() to detect this case. Author: Dmitry Koval, Juan José Santamaría Flecha Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14 https://git.postgresql.org/pg/commitdiff/10260c794b211117a56ee2eb2deacf609bcca25f Block ALTER TABLE .. DROP NOT NULL on columns in replica identity index. Replica identities that depend directly on an index rely on a set of properties, one of them being that all the columns defined in this index have to be marked as NOT NULL. There was a hole in the logic with ALTER TABLE DROP NOT NULL, where it was possible to remove the NOT NULL property of a column part of an index used as replica identity, so block it to avoid problems with logical decoding down the road. The same check was already done columns part of a primary key, so the fix is straight-forward. Author: Haiying Tang, Hou Zhijie Reviewed-by: Dilip Kumar, Michael Paquier Discussion: https://postgr.es/m/OS0PR01MB6113338C102BEE8B2FFC5BD9FB619@OS0PR01MB6113.jpnprd01.prod.outlook.com Backpatch-through: 10 https://git.postgresql.org/pg/commitdiff/f0d43947a1b0c30f0bf2c117cd78bf95a3161268 David Rowley pushed: Allow Memoize to operate in binary comparison mode. Memoize would always use the hash equality operator for the cache key types to determine if the current set of parameters were the same as some previously cached set. Certain types such as floating points where -0.0 and +0.0 differ in their binary representation but are classed as equal by the hash equality operator may cause problems as unless the join uses the same operator it's possible that whichever join operator is being used would be able to distinguish the two values. In which case we may accidentally return in the incorrect rows out of the cache. To fix this here we add a binary mode to Memoize to allow it to the current set of parameters to previously cached values by comparing bit-by-bit rather than logically using the hash equality operator. This binary mode is always used for LATERAL joins and it's used for normal joins when any of the join operators are not hashable. Reported-by: Tom Lane Author: David Rowley Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14, where Memoize was added https://git.postgresql.org/pg/commitdiff/e502150f7d0be41e3c8784be007fa871a32d8a7f Flush Memoize cache when non-key parameters change. It's possible that a subplan below a Memoize node contains a parameter from above the Memoize node. If this parameter changes then cache entries may become out-dated due to the new parameter value. Previously Memoize was mistakenly not aware of this. We fix this here by flushing the cache whenever a parameter that's not part of the cache key changes. Bug: #17213 Reported by: Elvis Pranskevichus Author: David Rowley Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14, where Memoize was added https://git.postgresql.org/pg/commitdiff/1050048a315790a505465bfcceb26eaf8dbc7e2e Revert "Flush Memoize cache when non-key parameters change". This reverts commit 1050048a315790a505465bfcceb26eaf8dbc7e2e. https://git.postgresql.org/pg/commitdiff/dad20ad4709f602b4827a1ab2b0e715f36c548c3 Flush Memoize cache when non-key parameters change, take 2. It's possible that a subplan below a Memoize node contains a parameter from above the Memoize node. If this parameter changes then cache entries may become out-dated due to the new parameter value. Previously Memoize was mistakenly not aware of this. We fix this here by flushing the cache whenever a parameter that's not part of the cache key changes. Bug: #17213 Reported by: Elvis Pranskevichus Author: David Rowley Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14, where Memoize was added https://git.postgresql.org/pg/commitdiff/411137a429210e432f923264a8e313a9872910ca Amit Kapila pushed: Rename SnapBuild* macros in slot.c. Same macro names for SnapBuildOnDiskNotChecksummedSize and SnapBuildOnDiskChecksummedSize are being used in slot.c and snapbuild.c. This patch renames them, in slot.c, to ReplicationSlotOnDiskNotChecksummedSize and ReplicationSlotOnDiskChecksummedSize similar to the other macros. This makes all macro names look consistent in slot.c. Author: Bharath Rupireddy Discussion: https://postgr.es/m/CALj2ACVZo-piDGzBOJRY4ob=_goFR6t9DhZMDMjJWN7LQs34Aw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/875e02c2dff34f1bc9f3832a4f83c34bf300eb9f Robert Haas pushed: Fix corner-case failure to detect improper timeline switch. rescanLatestTimeLine() contains a guard against switching to a timeline that forked off from the current one prior to the current recovery point, but that guard does not work if the timeline switch occurs before the first WAL recod (which must be the checkpoint record) is read. Without this patch, an improper timeline switch is therefore possible in such cases. This happens because rescanLatestTimeLine() relies on the global variable EndRecPtr to understand the current position of WAL replay. However, EndRecPtr at this point in the code contains the endpoint of the last-replayed record, not the startpoint or endpoint of the record being replayed now. Thus, before any records have been replayed, it's zero, which causes the sanity check to always pass. To fix, pass down the correct timeline explicitly. The EndRecPtr value we want is the one from the xlogreader, which will be the starting position of the record we're about to try to read, rather than the global variable, which is the ending position of the last record we successfully read. They're usually the same, but not in the corner case described here. No back-patch, because in v14 and earlier branhes, we were using the wrong TLI here as well as the wrong LSN. In master, that was fixed by commit 4a92a1c3d1c361ffb031ed05bf65b801241d7cdd, but that and it's prerequisite patches are too invasive to back-patch for such a minor issue. Patch by me, reviewed by Amul Sul. Discussion: http://postgr.es/m/CA+Tgmoao96EuNeSPd+hspRKcsCddu=b1h-QNRuKfY8VmfNQdfg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e7ea2fa342b008ae97e794b0fa2ee538ddcee3b7 xlog.c: Remove global variables ReadRecPtr and EndRecPtr. In most places, the variables necessarily store the same value as the eponymous members of the XLogReaderState that we use during WAL replay, because ReadRecord() assigns the values from the structure members to the global variables just after XLogReadRecord() returns. However, XLogBeginRead() adjusts the structure members but not the global variables, so after XLogBeginRead() and before the completion of XLogReadRecord() the values can differ. Otherwise, they must be identical. According to my analysis, the only place where either variable is referenced at a point where it might not have the same value as the structure member is the refrence to EndRecPtr within XLogPageRead. Therefore, at every other place where we are using the global variable, we can just switch to using the structure member instead, and remove the global variable. However, we can, and in fact should, do this in XLogPageRead() as well, because at that point in the code, the global variable will actually store the start of the record we want to read - either because it's where the last WAL record ended, or because the read position has been changed using XLogBeginRead since the last record was read. The structure member, on the other hand, will already have been updated to point to the end of the record we just read. Elsewhere, the latter is what we use as an argument to emode_for_corrupt_record(), so we should do the same here. This part of the patch is perhaps a bug fix, but I don't think it has any important consequences, so no back-patch. The point here is just to continue to whittle down the entirely excessive use of global variables in xlog.c. Discussion: http://postgr.es/m/CA+Tgmoao96EuNeSPd+hspRKcsCddu=b1h-QNRuKfY8VmfNQdfg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/d2ddfa681db27a138acb63c8defa8cc6fa588922 Heikki Linnakangas pushed: Fix missing space in docs. Author: Japin Li Discussion: https://www.postgresql.org/message-id/MEYP282MB1669C36E5F733C2EFBDCB80BB6619@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM https://git.postgresql.org/pg/commitdiff/373e55218972f840ad29cd8a4dabe4b17e98d28b Andres Freund pushed: Replace straggling uses of ReadRecPtr/EndRecPtr. d2ddfa681db removed ReadRecPtr/EndRecPtr, but two uses within an #ifdef WAL_DEBUG escaped. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/3030903dfefb314ebb575834702904dc008eb5ca Daniel Gustafsson pushed: Fix GRANTED BY support in REVOKE ROLE statements. Commit 6aaaa76bb added support for the GRANTED BY clause in GRANT and REVOKE statements, but missed adding support for checking the role in the REVOKE ROLE case. Fix by checking that the parsed role matches the CURRENT_ROLE/CURRENT_USER requirement, and also add some tests for it. Backpatch to v14 where GRANTED BY support was introduced. Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14 https://git.postgresql.org/pg/commitdiff/b2a459edfe645747744402f23de041e9c0a3cd93 Add test for REVOKE ADMIN OPTION. The REVOKE ADMIN OPTION FOR syntax didn't have ample test coverage. Fix by adding coverage in the privileges test suite. Author: Mark Dilger [email protected] Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/4597fd78d6dea2235cb948ea036c2d61057c415c [Less]

PostgreSQL Weekly News - November 21, 2021 Nordic PGDay 2022 will be held in Helsinki, Finland at the Hilton Helsinki Strand Hotel on March 22, 2022. The CfP is open through December 31, 2021 here PostgreSQL Product News PGroonga 2.3.4 a full text ... [More] search platform for all languages, released. Pgpool-II 4.2.6, 4.1.9, 4.0.16, 3.7.21 and 3.6.28, a connection pooler and statement replication system for PostgreSQL, re l ea s ed. Ora2Pg 23.0, a tool for migrating Oracle databases to PostgreSQL, released. https://github.com/darold/ora2pg/blob/master/changelog BigAnimal, a managed PostgreSQL database on Azure, released. pgAdmin4 6.2, a web- and native GUI control center for PostgreSQL, released. PostgreSQL Jobs for November https://archives.postgresql.org/pgsql-jobs/2021-11/ PostgreSQL in the News Planet PostgreSQL: https://planet.postgresql.org/ PostgreSQL Weekly News is brought to you this week by David Fetter Submit news and announcements by Sunday at 3:00pm PST8PDT to [email protected]. Applied Patches Robert Haas pushed: Fix thinko in bbsink_throttle_manifest_contents. Report and diagnosis by Dmitry Dolgov. Discussion: http://postgr.es/m/20211115162641.dmo6l32fklh64gnw@localhost https://git.postgresql.org/pg/commitdiff/1b098da2009362e0e8d9a1d0a6aac2f2bd3e2f0b Move InitXLogInsert() call from InitXLOGAccess() to BaseInit(). At present, there is an undocumented coding rule that you must call RecoveryInProgress(), or do something else that results in a call to InitXLogInsert(), before trying to write WAL. Otherwise, the WAL construction buffers won't be initialized, resulting in failures. Since it's not good to rely on a status inquiry function like RecoveryInProgress() having the side effect of initializing critical data structures, instead do the initialization eariler, when the backend first starts up. Patch by me. Reviewed by Nathan Bossart and Michael Paquier. Discussion: http://postgr.es/m/CA+TgmoY7b65qRjzHN_tWUk8B4sJqk1vj1d31uepVzmgPnZKeLg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e51c46991f0ee99cca222305619dee5543a1290a Amit Kapila pushed: Invalidate relcache when changing REPLICA IDENTITY index. When changing REPLICA IDENTITY INDEX to another one, the target table's relcache was not being invalidated. This leads to skipping update/delete operations during apply on the subscriber side as the columns required to search corresponding rows won't get logged. Author: Tang Haiying, Hou Zhijie Reviewed-by: Euler Taveira, Amit Kapila Backpatch-through: 10 Discussion: https://postgr.es/m/OS0PR01MB61133CA11630DAE45BC6AD95FB939@OS0PR01MB6113.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/354a1f8d220fbbb07b0ded32c5ade72646afb801 Fix parallel operations that prevent oldest xmin from advancing. While determining xid horizons, we skip over backends that are running Vacuum. We also ignore Create Index Concurrently, or Reindex Concurrently for the purposes of computing Xmin for Vacuum. But we were not setting the flags corresponding to these operations when they are performed in parallel which was preventing Xid horizon from advancing. The optimization related to skipping Create Index Concurrently, or Reindex Concurrently operations was implemented in PG-14 but the fix is the same for the Parallel Vacuum as well so back-patched till PG-13. Author: Masahiko Sawada Reviewed-by: Amit Kapila Backpatch-through: 13 Discussion: https://postgr.es/m/CAD21AoCLQqgM1sXh9BrDFq0uzd3RBFKi=Vfo6cjjKODm0Onr5w@mail.gmail.com https://git.postgresql.org/pg/commitdiff/0f0cfb494004befb0f6e89d3129347869420c509 Álvaro Herrera pushed: Fix headerscheck failure in replication/worker_internal.h. Broken by 31c389d8de91 https://git.postgresql.org/pg/commitdiff/ad26ee28250c4cd357a7420161a2be321c3dd536 Michaël Paquier pushed: Remove global variable "LastRec" in xlog.c. This variable is used only by StartupXLOG() now, so let's make it local to simplify the code. Author: Amul Sul Reviewed-by: Tom Lane, Michael Paquier Discussion: https://postgr.es/m/CAAJ_b96Qd023itERBRN9Z7P2saNDT3CYvGuMO8RXwndVNN6z7g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f975fc3a3542005ed0dd689bdb5bd9ed4e1f4d52 Add table to regression tests for binary-compatibility checks in pg_upgrade. This commit adds to the main regression test suite a table with all the in-core data types (some exceptions apply). This table is not dropped, so as pg_upgrade would be able to check the binary compatibility of the types tracked in the table. If a new type is added in core, this part of the tests would need a refresh but the tests are designed to fail if that were to happen. As this is useful for upgrades and that these rely on the objects created in the regression test suite of the old version upgraded from, a backpatch down to 12 is done, which is the last point where a binary incompatible change has been done (7c15cef). This will hopefully be enough to find out if something gets broken during the development of a new version of Postgres, so as it is possible to take actions in pg_upgrade itself in this case (like 0ccfc28 for sql_identifier). An area that is not covered yet is related to external modules, which may create their own types. The testing infrastructure of pg_upgrade is not integrated yet with the external modules stored in core (src/test/modules/ or contrib/, all use the same database name for their tests so there would be an overlap). This could be improved in the future. Author: Justin Pryzby Reviewed-by: Jacob Champion, Peter Eisentraut, Tom Lane, Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 12 https://git.postgresql.org/pg/commitdiff/835bcba8b8d72a00cecc5431b67e70bbea93f947 Fix quoting of ACL item in table for upgrade binary compatibility checks. Per buildfarm member prion, that runs the regression tests under a role name that uses a hyphen. Issue introduced by 835bcba. Discussion: https://postgr.es/m/[email protected] Backpatch-through: 12 https://git.postgresql.org/pg/commitdiff/ac1c7458b17633d1e53a01393d12774c10cb6a91 Improve psql tab completion for transforms, domains and sequences. The following improvements are done: - Addition of some tab completion for CREATE DOMAIN. - Addition of some tab completion for CREATE TRANSFORM. - Addition of type completion for CREATE SEQUENCE AS. Author: Ken Kato Reviewed-by: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/0cd6d3b3c5aeac81903aa7de92e406f8567898a2 Peter Eisentraut pushed: Fix incorrect format placeholders. https://git.postgresql.org/pg/commitdiff/303d4eb1c548f1d0821e168a6e7c7e9bd02c8088 Daniel Gustafsson pushed: Doc: add see-also references to CREATE PUBLICATION. The "See also" section on the reference page for CREATE PUBLICATION didn't match the cross references on CREATE SUBSCRIPTION and their ALTER counterparts. Fixed by adding an xref to the CREATE and ALTER SUBSCRIPTION pages. Backpatch down to v10 where CREATE PUBLICATION was introduced. Author: Peter Smith [email protected] Reviewed-by: Masahiko Sawada [email protected] Discussion: https://postgr.es/m/CAHut+PvGWd3-Ktn96c-z6uq-8TGVVP=TPOkEovkEfntoo2mRhw@mail.gmail.com Backpatch-through: 10 https://git.postgresql.org/pg/commitdiff/3374a87b62cc553fa65f57ade019dcf3104ae639 Improve publication error messages. Commit 81d5995b4b introduced more fine-grained errormessages for incorrect relkinds for publication, while unlogged and temporary tables were reported with using the same message. This provides separate error messages for these types of relpersistence. Author: Bharath Rupireddy [email protected] Reviewed-by: Peter Eisentraut [email protected] Reviewed-by: Jeevan Ladhe [email protected] Reviewed-by: Euler Taveira [email protected] Discussion: https://postgr.es/m/CALj2ACW9S=AswyQHjtO6WMcsergMkCBTtzXGrM8DX26DzfeTLQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/aa12781b0d039d93e1a851ece4bc75c3746cbd43 Tom Lane pushed: Fix display of SQL-standard function's arguments in INSERT/SELECT. If a SQL-standard function body contains an INSERT ... SELECT statement, any function parameters referenced within the SELECT were always printed in $N style, rather than using the parameter name if any. While not strictly incorrect, this wasn't the intention, and it's inconsistent with the way that such parameters would be printed in any other kind of statement. The cause is that the recursion to get_query_def from get_insert_query_def neglected to pass down the context->namespaces list, passing constant NIL instead. This is a very ancient oversight, but AFAICT it had no visible consequences before commit e717a9a18 added an outermost namespace with function parameters. We don't allow INSERT ... SELECT as a sub-query, except in a top-level WITH clause, where it couldn't contain any outer references that might need to access upper namespaces. So although that's arguably a bug, I don't see any point in changing it before v14. In passing, harden the code added to get_parameter by e717a9a18 so that it won't crash if a PARAM_EXTERN Param appears in an unexpected place. Per report from Erki Eessaar. Code fix by me, regression test case by Masahiko Sawada. Discussion: https://postgr.es/m/AM9PR01MB8268347BED344848555167FAFE949@AM9PR01MB8268.eurprd01.prod.exchangelabs.com https://git.postgresql.org/pg/commitdiff/a8d8445a7b2f80f6d0bfe97b19f90bd2cbef8759 Handle close() failures more robustly in pg_dump and pg_basebackup. Coverity complained that applying get_gz_error after a failed gzclose, as we did in one place in pg_basebackup, is unsafe. I think it's right: it's entirely likely that the call is touching freed memory. Change that to inspect errno, as we do for other gzclose calls. Also, be careful to initialize errno to zero immediately before any gzclose() call where we care about the error status. (There are some calls where we don't, because we already failed at some previous step.) This ensures that we don't get a misleadingly irrelevant error code if gzclose() fails in a way that doesn't set errno. We could work harder at that, but it looks to me like all such cases are basically can't-happen if we're not misusing zlib, so it's not worth the extra notational cruft that would be required. Also, fix several places that simply failed to check for close-time errors at all, mostly at some remove from the close or gzclose itself; and one place that did check but didn't bother to report the errno. Back-patch to v12. These mistakes are older than that, but between the frontend logging API changes that happened in v12 and the fact that frontend code can't rely on %m before that, the patch would need substantial revision to work in older branches. It doesn't quite seem worth the trouble given the lack of related field complaints. Patch by me; thanks to Michael Paquier for review. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/3cac2c8caaefc642332e6994ce80032cc7d4cfdf Clean up error handling in pg_basebackup's walmethods.c. The error handling here was a mess, as a result of a fundamentally bad design (relying on errno to keep its value much longer than is safe to assume) as well as a lot of just plain sloppiness, both as to noticing errors at all and as to reporting the correct errno. Moreover, the recent addition of LZ4 compression broke things completely, because liblz4 doesn't use errno to report errors. To improve matters, keep the error state in the DirectoryMethodData or TarMethodData struct, and add a string field so we can handle cases that don't set errno. (The tar methods already had a version of this, but it can be done more efficiently since all these cases use a constant error string.) Make the dir and tar methods handle errors in basically identical ways, which they didn't before. This requires copying errno into the state struct in a lot of places, which is a bit tedious, but it has the virtue that we can get rid of ad-hoc code to save and restore errno in a number of places ... not to mention that it fixes other places that should've saved/restored errno but neglected to. In passing, fix some pointlessly static buffers to be ordinary local variables. There remains an issue about exactly how to handle errors from fsync(), but that seems like material for its own patch. While the LZ4 problems are new, all the rest of this is fixes for old bugs, so backpatch to v10 where walmethods.c was introduced. Patch by me; thanks to Michael Paquier for review. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/248c3a937dd018a72095f407cff727c9f08db0c1 Add a planner support function for starts_with(). This fills in some gaps in planner support for starts_with() and the equivalent ^@ operator: * A condition such as "textcol ^@ constant" can now use a regular btree index, not only an SP-GiST index, so long as the index's collation is C. (This works just like "textcol LIKE 'foo%'".) * "starts_with(textcol, constant)" can be optimized the same as "textcol ^@ constant". * Fixed-prefix LIKE and regex patterns are now more like starts_with() in another way: if you apply one to an SPGiST-indexed column, you'll get an index condition using ^@ rather than two index conditions with >= and <. Per a complaint from Shay Rojansky. Patch by me; thanks to Nathan Bossart for review. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/a148f8bc04b9980f019ea0d4b89311cf0bdc22b7 Provide a variant of simple_prompt() that can be interrupted by ^C. Up to now, you couldn't escape out of psql's \password command by typing control-C (or other local spelling of SIGINT). This is pretty user-unfriendly, so improve it. To do so, we have to modify the functions provided by pg_get_line.c; but we don't want to mess with psql's SIGINT handler setup, so provide an API that lets that handler cause the cancel to occur. This relies on the assumption that we won't do any major harm by longjmp'ing out of fgets(). While that's obviously a little shaky, we've long had the same assumption in the main input loop, and few issues have been reported. psql has some other simple_prompt() calls that could usefully be improved the same way; for now, just deal with \password. Nathan Bossart, minor tweaks by me Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/5f1148224bd78bcf3bf7d916b8fe85dd820c52c6 Use appropriate -Wno-warning switches when compiling bitcode. We use "clang" to compile bitcode files for LLVM inlining. That might be different from the build's main C compiler, so it needs its own set of compiler flags. To simplify configure, we don't bother adding any -W switches to that flag set; there's little need since the main build will show us any warnings. However, if we don't want to see unwanted warnings, we still have to add any -Wno-warning switches we'd normally use with clang. This escaped notice before commit 9ff47ea41, which tried to add -Wno-compound-token-split-by-macro; buildfarm animals using mismatched CC and CLANG still showed those warnings. I'm not sure why we never saw any effects from the lack of -Wno-unused-command-line-argument (maybe that's only activated by -Wall?). clang does not currently support -Wno-format-truncation or -Wno-stringop-truncation, although in the interests of future-proofing and consistency I included tests for those. Back-patch to v11 where we started building bitcode files. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/276517a96484f9e39a7a1095ab39fa76ef1ee8cc Allow psql's other uses of simple_prompt() to be interrupted by ^C. This fills in the work left un-done by 5f1148224. \prompt can be canceled out of now, and so can password prompts issued during \connect. (We don't need to do anything for password prompts issued during startup, because we aren't yet trapping SIGINT at that point.) Nathan Bossart Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/46d665bc26ce57b5afecbc218c8fc3c6848211d8 Fix SP-GiST scan initialization logic for binary-compatible cases. Commit ac9099fc1 rearranged the logic in spgGetCache() that determines the index's attType (nominal input data type) and leafType (actual type stored in leaf index tuples). Turns out this broke things for the case where (a) the actual input data type is different from the nominal type, (b) the opclass's config function leaves leafType defaulted, and (c) the opclass has no "compress" function. (b) caused us to assign the actual input data type as leafType, and then since that's not attType, we complained that a "compress" function is required. For non-polymorphic opclasses, condition (a) arises in binary-compatible cases, such as using SP-GiST text_ops for a varchar column, or using any opclass on a domain over its nominal input type. To fix, use attType for leafType when the index's declared column type is different from but binary-compatible with attType. Do this only in the defaulted-leafType case, to avoid overriding any explicit selection made by the opclass. Per bug #17294 from Ilya Anfimov. Back-patch to v14. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/f4e7ae2b8a67ad6801726553a024a3306716ef80 Doc: update some things relevant to minimum Test::More version. Oversights in commit 405f32fc4. Also, add a tip (discovered the hard way) about getting Test::More 0.98 to pass its regression tests on recent Linux platforms. https://git.postgresql.org/pg/commitdiff/92e70796e91e2f9086fad0156e0e91513e54a66b pg_receivewal, pg_recvlogical: allow canceling initial password prompt. Previously it was impossible to terminate these programs via control-C while they were prompting for a password. We can fix that trivially for their initial password prompts, by moving setup of the SIGINT handler from just before to just after their initial GetConnection() calls. This fix doesn't permit escaping out of later re-prompts, but those should be exceedingly rare, since the user's password or the server's authentication setup would have to have changed meanwhile. We considered applying a fix similar to commit 46d665bc2, but that seemed more complicated than it'd be worth. Moreover, this way is back-patchable, which that wasn't. The misbehavior exists in all supported versions, so back-patch to all. Tom Lane and Nathan Bossart Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/282b6d00abf5cebece6f94c796a4ed807a0176db Andres Freund pushed: Initialize backend status reporting during bootstrap. This allows a later commit to reduce the number of branches in performance sensitive functions during normal running, compared to a very minor saving during bootstrapping. Author: Melanie Plageman [email protected] Reviewed-By: Andres Freund [email protected] Discussion: https://postgr.es/m/CAAKRu_Yeg+vh6SHNEo1+=O7e-BPX35cU0XQM=YwQRnkFyv_y+w@mail.gmail.com https://git.postgresql.org/pg/commitdiff/3b34645678d1a516c148e3e27c26325708e92f6f Andrew Dunstan pushed: Require version 0.98 of Test::More for TAP tests. This means that the subtest feature will be available for use. We expect that this change will make prairiedog go red until it is updated, but other buildfarm animals should be fine. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/405f32fc49609eb94fa39e7b5e7c1fe2bb2b73aa [Less]

What is Pgpool-II? Pgpool-II is a tool to add useful features to PostgreSQL, including: connection pooling load balancing automatic fail over and more. Minor releases Pgpool Global Development Group is pleased to announce the availability of ... [More] following versions of Pgpool-II: 4.2.6 4.1.9 4.0.16 3.7.21 3.6.28 This release includes a vulnerability fix. Please take a look at release notes. You can download the source code and RPMs. [Less]

Having been canceled the past two years due to the COVID-19 pandemic, Nordic PGDay is once again scheduled to be an in-person event for the Nordic PostgreSQL community. The format is like before: a one-day single-track event - packed with great ... [More] content but in a room big enough to ensure desired social distancing. Our call for papers is now open, accepting proposals until the end of the year. We welcome speakers from all parts of the world, all talks will be given in English. Technical details, case studies, good ideas or bad ideas -- all are good ideas for topics. All speakers get free entrance, so it's also a good excuse to come visit Finland! We are also accepting sponsorships starting today. If your company is interested in reaching the Nordic PostgreSQL community then this is a great chance to get high visibility at a reasonable price. Nordic PGDay is a not-for-profit event run by PostgreSQL Europe funded by sponsorships. See our sponsorship page for the available sponsorship levels. [Less]

The pgAdmin Development Team is pleased to announce pgAdmin 4 version 6.2. This release of pgAdmin 4 includes 22 bug fixes and new features. For more details please see the release notes. pgAdmin is the leading Open Source graphical management tool ... [More] for PostgreSQL. For more information, please see the website. Notable changes in this release include: Features: Added support for Aggregate and Operator nodes in view-only mode. Ensure that users should be able to modify the REMOTE_USER environment variable as per their environment by introducing the new config parameter WEBSERVER_REMOTE_USER. Bugs/Housekeeping: Fixed pgAdmin freezing issue by providing the error message for the operation that can't perform due to a lock on the particular table. Fixed an issue where pgAdmin is not opening properly. Ensure that internal authentication, when combined with other authentication providers, the order of internal sources should not matter while picking up the provider. Ensure that the user should be able to navigate browser tree objects using arrow keys from the keyboard. Fixed an issue where database nodes are not getting loaded behind a reverse proxy with SSL. Fixed an issue where JSON editor preview colours had inappropriate contrast in dark mode. Fixed JSON Editor scrolling issue in code mode. Ensure that changing themes should work on Windows when system high contrast mode is enabled. Ensure that the Binary path for PG14 should be visible in the preferences. Fixed an issue where textarea should be allowed to resize and have more than 255 chars. Note: We regret that once again we have been unable to publish an updated Python package to PyPi. This is due to the need for a quota increase for pgAdmin on PyPi that is currently awaiting action from the PyPi team. Builds for Windows and macOS are available now, along with a Python Wheel, Docker Container, RPM, DEB Package, and source code tarball from the tarball area. [Less]