Jelenlegi hely

PostreSQL.org

Feliratkozás PostreSQL.org hírcsatorna csatornájára
PostgreSQL news
Frissítve: 8 óra 21 perc

Ajqvue Version 3.3 Released

2020, november 6 - 01:00

The Ajqvue project is pleased to release v3.3 to the public. The
release brings updates to the included File/Memory database
libraries. Modifications to image saves for sizing. Added was
support for PostgreSQL 13 along with data types money,
smallserial, macaddr8, line, and uuid. Precision is now supported
for time and timestamp types for those databases that support it.

Convert database queries to a local file/memory H2, HSQL, Derby
or SQLite database with the DB To File/Memory DB plugin.
Github DB To File/Memory DB Plugin

Dana M. Proctor
Ajqvue Project Manager

Ajqvue Website
Ajqvue Github

Ajqvue is an open source Java GUI build for users in accessing,
plotting, and analyzing data in several mainstream databases.
The application is built with a included plugin framework for
adding functionality, quickly.

Kategóriák: Informatika

PostgreSQL Weekly News - November 1, 2020

2020, november 2 - 01:00
PostgreSQL Weekly News - November 1, 2020

The next Commitfest for PostgreSQL 14 has begun. If you are the author of a patch, please make sure to follow up on the reviews so your contribution can get ready to be committed.

PostgreSQL Product News

pgbitmap 0.93, a space-optimised, non-sparse, bitmap type, released. https://pgxn.org/dist/pgbitmap/

Pgpool-II 4.2 beta1 https://www.pgpool.net/docs/42/en/html/release-4-2-0.html

pglogical 2.3.3, a logical-WAL-based replication system for PostgreSQL, released. https://www.2ndquadrant.com/en/resources/pglogical/release-notes/

pg_activity 1.6.2, a top-like application for PostgreSQL server activity monitoring, released. https://github.com/dalibo/pg_activity/releases/tag/v1.6.2

pg_dumpbinary 2.3, a program used to dump a PostgreSQL database in binary format, released. https://github.com/lzlabs/pg_dumpbinary/releases/

pgCenter 0.6.6, a command-line admin tool for observing and troubleshooting PostgreSQL, released. https://github.com/lesovsky/pgcenter/releases/tag/v0.6.6

PostgreSQL in the News

Planet PostgreSQL: http://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 david@fetter.org.

Applied Patches

David Rowley pushed:

  • Prevent overly large and NaN row estimates in relations. Given a query with enough joins, it was possible that the query planner, after multiplying the row estimates with the join selectivity that the estimated number of rows would exceed the limits of the double data type and become infinite. To give an indication on how extreme a case is required to hit this, the particular example case reported required 379 joins to a table without any statistics, which resulted in the 1.0/DEFAULT_NUM_DISTINCT being used for the join selectivity. This eventually caused the row estimates to go infinite and resulted in an assert failure in initial_cost_mergejoin() where the infinite row estimated was multiplied by an outerstartsel of 0.0 resulting in NaN. The failing assert verified that NaN <= Inf, which is false. To get around this we use clamp_row_est() to cap row estimates at a maximum of 1e100. This value is thought to be low enough that costs derived from it would remain within the bounds of what the double type can represent. Aside from fixing the failing Assert, this also has the added benefit of making it so add_path() will still receive proper numerical values as costs which will allow it to make more sane choices when determining the cheaper path in extreme cases such as the one described above. Additionally, we also get rid of the isnan() checks in the join costing functions. The actual case which originally triggered those checks to be added in the first place never made it to the mailing lists. It seems likely that the new code being added to clamp_row_est() will result in those becoming checks redundant, so just remove them. The fairly harmless assert failure problem does also exist in the backbranches, however, a more minimalistic fix will be applied there. Reported-by: Onder Kalaci Reviewed-by: Tom Lane Discussion: https://postgr.es/m/DM6PR21MB1211FF360183BCA901B27F04D80B0@DM6PR21MB1211.namprd21.prod.outlook.com https://git.postgresql.org/pg/commitdiff/a90c950fc7fd8796daa8c7948e7046bceb272894

  • Optimize a few list_delete_ptr calls. There is a handful of places where we called list_delete_ptr() to remove some element from a List. In many of these places we know, or with very little additional effort know the index of the ListCell that we need to remove. Here we change all of those places to instead either use one of; list_delete_nth_cell(), foreach_delete_current() or list_delete_last(). Each of these saves from having to iterate over the list to search for the element to remove by its pointer value. There are some small performance gains to be had by doing this, but in the general case, none of these lists are likely to be very large, so the lookup was probably never that expensive anyway. However, some of the calls are in fairly hot code paths, e.g process_equivalence(). So any small gains there are useful. Author: Zhijie Hou and David Rowley Discussion: https://postgr.es/m/b3517353ec7c4f87aa560678fbb1034b@G08CNEXMBPEKD05.g08.fujitsu.local https://git.postgresql.org/pg/commitdiff/e7c2b95d37a2b9c01367f7ccc55703555b39c81c

  • Fix incorrect parameter name in a function header comment. Author: Zhijie Hou Discussion: https://postgr.es/m/14cd74ea00204cc8a7ea5d738ac82cd1@G08CNEXMBPEKD05.g08.fujitsu.local Backpatch-through: 12, where the mistake was introduced https://git.postgresql.org/pg/commitdiff/e83c9f913c6197586af8ac53c1d3652db15a3c91

Michaël Paquier pushed:

  • Fix potential memory leak in pgcrypto. When allocating a EVP context, it would have been possible to leak some memory allocated directly by OpenSSL, that PostgreSQL lost track of if the initialization of the context allocated failed. The cleanup can be done with EVP_MD_CTX_destroy(). Note that EVP APIs exist since OpenSSL 0.9.7 and we have in the tree equivalent implementations for older versions since ce9b75d (code removed with 9b7cd59a as of 10~). However, in 9.5 and 9.6, the existing code makes use of EVP_MD_CTX_destroy() and EVP_MD_CTX_create() without an equivalent implementation when building the tree with OpenSSL 0.9.6 or older, meaning that this code is in reality broken with such versions since it got introduced in e2838c5. As we have heard no complains about that, it does not seem worth bothering with in 9.5 and 9.6, so I have left that out for simplicity. Author: Michael Paquier Discussion: https://postgr.es/m/20201015072212.GC2305@paquier.xyz Backpatch-through: 9.5 https://git.postgresql.org/pg/commitdiff/ca2a12c935f75fb56c3b14527d6f2ff6f549ea85

  • Review format of code generated by PerfectHash.pm. 80f8eb7 has added to the normalization quick check headers some code generated by PerfectHash.pm that is incompatible with the settings of gitattributes for this repository, as whitespaces followed a set of tabs for the first element of a line in the table. Instead of adding a new exception to gitattributes, rework the format generated so as a right padding with spaces is used instead of a left padding. This keeps the table generated in a readable shape with its set of columns, making unnecessary an update of gitattributes. Reported-by: Peter Eisentraut Author: John Naylor Discussion: https://postgr.es/m/d601b3b5-a3c7-5457-2f84-3d6513d690fc@2ndquadrant.com https://git.postgresql.org/pg/commitdiff/19ae53c92d5f5bdfb971d560a562e84c5f65c8b0

  • Improve performance of Unicode {de,re}composition in the backend. This replaces the existing binary search with two perfect hash functions for the composition and the decomposition in the backend code, at the cost of slightly-larger binaries there (35kB in libpgcommon_srv.a). Per the measurements done, this improves the speed of the recomposition and decomposition by up to 30~40 times for the NFC and NFKC conversions, while all other operations get at least 40% faster. This is not as "good" as what libicu has, but it closes the gap a lot as per the feedback from Daniel Verite. The decomposition table remains the same, getting used for the binary search in the frontend code, where we care more about the size of the libraries like libpq over performance as this gets involved only in code paths related to the SCRAM authentication. In consequence, note that the perfect hash function for the recomposition needs to use a new inverse lookup array back to to the existing decomposition table. The size of all frontend deliverables remains unchanged, even with --enable-debug, including libpq. Author: John Naylor Reviewed-by: Michael Paquier, Tom Lane Discussion: https://postgr.es/m/CAFBsxsHUuMFCt6-pU+oG-F1==CmEp8wR+O+bRouXWu6i8kXuqA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/783f0cc64dcc05e3d112a06b1cd181e5a1ca9099

  • Add tab completion for ALTER TABLE .. FORCE ROW LEVEL SECURITY in psql. This completes both the FORCE and NO FORCE options, NO INHERIT needing a small adjustment. Author: Li Japin Discussion: https://postgr.es/m/15B10F9F-5847-4F5E-BD66-8E25AA473C95@hotmail.com https://git.postgresql.org/pg/commitdiff/0b46e82c06b0c4b0dc6a94a890d23945ebf720fd

  • Fix issue with --enable-coverage and the new unicode {de,re}composition code. genhtml has been generating the following warning with this new code: WARNING: function data mismatch at /path/src/common/unicode_norm.c:102 HTML coverage reports care about the uniqueness of functions defined in source files, ignoring any assumptions around CFLAGS. 783f0cc introduced a duplicated definition of get_code_entry(), leading to a warning and potentially some incorrect data generated in the reports. This refactors the code so as the code has only one function declaration, fixing the warning. Oversight in 783f0cc. Reported-by: Tom Lane Author: Michael Paquier Reviewed-by: Tom Lane Discussion: https://postgr.es/m/207789.1603469272@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/2771fcee18be0b86d2e008add20f73d175e06e90

  • Extend PageIsVerified() to handle more custom options. This is useful for checks of relation pages without having to load the pages into the shared buffers, and two cases can make use of that: page verification in base backups and the online, lock-safe, flavor. Compatibility is kept with past versions using a macro that calls the new extended routine with the set of options compatible with the original version. Extracted from a larger patch by the same author. Author: Anastasia Lubennikova Reviewed-by: Michael Paquier, Julien Rouhaud Discussion: https://postgr.es/m/608f3476-0598-2514-2c03-e05c7d2b0cbd@postgrespro.ru https://git.postgresql.org/pg/commitdiff/d401c5769ef6aeef0a28c147f3fb5afedcd59984

  • Add CheckBuffer() to check on-disk pages without shared buffer loading. CheckBuffer() is designed to be a concurrent-safe function able to run sanity checks on a relation page without loading it into the shared buffers. The operation is done using a lock on the partition involved in the shared buffer mapping hashtable and an I/O lock for the buffer itself, preventing the risk of false positives due to any concurrent activity. The primary use of this function is the detection of on-disk corruptions for relation pages. If a page is found in shared buffers, the on-disk page is checked if not dirty (a follow-up checkpoint would flush a valid version of the page if dirty anyway), as it could be possible that a page was present for a long time in shared buffers with its on-disk version corrupted. Such a scenario could lead to a corrupted cluster if a host is plugged off for example. If the page is not found in shared buffers, its on-disk state is checked. PageIsVerifiedExtended() is used to apply the same sanity checks as when a page gets loaded into shared buffers. This function will be used by an upcoming patch able to check the state of on-disk relation pages using a SQL function. Author: Julien Rouhaud, Michael Paquier Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/CAOBaU_aVvMjQn=ge5qPiJOPMmOj5=ii3st5Q0Y+WuLML5sR17w@mail.gmail.com https://git.postgresql.org/pg/commitdiff/c780a7a90a8e7b074405ea2007e34f94e227e695

  • Add pg_relation_check_pages() to check on-disk pages of a relation. This makes use of CheckBuffer() introduced in c780a7a, adding a SQL wrapper able to do checks for all the pages of a relation. By default, all the fork types of a relation are checked, and it is possible to check only a given relation fork. Note that if the relation given in input has no physical storage or is temporary, then no errors are generated, allowing full-database checks when coupled with a simple scan of pg_class for example. This is not limited to clusters with data checksums enabled, as clusters without data checksums can still apply checks on pages using the page headers or for the case of a page full of zeros. This function returns a set of tuples consisting of: - The physical file where a broken page has been detected (without the segment number as that can be AM-dependent, which can be guessed from the block number for heap). A relative path from PGPATH is used. - The block number of the broken page. By default, only superusers have an access to this function but execution rights can be granted to other users. The feature introduced here is still minimal, and more improvements could be done, like: - Addition of a start and end block number to run checks on a range of blocks, which would apply only if one fork type is checked. - Addition of some progress reporting.

  • Throttling, with configuration parameters in function input or potentially some cost-based GUCs. Regression tests are added for positive cases in the main regression test suite, and TAP tests are added for cases involving the emulation of page corruptions. Bump catalog version. Author: Julien Rouhaud, Michael Paquier Reviewed-by: Masahiko Sawada, Justin Pryzby Discussion: https://postgr.es/m/CAOBaU_aVvMjQn=ge5qPiJOPMmOj5=ii3st5Q0Y+WuLML5sR17w@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f2b883969557f4572cdfa87e1a40083d2b1272e7

  • Use correct GetDatum() in pg_relation_check_pages(). UInt32GetDatum() was getting used, while the result needs Int64GetDatum(). Oversight in f2b8839. Per buildfarm member florican. Discussion: https://postgr.es/m/1226629.1603859189@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/ce7f772c5e6066e0bbafea5759e652c9757c8e6b

  • Fix incorrect placement of pfree() in pg_relation_check_pages(). This would cause the function to crash when more than one page is considered as broken and reported in the SRF. Reported-by: Noriyoshi Shinoda Discussion: https://postgr.es/m/TU4PR8401MB11523D42C315AAF822E74275EE170@TU4PR8401MB1152.NAMPRD84.PROD.OUTLOOK.COM https://git.postgresql.org/pg/commitdiff/60a51c6b32960822d3987ea7d2816c65bdbcb314

  • Add error code for encryption failure in pgcrypto. PXE_DECRYPT_FAILED exists already for decryption errors, and an equivalent for encryption did not exist. There is one code path that deals with such failures for OpenSSL but it used PXE_ERR_GENERIC, which was inconsistent. This switches this code path to use the new error PXE_ENCRYPT_FAILED instead of PXE_ERR_GENERIC, making the code used for encryption more consistent with the decryption. Author: Daniel Gustafsson Discussion: https://postgr.es/m/03049139-CB7A-436E-B71B-42696D3E2EF7@yesql.se https://git.postgresql.org/pg/commitdiff/aecaa04418f39c32adb3dbf91c4aa7f6e175f01c

  • Preserve index data in pg_statistic across REINDEX CONCURRENTLY. Statistics associated to an index got lost after running REINDEX CONCURRENTLY, while the non-concurrent case preserves these correctly. The concurrent and non-concurrent operations need to be consistent for the end-user, and missing statistics would force to wait for a new analyze to happen, which could take some time depending on the activity of the existing autovacuum workers. This issue is fixed by copying any existing entries in pg_statistic associated to the old index to the new one. Note that this copy is already done with the data of the index in the stats collector. Reported-by: Fabrízio de Royes Mello Author: Michael Paquier, Fabrízio de Royes Mello Reviewed-by: Justin Pryzby Discussion: https://postgr.es/m/CAFcNs+qpFPmiHd1oTXvcPdvAHicJDA9qBUSujgAhUMJyUMb+SA@mail.gmail.com Backpatch-through: 12 https://git.postgresql.org/pg/commitdiff/b17ff07aa3eb142d2cde2ea00e4a4e8f63686f96

Amit Kapila pushed:

Peter Eisentraut pushed:

Heikki Linnakangas pushed:

Magnus Hagander pushed:

Tom Lane pushed:

  • Fix list-munging bug that broke SQL function result coercions. Since commit 913bbd88d, check_sql_fn_retval() can either insert type coercion steps in-line in the Query that produces the SQL function's results, or generate a new top-level Query to perform the coercions, if modifying the Query's output in-place wouldn't be safe. However, it appears that the latter case has never actually worked, because the code tried to inject the new Query back into the query list it was passed ... which is not the list that will be used for later processing when we execute the SQL function "normally" (without inlining it). So we ended up with no coercion happening at run-time, leading to wrong results or crashes depending on the datatypes involved. While the regression tests look like they cover this area well enough, through a huge bit of bad luck all the test cases that exercise the separate-Query path were checking either inline-able cases (which accidentally didn't have the bug) or cases that are no-ops at runtime (e.g., varchar to text), so that the failure to perform the coercion wasn't obvious. The fact that the cases that don't work weren't allowed at all before v13 probably contributed to not noticing the problem sooner, too. To fix, get rid of the separate "flat" list of Query nodes and instead pass the real two-level list that is going to be used later. I chose to make the same change in check_sql_fn_statements(), although that has no actual bug, just so that we don't need that data structure at all. This is an API change, as evidenced by the adjustments needed to callers outside functions.c. That's a bit scary to be doing in a released branch, but so far as I can tell from a quick search, there are no outside callers of these functions (and they are sufficiently specific to our semantics for SQL-language functions that it's not apparent why any extension would need to call them). In any case, v13 already changed the API of check_sql_fn_retval() compared to prior branches. Per report from pinker. Back-patch to v13 where this code came in. Discussion: https://postgr.es/m/1603050466566-0.post@n3.nabble.com https://git.postgresql.org/pg/commitdiff/c8ab9701791e22f7a8e1badf362654db179c9703

  • Fix connection string handling in src/bin/scripts/ programs. When told to process all databases, clusterdb, reindexdb, and vacuumdb would reconnect by replacing their --maintenance-db parameter with the name of the target database. If that parameter is a connstring (which has been allowed for a long time, though we failed to document that before this patch), we'd lose any other options it might specify, for example SSL or GSS parameters, possibly resulting in failure to connect. Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and pg_restore. We can fix it in the same way, by using libpq's rules for handling multiple "dbname" parameters to add the target database name separately. I chose to apply the same refactoring approach as in that patch, with a struct to handle the command line parameters that need to be passed through to connectDatabase. (Maybe someday we can unify the very similar functions here and in pg_dump/pg_restore.) Per Peter Eisentraut's comments on bug #16604. Back-patch to all supported branches. Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org https://git.postgresql.org/pg/commitdiff/8e5793ab60bba65ffaa0f2237b39c9580d8972c7

  • Remove the option to build thread_test.c outside configure. Theoretically one could go into src/test/thread and build/run this program there. In practice, that hasn't worked since 96bf88d52, and probably much longer on some platforms (likely including just the sort of hoary leftovers where this test might be of interest). While it wouldn't be too hard to repair the breakage, the fact that nobody has noticed for two years shows that there is zero usefulness in maintaining this build pathway. Let's get rid of it and decree that thread_test.c is *only* meant to be built/used in configure. Given that decision, it makes sense to put thread_test.c under config/ and get rid of src/test/thread altogether, so that's what I did. In passing, update src/test/README, which had been ignored by some not-so-recent additions of subdirectories. Discussion: https://postgr.es/m/227659.1603041612@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/8a2121185b26d7eb439860c7a96a08c0aa3c8508

  • Fix connection string handling in psql's \connect command. psql's \connect claims to be able to re-use previous connection parameters, but in fact it only re-uses the database name, user name, host name (and possibly hostaddr, depending on version), and port. This is problematic for assorted use cases. Notably, pg_dump[all] emits "\connect databasename" commands which we would like to have re-use all other parameters. If such a script is loaded in a psql run that initially had "-d connstring" with some non-default parameters, those other parameters would be lost, potentially causing connection failure. (Thus, this is the same kind of bug addressed in commits a45bc8a4f and 8e5793ab6, although the details are much different.) To fix, redesign do_connect() so that it pulls out all properties of the old PGconn using PQconninfo(), and then replaces individual properties in that array. In the case where we don't wish to re-use anything, get libpq's default settings using PQconndefaults() and replace entries in that, so that we don't need different code paths for the two cases. This does result in an additional behavioral change for cases where the original connection parameters allowed multiple hosts, say "psql -h host1,host2", and the \connect request allows re-use of the host setting. Because the previous coding relied on PQhost(), it would only permit reconnection to the same host originally selected. Although one can think of scenarios where that's a good thing, there are others where it is not. Moreover, that behavior doesn't seem to meet the principle of least surprise, nor was it documented; nor is it even clear it was intended, since that coding long pre-dates the addition of multi-host support to libpq. Hence, this patch is content to drop it and re-use the host list as given. Per Peter Eisentraut's comments on bug #16604. Back-patch to all supported branches. Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org https://git.postgresql.org/pg/commitdiff/85c54287af56fe351b53913ea2b81e9d6145f964

  • Clean up some unpleasant behaviors in psql's \connect command. The check for whether to complain about not having an old connection to get parameters from was seriously out of date: it had not been rethought when we invented connstrings, nor when we invented the -reuse-previous option. Replace it with a check that throws an error if reuse-previous is active and we lack an old connection to reuse. While that doesn't move the goalposts very far in terms of easing reconnection after a server crash, at least it's consistent. If the user specifies a connstring plus additional parameters (which is invalid per the documentation), the extra parameters were silently ignored. That seems like it could be really confusing, so let's throw a syntax error instead. Teach the connstring code path to re-use the old connection's password in the same cases as the old-style-syntax code path would, ie if we are reusing parameters and the values of username, host/hostaddr, and port are not being changed. Document this behavior, too, since it was unmentioned before. Also simplify the implementation a bit, giving rise to two new and useful properties: if there's a "password=xxx" in the connstring, we'll use it not ignore it, and by default (i.e., except with --no-password) we will prompt for a password if the re-used password or connstring password doesn't work. The previous code just failed if the re-used password didn't work. Given the paucity of field complaints about these issues, I don't think that they rise to the level of back-patchable bug fixes, and in any case they might represent undesirable behavior changes in minor releases. So no back-patch. Discussion: https://postgr.es/m/235210.1603321144@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/94929f1cf6cb3ea070d0919d1303379b525a72a3

  • Add documentation and tests for quote marks in ECPG literal queries. ECPG's PREPARE ... FROM and EXECUTE IMMEDIATE can optionally take the target query as a simple literal, rather than the more usual string-variable reference. This was previously documented as being a C string literal, but that's a lie in one critical respect: you can't write a data double quote as \" in such literals. That's because the lexer is in SQL mode at this point, so it'll parse double-quoted strings as SQL identifiers, within which backslash is not special, so \" ends the literal. I looked into making this work as documented, but getting the lexer to switch behaviors at just the right point is somewhere between very difficult and impossible. It's not really worth the trouble, because these cases are next to useless: if you have a fixed SQL statement to execute or prepare, you might as well write it as a direct EXEC SQL, saving the messiness of converting it into a string literal and gaining the opportunity for compile-time SQL syntax checking. Instead, let's just document (and test) the workaround of writing a double quote as an octal escape (\042) in such cases. There's no code behavioral change here, so in principle this could be back-patched, but it's such a niche case I doubt it's worth the trouble. Per report from 1250kv. Discussion: https://postgr.es/m/673825.1603223178@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/c16a1bbcf498f0aa053a3e55008f57d7f67357dd

  • Avoid premature de-doubling of quote marks in ECPG strings. If you write the literal 'abc''def' in an EXEC SQL command, that will come out the other end as 'abc'def', triggering a syntax error in the backend. Likewise, "abc""def" is reduced to "abc"def" which is wrong syntax for a quoted identifier. The cause is that the lexer thinks it should emit just one quote mark, whereas what it really should do is keep the string as-is. Add some docs and test cases, too. Although this seems clearly a bug, I fear users wouldn't appreciate changing it in minor releases. Some may well be working around it by applying an extra doubling of affected quotes, as for example sql/dyntest.pgc has been doing. Per investigation of a report from 1250kv, although this isn't exactly what he/she was on about. Discussion: https://postgr.es/m/673825.1603223178@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/3dfb1942d9b8748b93094a430289e2f7f3b3ae0d

  • Sync our copy of the timezone library with IANA release tzcode2020d. There's no functional change at all here, but I'm curious to see whether this change successfully shuts up Coverity's warning about a useless strcmp(), which appeared with the previous update. Discussion: http://mm.icann.org/pipermail/tz/2020-October/029370.html https://git.postgresql.org/pg/commitdiff/c5054da0d7ee59a93ca6d7f7fc669ef0210dbad3

  • Update time zone data files to tzdata release 2020d. DST law changes in Palestine, with a whopping 120 hours' notice. Also some historical corrections for Palestine. https://git.postgresql.org/pg/commitdiff/7d6d6bce43c60bb7b77237e2cc6ab845646b911f

  • Fix broken XML formatting in EXPLAIN output for incremental sorts. The ExplainCloseGroup arguments for incremental sort usage data didn't match the corresponding ExplainOpenGroup. This only matters for XML-format output, which is probably why we'd not noticed. Daniel Gustafsson, per bug #16683 from Frits Jalvingh Discussion: https://postgr.es/m/16683-8005033324ad34e9@postgresql.org https://git.postgresql.org/pg/commitdiff/87a174c0e77eed0bec7d53ef6d470d60335f6444

  • Fix portability issues in new amcheck test. The tests added by commit 866e24d47 failed on big-endian machines due to lack of attention to endianness considerations. Fix that. While here, improve a few small cosmetic things, such as running it through perltidy. Mark Dilger Discussion: https://postgr.es/m/30B8E99A-2D9C-48D4-A55C-741C9D5F1563@enterprisedb.com https://git.postgresql.org/pg/commitdiff/860593ec3bd15e8969effdfcb5cbd98c561dd722

  • Allow psql to re-use connection parameters after a connection loss. Instead of immediately PQfinish'ing a dead connection, save it aside so that we can still extract its parameters for \connect attempts. (This works because PQconninfo doesn't care whether the PGconn is in CONNECTION_BAD state.) This allows developers to reconnect with just \c after a database crash and restart. It's tempting to use the same approach instead of closing the old connection after a failed non-interactive \connect command. However, that would not be very safe: consider a script containing \c db1 user1 live_server \c db2 user2 dead_server \c db3 The script would be expecting to connect to db3 at dead_server, but if we re-use parameters from the first connection then it might successfully connect to db3 at live_server. This'd defeat the goal of not letting a script accidentally execute commands against the wrong database. Discussion: https://postgr.es/m/38464.1603394584@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/1b62d0fb3e50ede570d0d4e4a2be69d5645b48a7

  • Fix more portability issues in new amcheck code. verify_heapam() wasn't being careful to sanity-check tuple line pointers before using them, resulting in SIGBUS on alignment-picky architectures. Fix that, add some more test coverage. Mark Dilger, some tweaking by me Discussion: https://postgr.es/m/30B8E99A-2D9C-48D4-A55C-741C9D5F1563@enterprisedb.com https://git.postgresql.org/pg/commitdiff/321633e17b07968e68ca5341429e2c8bbf15c331

  • Fix ancient bug in ecpg's pthread_once() emulation for Windows. We must not set the "done" flag until after we've executed the initialization function. Otherwise, other threads can fall through the initial unlocked test before initialization is really complete. This has been seen to cause rare failures of ecpg's thread/descriptor test, and it could presumably cause other sorts of misbehavior in threaded ECPG-using applications, since ecpglib relies on pthread_once() in several places. Diagnosis and patch by me, based on investigation by Alexander Lakhin. Back-patch to all supported branches (the bug dates to 2007). Discussion: https://postgr.es/m/16685-d6cd241872c101d3@postgresql.org https://git.postgresql.org/pg/commitdiff/21d36747d4fafe16539a0c55ebb91a01e4053e3c

  • Fix corner case for a BEFORE ROW UPDATE trigger returning OLD. If the old row has any "missing" attributes that are supposed to be retrieved from an associated tuple descriptor, the wrong things happened because the trigger result is shoved directly into an executor slot that lacks the missing-attribute data. Notably, CHECK-constraint verification would incorrectly see those columns as NULL, and so would RETURNING-list evaluation. Band-aid around this by forcibly expanding the tuple before passing it to the trigger function. (IMO it was a fundamental misdesign to put the missing-attribute data into tuple constraints, which so much of the system considers to be optional. But we're probably stuck with that now, and will have to continue to apply band-aids as we find other places with similar issues.) Back-patch to v12. v11 would also have the issue, except that commit 920311ab1 already applied a similar band-aid. That forced expansion in more cases than seem really necessary, though, so this isn't a directly equivalent fix. Amit Langote, with some cosmetic changes by me Discussion: https://postgr.es/m/16644-5da7ef98a7ac4545@postgresql.org https://git.postgresql.org/pg/commitdiff/ba9f18abd3650e385e9a35df7145a7c38af17e92

  • In INSERT/UPDATE, use the table's real tuple descriptor as target. Previously, ExecInitModifyTable relied on ExecInitJunkFilter, and thence ExecCleanTypeFromTL, to build the target descriptor from the query tlist. While we just checked (in ExecCheckPlanOutput) that the tlist produces compatible output, this is not a great substitute for the relation's actual tuple descriptor that's available from the relcache. For one thing, dropped columns will not be correctly marked attisdropped; it's a bit surprising that we've gotten away with that this long. But the real reason for being concerned with this is that using the table's descriptor means that the slot will have correct attrmissing data, allowing us to revert the klugy fix of commit ba9f18abd. (This commit undoes that one's changes in trigger.c, but keeps the new test case.) Thus we can solve the bogus-trigger-tuple problem with fewer cycles rather than more. No back-patch, since this doesn't fix any additional bug, and it seems somewhat more likely to have unforeseen side effects than ba9f18abd's narrow fix. Discussion: https://postgr.es/m/16644-5da7ef98a7ac4545@postgresql.org https://git.postgresql.org/pg/commitdiff/20d3fe9009ddbbbb3da3a2da298f922054b43f8c

  • Doc: improve explanation of how to use our code coverage infrastructure. The reference to running "make coverage" in a subdirectory was a bit obscure, so clarify what happens when you do that. Do a little desultory copy-editing, too. Per a question from Peter Smith. Discussion: https://postgr.es/m/CAHut+Pu0r3AjRSyu5E0v2-zRj8r24OSrkWs3fEBxOuaw1i8DKA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/8d132b2850d4c95ed5666a09b295dea645bbc884

  • Fix foreign-key selectivity estimation in the presence of constants. get_foreign_key_join_selectivity() looks for join clauses that equate the two sides of the FK constraint. However, if we have a query like "WHERE fktab.a = pktab.a and fktab.a = 1", it won't find any such join clause, because equivclass.c replaces the given clauses with "fktab.a = 1 and pktab.a = 1", which can be enforced at the scan level, leaving nothing to be done for column "a" at the join level. We can fix that expectation without much trouble, but then a new problem arises: applying the foreign-key-based selectivity rule produces a rowcount underestimate, because we're effectively double-counting the selectivity of the "fktab.a = 1" clause. So we have to cancel that selectivity out of the estimate. To fix, refactor process_implied_equality() so that it can pass back the new RestrictInfo to its callers in equivclass.c, allowing the generated "fktab.a = 1" clause to be saved in the EquivalenceClass's ec_derives list. Then it's not much trouble to dig out the relevant RestrictInfo when we need to adjust an FK selectivity estimate. (While at it, we can also remove the expensive use of initialize_mergeclause_eclasses() to set up the new RestrictInfo's left_ec and right_ec pointers. The equivclass.c code can set those basically for free.) This seems like clearly a bug fix, but I'm hesitant to back-patch it, first because there's some API/ABI risk for extensions and second because we're usually loath to destabilize plan choices in stable branches. Per report from Sigrid Ehrenreich. Discussion: https://postgr.es/m/1019549.1603770457@sss.pgh.pa.us Discussion: https://postgr.es/m/AM6PR02MB5287A0ADD936C1FA80973E72AB190@AM6PR02MB5287.eurprd02.prod.outlook.com https://git.postgresql.org/pg/commitdiff/ad1c36b0709e47cdb3cc4abd6c939fe64279b63f

  • Don't use custom OID symbols in pg_proc.dat. We have a perfectly good convention for OID macros for built-in functions already, so making custom symbols is just introducing unnecessary deviation from the convention. Remove the one case that had snuck in, and add an error check in genbki.pl to discourage future instances. Although this touches pg_proc.dat, there's no need for a catversion bump since the actual catalog data isn't changed. John Naylor Discussion: https://postgr.es/m/CAFBsxsHpCbjfoddNGpnnnY5pHwckWfiYkMYSF74PmP1su0+ZOw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/36b93121436cbbf357974144068c23bac75154fa

  • Calculate extraUpdatedCols in query rewriter, not parser. It's unsafe to do this at parse time because addition of generated columns to a table would not invalidate stored rules containing UPDATEs on the table ... but there might now be dependent generated columns that were not there when the rule was made. This also fixes an oversight that rewriteTargetView failed to update extraUpdatedCols when transforming an UPDATE on an updatable view. (Since the new calculation is downstream of that, rewriteTargetView doesn't actually need to do anything; but before, there was a demonstrable bug there.) In v13 and HEAD, this leads to easily-visible bugs because (since commit c6679e4fc) we won't recalculate generated columns that aren't listed in extraUpdatedCols. In v12 this bitmap is mostly just used for trigger-firing decisions, so you'd only notice a problem if a trigger cared whether a generated column had been updated. I'd complained about this back in May, but then forgot about it until bug #16671 from Michael Paul Killian revived the issue. Back-patch to v12 where this field was introduced. If existing stored rules contain any extraUpdatedCols values, they'll be ignored because the rewriter will overwrite them, so the bug will be fixed even for existing rules. (But note that if someone were to update to 13.1 or 12.5, store some rules with UPDATEs on tables having generated columns, and then downgrade to a prior minor version, they might observe issues similar to what this patch fixes. That seems unlikely enough to not be worth going to a lot of effort to fix.) Discussion: https://postgr.es/m/10206.1588964727@sss.pgh.pa.us Discussion: https://postgr.es/m/16671-2fa55851859fb166@postgresql.org https://git.postgresql.org/pg/commitdiff/ad77039fad0f4128b0e4a05ddbf5dbc3ab5f3fa4

  • Use mode "r" for popen() in psql's evaluate_backtick(). In almost all other places, we use plain "r" or "w" mode in popen() calls (the exceptions being for COPY data). This one has been overlooked (possibly because it's buried in a ".l" flex file?), but it's using PG_BINARY_R. Kensuke Okamura complained in bug #16688 that we fail to strip \r when stripping the trailing newline from a backtick result string. That's true enough, but we'd also fail to convert embedded \r\n cleanly, which also seems undesirable. Fixing the popen() mode seems like the best way to deal with this. It's been like this for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/16688-c649c7b69cd7e6f8@postgresql.org https://git.postgresql.org/pg/commitdiff/66f8687a8ff867f656de81e367314604d29dbd59

  • Doc: clean up verify_heapam() documentation. I started with the intention of just suppressing a PDF build warning by removing the example output, but ended up doing more: correcting factual errors in the function's signature, moving a bunch of generalized handwaving into the "Using amcheck Effectively" section which seemed a better place for it, and improving wording and markup a little bit. Discussion: https://postgr.es/m/732904.1603728748@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/4c49d8fc15eeb1dc69b0ddb2d986a1884a5d7f5f

  • Doc: clean up pg_relation_check_pages() documentation. Commit f2b883969 did not get the memo about the new formatting style for tables documenting built-in functions. I noticed because of a PDF build warning about an overwidth table. https://git.postgresql.org/pg/commitdiff/b787d4ce6d910080065025bcd5f968544997271f

  • Don't use custom OID symbols in pg_type.dat, either. On the same reasoning as in commit 36b931214, forbid using custom oid_symbol macros in pg_type as well as pg_proc, so that we always rely on the predictable macro names generated by genbki.pl. We do continue to grant grandfather status to the names CASHOID and LSNOID, although those are now considered deprecated aliases for the preferred names MONEYOID and PG_LSNOID. This is because there's likely to be client-side code using the old names, and this bout of neatnik-ism doesn't quite seem worth breaking client code. There might be a case for grandfathering EVTTRIGGEROID, too, since externally-maintained PLs may reference that symbol. But renaming such references to EVENT_TRIGGEROID doesn't seem like a particularly heavy lift --- we make far more significant backend API changes in every major release. For now I didn't add that, but we could reconsider if there's pushback. The other names changed here seem pretty unlikely to have any outside uses. Again, we could add alias macros if there are complaints, but for now I didn't. As before, no need for a catversion bump. John Naylor Discussion: https://postgr.es/m/CAFBsxsHpCbjfoddNGpnnnY5pHwckWfiYkMYSF74PmP1su0+ZOw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f90149e6285aaae6b48559afce1bd638ee26c33e

  • Stabilize timetz test across DST transitions. The timetz test cases I added in commit a9632830b were unintentionally sensitive to whether or not DST is active in the PST8PDT time zone. Thus, they'll start failing this coming weekend, as reported by Bernhard M. Wiedemann in bug #16689. Fortunately, DST-awareness is not significant to the purpose of these test cases, so we can just force them all to PDT (DST hours) to preserve stability of the results. Back-patch to v10, as the prior patch was. Discussion: https://postgr.es/m/16689-57701daa23b377bf@postgresql.org https://git.postgresql.org/pg/commitdiff/4a071afbd056282746a5bc9362e87f579a56402d

  • Doc: clarify description for pg_constraint.convalidated. Jimmy Angelakos Discussion: https://postgr.es/m/CABgVKCW_zPnvFXn24FTF0299_yU6+1p6JRUc0xpiZFWEXH1_jg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/b401fa206d446f224ec4760f21e0a351816c97b3

  • Fix assertion failure in check_new_partition_bound(). Commit 6b2c4e59d was overly confident about not being able to see a negative cmpval result from partition_range_bsearch(). Adjust the code to cope with that. Report and patch by Amul Sul; some additional cosmetic changes by me Discussion: https://postgr.es/m/CAAJ_b97WCO=EyVA7fKzc86kKfojHXLU04_zs7-7+yVzm=-1QkQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/970c05057593c2f5919a69b43fd917c4fa86f51c

  • Avoid null pointer dereference if error result lacks SQLSTATE. Although error results received from the backend should always have a SQLSTATE field, ones generated by libpq won't, making this code vulnerable to a crash after, say, untimely loss of connection. Noted by Coverity. Oversight in commit 403a3d91c. Back-patch to 9.5, as that was. https://git.postgresql.org/pg/commitdiff/7f4235032f0d75ea1ad29b192d57fee3d8fe533e

Álvaro Herrera pushed:

Robert Haas pushed:

Bruce Momjian pushed:

Andres Freund pushed:

  • Centralize horizon determination for temp tables, fixing bug due to skew. This fixes a bug in the edge case where, for a temp table, heap_page_prune() can end up with a different horizon than heap_vacuum_rel(). Which can trigger errors like "ERROR: cannot freeze committed xmax ...". The bug was introduced due to interaction of a7212be8b9e "Set cutoff xmin more aggressively when vacuuming a temporary table." with dc7420c2c92 "snapshot scalability: Don't compute global horizons while building snapshots.". The problem is caused by lazy_scan_heap() assuming that the only reason its HeapTupleSatisfiesVacuum() call would return HEAPTUPLE_DEAD is if the tuple is a HOT tuple, or if the tuple's inserting transaction has aborted since the heap_page_prune() call. But after a7212be8b9e that was also possible in other cases for temp tables, because heap_page_prune() uses a different visibility test after dc7420c2c92. The fix is fairly simple: Move the special case logic for temp tables from vacuum_set_xid_limits() to the infrastructure introduced in dc7420c2c92. That ensures that the horizon used for pruning is at least as aggressive as the one used by lazy_scan_heap(). The concrete horizon used for temp tables is slightly different than the logic in dc7420c2c92, but should always be as aggressive as before (see comments). A significant benefit to centralizing the logic procarray.c is that now the more aggressive horizons for temp tables does not just apply to VACUUM but also to e.g. HOT pruning and the nbtree killtuples logic. Because isTopLevel is not needed by vacuum_set_xid_limits() anymore, I undid the the related changes from a7212be8b9e. This commit also adds an isolation test ensuring that the more aggressive vacuuming and pruning of temp tables keeps working. Debugged-By: Amit Kapila amit.kapila16 [AT] gmail.com Debugged-By: Tom Lane tgl [AT] sss.pgh.pa.us Debugged-By: Ashutosh Sharma ashu.coek88 [AT] gmail.com Author: Andres Freund andres [AT] anarazel.de Discussion: https://postgr.es/m/20201014203103.72oke6hqywcyhx7s@alap3.anarazel.de Discussion: https://postgr.es/m/20201015083735.derdzysdtqdvxshp@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/94bc27b57680b4e757577e3f5b65dc32f96d33c1

  • Fix wrong data table horizon computation during backend startup. When ComputeXidHorizons() was called before MyDatabaseOid is set, e.g. because a dead row in a shared relation is encountered during InitPostgres(), the horizon for normal tables was computed too aggressively, ignoring all backends connected to a database. During subsequent pruning in a data table the too aggressive horizon could end up still being used, possibly leading to still needed tuples being removed. Not good. This is a bug in dc7420c2c92, which the test added in 94bc27b5768 made visible, if run with force_parallel_mode set to regress. In that case the bug is reliably triggered, because "pruning_query" is run in a parallel worker and the start of that parallel worker is likely to encounter a dead row in pg_database. The fix is trivial: Compute a more pessimistic data table horizon if MyDatabaseId is not yet known. Author: Andres Freund Discussion: https://postgr.es/m/20201029040030.p4osrmaywhqaesd4@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/1c7675a7a4265064a2c8e1ed02b2c042c2521664

Noah Misch pushed:

Pending Patches

Peter Eisentraut sent in a patch to add a default_result_formats GUC, which specifies the default result formats by data type for rows returned in the extended query protocol when no result formats are specified in the Bind message.

Álvaro Herrera sent in another revision of a patch to add tracing to libpq.

Julien Rouhaud sent in two revisions of a patch to handle = operator in pg_trgm.

Álvaro Herrera sent in another revision of a patch to add batch and pipelining support to libpq.

Craig Ringer sent in a patch to report libpq version and configuration.

Jakub Wartak sent in two revisions of a patch to add "IO read time" log message to autoanalyze.

Alexander Korotkov and Andrey Borodin traded patches to use a shared lock, as opposed to an exclusive control lock, in GetMultiXactIdMembers for offsets and members, make the MultiXact local cache size configurable, add a conditional variable to wait for next MultXact offset in corner case, and add GUCs to tune MultiXact SLRUs.

Pavel Borisov sent in another revision of a patch to make GROUP BY more efficient by making it possible to reorder the columns.

Peter Geoghegan sent in another revision of a patch to add sort_template.h for making fast sort functions, and add delete deduplication to nbtree.

Michaël Paquier sent in another revision of a patch to fix checksum verification in base backups for zero page headers.

Ajin Cherian and Peter Smith traded patches to implement logical decoding for two-phase transactions.

Zhenghua Lyu sent in a patch to consider the case when stanullfrac is 1.0 in get_variable_numdistinct.

Konstantin Knizhnik sent in five more revisions of a patch to implement compression in libpq.

Justin Pryzby sent in a patch to remove deprecated v8.2 containment operators.

Peter Eisentraut sent in another revision of a patch to support for writing CREATE FUNCTION and CREATE PROCEDURE statements for language SQL with a function body that conforms to the SQL standard and is portable to other implementations.

Ibrar Ahmed sent in another revision of a patch to implement temporal PK/FK deletes and updates.

Justin Pryzby sent in another revision of a patch to pg_dump to output DISABLE/ENABLE for child triggers if their state does not match their parent.

Arseny Sher sent in a patch to fix a use-after-free.

Amit Kapila sent in a patch to make some minor improvements to the description of spilled counters in pg_stat_replication_slots view.

Dilip Kumar sent in three more revisions of a patch to implement custom compression methods for tables and ways to change same.

John Naylor sent in two revisions of a patch to use the standard symbol for the builtin function heap_tableam_handler().

Michaël Paquier sent in another revision of a patch to enable online checksum verification in the backend.

Greg Nancarrow sent in two more revisions of a patch to enable parallel SELECT for "INSERT INTO ... SELECT ...", where it is safe to do so, and enable parallel INSERT and/or SELECT for "INSERT INTO ... SELECT ...", where it is safe to do so.

Masahiko Sawada and Bertrand Drouvot traded patches to log the standby recovery conflict waits.

Vigneshwaran C sent in another revision of a patch to parallelize parts of COPY.

Daniel Gustafsson sent in four more revisions of a patch to support NSS as a libpq TLS backend.

Michaël Paquier, Fabrízio de Royes Mello, and Nikolay Samokhvalov traded patches to add important information about ANALYZE after creating an expressional index.

Justin Pryzby sent in a patch to implement CLUSTER for partitioned tables, reserve indisclustered on children of clustered, partitioned indexes, and invalidate indisclustered when attaching unclustered indexes.

Justin Pryzby sent in a WIP patch to implement DROP INDEX CONCURRENTLY for partitioned indexes.

Hayato Kuroda sent in a patch to fix an issue in pgbench where queries were firing before connections were established by adding a call to pthread_barrier_wait().

Hou Zhijie sent in a patch to enhance libpq to support multiple host for non hot standby.

Pavel Borisov sent in a patch to fix for bug when running Valgrind on OSX.

Amul Sul sent in another revision of a patch to implement ALTER SYSTEM READ {ONLY|WRITE}.

Justin Pryzby sent in another revision of a patch to ensure that all the pg_ls_* functions show directories and shared filesets.

Tsutomu Yamada sent in four revisions of a patch to add list extended stats to psql's \dX and \dX+.

Kirk Jamison sent in another revision of a patch to make dropping relation buffers more efficient using dlist.

Bruce Momjian sent in two more revisions of a patch to implement a key management system.

Xiao Bai Yan sent in another revision of a patch to extend the shared tuple store and add batch store module, and in passing, use atomic operations instead of LWLock for shared tuple stores when getting the next read page, and use this to implement parallel distinct union aggregates and grouping sets support using batch hash aggregate.

Amit Kapila sent in another revision of a patch to track statistics for streaming of changes from ReorderBuffer.

John Naylor sent in a patch to forbid custom pg type symbols.

Heikki Linnakangas and Andres Freund traded patches to deduplicate aggregates and transition functions in the planner.

Amit Langote sent in another revision of a patch to rearrange partition routing layering in nodeModifyTable.c.

Takamichi Osumi make it possible to disable WAL logging to speed up data loading.

John Naylor sent in four revisions of a patch to document the fact that pg_settings view doesn't display custom options.

Bharath Rupireddy sent in two more revisions of a patch to adds two new functions: pg_terminate_backend(pid, wait, timeout), which terminates and waits or times out for a given backend, and pg_wait_backend(pid, timeout), which checks for the existence of the backend with a given PID and waits or times out until it goes away.

Euler Taveira de Oliveira sent in a patch to control temporary file removal after a crash.

Vigneshwaran C sent in four revisions of a patch to add a log message to include GSS authentication, encryption & principal information.

Noah Misch sent in another revision of a patch to prevent excess SimpleLruTruncate() deletion, and unlink less in SimpleLruTruncate(), as insurance against bugs.

Takamichi Osumi sent in another revision of a patch to implement CREATE OR REPLACE TRIGGER.

Justin Pryzby sent in another revision of a patch to pg_dump: Allow child partitions to be independently restored, even if the parent doesn't exist, or has missing/incompatible columns.

Justin Pryzby sent in a patch to retire pg_standby and pg_archivecleanup.

Masahiko Sawada sent in a PoC patch that adds some xx_vacuum GUC parameters to control the method of recording TIDs.

Michaël Paquier sent in another revision of a patch to fix page verifications in base backups.

Masahiro Ikeda sent in another revision of a patch to add statistics to the pg_stat_wal view.

Justin Pryzby sent in another revision of a patch to allow INSERT SELECT to use a BulkInsertState, and use same to make INSERT SELECT use multi_insert.

Daniel Gustafsson sent in another revision of a patch to clean up contrib/sslinfo and OpenSSL error handling.

Amit Langote sent in another revision of a patch to make update/delete of inheritance trees scale better.

Tomáš Vondra and James Coleman traded patches to fix get_useful_pathkeys_for_relation for volatile exprs below joins, and add comments explaining where projections aren't necessary.

Thomas Munro sent in two more revisions of a patch to implement collation versioning.

Amit Langote sent in another revision of a patch to call BeginDirectModify from ExecInitModifyTable, and initialize result relation information lazily.

Amit Langote sent in another revision of a patch to fix a bug with RETURNING when UPDATE moves tuples.

Ashutosh Bapat sent in two more revisions of a patch to enumize logical replication message actions.

Jimmy Angelakos sent in a patch to clarify the wording for convalidated in pg_constraint.

John Naylor sent in a patch to document deviation from the standard on REVOKE ROLE.

Andrey Borodin sent in another revision of a patch to add Sortsupport for sorting GiST build for gist_btree types.

Tomáš Vondra sent in another revision of a patch to extend range type operators to cope with elements.

Heikki Linnakangas sent in a WIP patch to find all line-endings in COPY in chunks.

Jürgen Purtz, Erik Rijkers, and Justin Pryzby traded patches to add a new chapter to the tutorial.

Tomáš Vondra sent in another revision of a patch to add extra statistics to explain for Nested Loop.

Justin Pryzby sent in another revision of a patch to fix typos.

Justin Pryzby sent in another revision of a patch to allow CREATE INDEX CONCURRENTLY on partitioned table, add a SKIPVALID flag for more integration, and make eindexPartitions() set indisvalid.

Andrey V. Lepikhov sent in another revision of a patch to remove unneeded self-joins.

Ranier Vilela sent in a patch to fix a dereference before NULL check in src/backend/storage/ipc/latch.c.

Ranier Vilela sent in a patch to fix an explicit NULL dereference in src/backend/utils/adt/ruleutils.c.

Justin Pryzby sent in another revision of a patch to allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly.

Tom Lane sent in a patch to add a new CoercionForm variant, COERCE_SQL_SYNTAX.

Greg Sabino Mullane sent in another revision of a patch to help psql's \df choose functions by their arguments.

Tom Lane sent in a patch to get Gen_fmgrtab.pl to generate macros for all pg_proc entries.

Tom Lane sent in a patch to get rid of aggregate_dummy().

Kategóriák: Informatika

New PostgreSQL Core Team Members

2020, november 2 - 01:00

The PostgreSQL Core Team are pleased to announce the addition of two new members to Core: Andres Freund and Jonathan Katz.

Andres has been a contributor to PostgreSQL for over 10 years and a committer for 6. Areas he has concentrated on include replication, performance & scalability, storage and patch review.

Jonathan has been active in the PostgreSQL community for over a decade and contributes to various parts of the project, including advocacy, the release process, website development and maintenance, and other administrative functions. He currently serves as a Director on the boards of the United States PostgreSQL Association and the PostgreSQL Community Association of Canada, and was a member of the inaugural PostgreSQL Code of Conduct Committee.

The PostgreSQL Core Team handles several responsibilities for the project, which you can read about here.

Please join us in welcoming Andres and Jonathan to the Core Team.

Kategóriák: Informatika

Server side rollback at statement level for PostgreSQL

2020, november 2 - 01:00

Zurich, Switzerland - Nov 2nd, 2020

Server side rollback at statement level for PostgreSQL

The initial release v1.0 of pg_statement_rollback was released today.

pg_statement_rollback is a PostgreSQL extension to add server side transaction with rollback at statement level like in Oracle or DB2.

Statement-level rollback

If at any time during execution a SQL statement causes an error, all effects of the statement are rolled back. The effect of the rollback is as if that statement had never been run. This operation is called statement-level rollback and has the following characteristics:

  • A SQL statement that does not succeed causes the loss only of work it would have performed itself. The unsuccessful statement does not cause the loss of any work that preceded it in the current transaction.
  • The effect of the rollback is as if the statement had never been run.

In PostgreSQL the transaction cannot continue when you encounter an error and the entire work done in the transaction is rolled back. Oracle or DB2 have implicit savepoint before each statement execution which allow a rollback to the state just before the statement failure.

Current implementation of rollback at statement level for PostgreSQL is done at client side. psql has \set ON_ERROR_ROLLBACK on, JDBC has autorollback on SQL exception from executing a query, psqlODBC too with the "statement level rollback" mode. The problem of these implementations is that they add extra communication with the server by sending a SAVEPOINT autosave and RELEASE SAVEPOINT autosave so it can seriously limit the throughput of the application.

See documentation for a complete description of the feature and how to use of the extension.

Links & Credits

pg_statement_rollback is an open project from LzLabs (https://www.lzlabs.com/). Any contribution to build a better tool is welcome. You just have to send your ideas, features requests or patches using the GitHub tools.

Links :

Kategóriák: Informatika

Announcing the Release of pglogical 2.3.3

2020, október 29 - 01:00

Oxford, United Kingdom - October 5, 2020

2ndQuadrant is proud to announce the release of pglogical 2.3.3, the next generation in logical replication for PostgreSQL.

This release includes support for PostgreSQL 13, the latest major release of the world's most advanced open source database. PostgreSQL 13 includes brand new features and major improvements, such as partitioning and performance enhancements, increased security features, and more.

Implemented entirely as a PostgreSQL extension, pglogical is a logical replication system that serves as a highly efficient method of replicating data as an alternative to physical replication.

Download and installation instructions are available here.

For more information, please send an email to info@2ndQuadrant.com

Kategóriák: Informatika

pg_activity 1.6.2 has been released

2020, október 29 - 01:00

Paris, France - October 2020

pg_activity is a top-like interface to monitor backends on a PostgreSQL instance in real-time. Features, Installation, Usage, License... read all about it here.

Its version 1.6.2 has been released.

It fixes a bug with versions of PostgreSQL older than 9.2.

Useful Links About pg_activity

pg_activity is maintained by Benoit Lobréau. This is one of the Dalibo Labs projects.

Kategóriák: Informatika

pg_dumpbinary v2.3 released

2020, október 29 - 01:00

Grenoble, France - August 21th, 2020

pg_dumpbinary 2.3 released

pg_dumpbinary is a program used to dump a PostgreSQL database with data dumped in binary format. The resulting dump must be restored using pg_restorebinary that is provided with this tool.

pg_dumpbinary 2.3 was released today. This release fixes the setting of sequences values after restoring data from binary a dump where sequences values from PostgreSQL extensions was not restored.

pg_dumpbinary is useful in some particular situations:

  • you have bytea that can not be exported by pg_dump because the total size of the escape/hex output exceed 1Gb.
  • you have custom type that stores \0 internally in bytea but data are returned as char/varchar/text which truncate data after the '\0'. In this case pg_dump will export data in the output type which will result in data lost.
  • any other case where binary format can be useful.

If you are in this case pg_dumpbinary will help you by dumping the PostgreSQL database in binary format. In all other cases you must use the pg_dump/pg_restore commands distributed with PostgreSQL.

See documentation for a complete description of the features.

Links & Credits

pg_dumpbinary is an open project from LzLabs (https://www.lzlabs.com/). Any contribution to build a better tool is welcome. You just have to send your ideas, features requests or patches using the GitHub tools.

Links :

  • Documentation: https://github.com/lzlabs/pg_dumpbinary/blob/master/README.md
  • Download: https://github.com/lzlabs/pg_dumpbinary/releases/
  • Support: use GitHub report tool at https://github.com/lzlabs/pg_dumpbinary/issues
Kategóriák: Informatika

Pgpool-II 4.2 beta1 is now released.

2020, október 28 - 01:00

Pgpool Global Development Group is pleased to announce the availability of Pgpool-II 4.2 beta1. This is not intended to be used in production but is close to the release version. So users are encouraged to test it out.

Pgpool-II is a tool to add useful features to PostgreSQL, including:

  • connection pooling
  • load balancing
  • automatic fail over and more.

For more information, please see the website.

V4.2 contains new features and enhancements, including:

  • Some items in the configuration file pgpool.conf are vastly enhanced for easier configuration and administration.
  • Implement logging_collector for easier log management.
  • Implement log_disconnections to collect disconnection logs.
  • Implement pg_enc and pg_md5 to allow to register multiple passwords at once.
  • Allow to show statistics of health check by using SHOW POOL_HEALTH_CHECK_STATS command, and also allow to show statistics of issued SQL by using SHOW POOL_BACKEND_STATS command.
  • New PCP command pcp_reload_config is added.
  • Now it is possible to omit write_function_list and read_only_function_list by looking at system catalog information.
  • Add new clustering mode snapshot_isolation_mode which guarantees not only data modifications to multiple PostgreSQL but read consistency.
  • Support LDAP authentication between clients and Pgpool-II.
  • Add ssl_crl_file and ssl_passphrase_command to SSL configuration.
  • Import PostgreSQL 13's SQL parser.

You can download it from here

Please take a look at release notes

Kategóriák: Informatika

pgbitmap 0.9.3

2020, október 25 - 02:00

Announcing the latest Beta release of pgbitmap, available from pgxn and github.

pgbitmap provides a bitmap datatype for Postgres with a full set of functions, operators and aggregates.

This release fixes a number of issues with empty bitmaps and is considered a production release candidate. Any and all feedback is welcomed.

A bitmap is an array of bits, indexed by an integer. Bitmaps provide an efficient means to implement sets of integers. pgbitmap provides functions and operators for:

  • creating new bitmaps;
  • adding elements to bitmaps;
  • removing elements from bitmaps;
  • testing for inclusion of elements in bitmaps;
  • finding the minimum and maximum bits in bitmaps;
  • unioning bitmaps together (set union/logical or);
  • intersecting bitmaps (set intersection/logical and);
  • subtracting one bitmap from another;
  • converting bitmaps to and from textual representations;
  • converting bitmaps to and from arrays;
  • aggregating bits and bitmaps into bitmaps.

It differs from the standard Postgres bitstring in that it isn't based around bit zero (bitmap(1000000) does not contain 1,000,000 zeroes followed by a 1) and it has more functionality.

It was developed primarily in order to efficiently manage sets of privileges for Virtual Private Database implementations.

Full documentation is available here

Kategóriák: Informatika

Announcing the Release of repmgr 5.2.0

2020, október 23 - 02:00

Oxford, United Kingdom - 22 October, 2020

2ndQuadrant is proud to announce the release of repmgr 5.2.0. This major release adds support for PostgreSQL 13 and includes several general improvements, important enhancements, and bug fixes.

repmgr is the most popular tool for PostgreSQL replication and failover management that enhances the built-in replication capabilities in PostgreSQL. It simplifies daily management of standby servers and allows smooth execution of administrative tasks such as switchover operations. The automatic failover capability of repmgr allows maximum database uptime and can be combined with other tools such as PgBouncer for high availability.

repmgr 5.2.0 adds the new --verify-backup option to run PostgreSQL's pg_verifybackup utility after cloning a standby to verify the integrity of the copied data (PostgreSQL 13 and later).

Furthermore, repmgr 5.2.0 enhances the failover_validation_command with additional parameters and the configuration option always_promote that is used to control whether a node should be promoted if the repmgr metadata is not up-to-date.

5.2.0 also removes the support for PostgreSQL 9.3, which was designated EOL in November 2018.

For a detailed list of all changes, please read the complete release notes here.

Upgrading to this version is highly recommended for all repmgr users. Upgrade instructions are available here.

Packages and installation documentation are available via 2ndQuadrant’s public RPM and APT repositories from 2ndQuadrant here.

Source files can be downloaded here and installation instructions are available here.

repmgr is distributed under GPL v3.

For more information, please send an email to info@2ndQuadrant.com

Kategóriák: Informatika

Statement from the PostgreSQL Core Team on the EDB acquisition of 2ndQuadrant

2020, október 20 - 02:00

Recently, the acquisition of 2ndQuadrant by EDB was announced. This resulted in the Core Team’s membership consisting of a majority of members being employed by EDB.

There has long been an unwritten rule that there should be no more than 50% of the membership of the Core Team working for the same company. As a result, there has been a lively ongoing discussion within the core team on how to best resolve this issue. For obvious reasons we do not want to rush into making changes.

We are aware that this has taken longer than expected, and apologise for any concern this may have caused in the community. Rest assured we are actively working to resolve the issue in a way that benefits the project, and will announce details as soon as possible once they are finalised.

Kategóriák: Informatika

PostgreSQL JDBC 42.2.18 Released

2020, október 17 - 02:00

Unfortunately the fixes in 42.2.17 weren't quite enough to fix the problem with gssEncMode. 42.2.18 has (hopefully) fixed them. See the details in the release notes

Kategóriák: Informatika

pgAdmin 4 v4.27 Released

2020, október 16 - 02:00

The pgAdmin Development Team is pleased to announce pgAdmin 4 version 4.27. This release of pgAdmin 4 includes 28 bug fixes and new features. For more details please see the release notes.

pgAdmin is the leading Open Source graphical management tool for PostgreSQL. For more information, please see the website.

Notable changes in this release include:

  • Added Macro support.
  • Added support to view trigger function under the respective trigger node.
  • Allow user to change the database connection from an open query tool tab.
  • Added support to ignore the owner while comparing objects in the Schema Diff tool.
  • Merged the latest code of 'pgcli' used for the autocomplete feature.
  • Fixed invalid literal issue when fetching dependencies for Materialized View.
  • Fixed an issue where schema diff is showing identical table as different due to default vacuum settings.
  • Ensure that the user should be able to change the start value of the existing sequence.
  • Fixed an issue where the query tool is not fetching more than 1000 rows for the table does not have any primary key.
  • Fixed an issue where 'Rows X' column values were not visible properly for Explain Analyze in Dark theme.
  • Fixed an issue where file extension is stripped on renaming a file.

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.

Kategóriák: Informatika

Ora2Pg v21.0 has been released

2020, október 13 - 02:00

Grenoble, France - October 12th, 2020

Ora2Pg 21.0 released

Version 21.0 of Ora2Pg, a free and reliable tool used to migrate an Oracle database to PostgreSQL, has been officially released and is publicly available for download.

This release fix several issues reported since last release and adds several new features and improvements.

New features and improvements
  • Add clause OVERRIDING SYSTEM VALUE to INSERT statements when the table has an IDENTITY column.
  • Considerably increase the speed to generate the report about the migration assessment, especially for database with huge number of objects.
  • Reduce time passed in the progress bar. Following the number of database objects we were spending too much time in refreshing the progress bar.
  • Add number of identity columns in migration assessment report.
  • Make assessment details report initially hidden using HTML5 tags details+summary
  • Improve speed of BLOB/CLOB data export. Oracle recommends reading from and writing to a LOB in batches using a multiple of the LOB chunk size. This chunk size defaults to 8k (8192). Recent tests show that the best performances can be reach with higher value like 512K or 4Mb.
  • Add progress bar when --oracle_speed is use in single process mode.
  • Automatically activate USER_GRANTS when the connection user has no DBA privilege. A warning is displayed.
  • Complete port to Windows by using the Windows separator on stdout redirection into a file at ora2pg command line call and improve ora2pg_scanner port on Windows OS.
  • Add rewrite of MySQL JOIN with WHERE clause instead of ON.
  • Add MGDSYS (Oracle E-Business Suite) and APEX_040000 to the list of schemas excluded from the export.
  • Supply credentials interactively when a password is not defined in the configuration file. Need the installation of a new Perl module Term::ReadKey.
  • Add supports oracle connections "as sysdba" with username "/" and an empty password to connect to a local oracle instance.
  • Add translation of PRIVATE TEMPORARY TABLE from Oracle 18c into PostgreSQL basic temporary table, only the default behavior for on commit change.
New command line options
  • Add new command line option to ora2pg_scanner: -b | --binpath DIR to set the full path to directory where the ora2pg binary stays. Might be useful only on Windows OS.
  • Add -r | --relative command line option and PSQL_RELATIVE_PATH configuration directive. By default Ora2Pg use \i psql command to execute generated SQL files if you want to use a relative path following the script execution file enabling this option will use \ir. See psql help for more information.
New configuration directives
  • NO_VIEW_ORDERING by default Ora2Pg try to order views to avoid error at import time with nested views. With a huge number of views this can take a very long time, you can bypass this ordering by enabling this directive.
  • NO_FUNCTION_METADATA: force Ora2Pg to not look for function declaration. This will prevent Ora2Pg to rewrite function replacement call if needed. Do not enable it unless looking forward at function breaks other export.
  • LOB_CHUNK_SIZE: see explanation in the new features and improvement list about BLOB/CLOB export speed improvement.
  • ALTERNATIVE_QUOTING_REGEXP: to support the Alternative Quoting Mechanism ('Q' or 'q') for String Literals set the regexp with the text capture to use to extract the text part. The value of this directive can be a list of regexp separated by a semi colon. The capture part is mandatory in each regexp if you want to restore the string constant.
Backward compatibility changes
  • Default for NO_LOB_LOCATOR is now 1 to benefit from LOB_CHUNK_SIZE performances gain.
  • Enable schema compilation (COMPILE_SCHEMA set to 1) by default to speed up DDL extraction.
  • Change the behavior of Ora2Pg with the parameters that follows a parameter with a default value. Ora2Pg used to change the order of the parameters function to put all parameters with a default value at end of the list which need a function call rewrite. This have been abandoned, any parameter without default value after a parameter with a default value will now be appended with DEFAULT NULL.

For a complete list of change see https://github.com/darold/ora2pg/blob/master/changelog

Thanks to all contributors, they are all cited in the changelog file.

Useful Links
  • Website: http://www.ora2pg.com/
  • Download1: https://github.com/darold/ora2pg/releases
  • Download2: http://sourceforge.net/projects/ora2pg/
  • Development: https://github.com/darold/ora2pg
  • Changelog: https://github.com/darold/ora2pg/blob/master/changelog
  • Documentation: http://www.ora2pg.com/documentation.html

  • Global Temporary Tables for PostgreSQL extension: https://github.com/darold/pgtt

  • BFILE for PostgreSQL extension: https://github.com/darold/external_file
About Ora2Pg

Ora2Pg is an easy and reliable tool to migrate from Oracle to PostgreSQL. It is developed since 2001 by Gilles Darold and can export most of the Oracle objects (table, view, materialized view, tablespace, sequence, indexes, trigger, grant, function, procedure, package, partition, data, blob, external table, etc.).

Ora2Pg works on any platform and is available under the GPL v3 license.

Docs, Download & Support at http://www.ora2pg.com/

Kategóriák: Informatika

New Members of the Community Code of Conduct Committee

2020, október 13 - 02:00

Today, the PostgreSQL Community Code of Conduct Committee welcomes three new members:

Jeanette Bromage is a Principal DBA at Kira Systems. Prior to this, she took a three year break from managing databases to concentrate on AWS/Linux system administration. Jeanette has worked with various database technologies across different platforms for over twenty years, including a three year stint as a C programmer.

Fábio Telles Rodriguez is a Database Consultant and co-founder of Timbira, in Brazil. He is a co-organizer of both PGConf.Brazil and Brazilian PUG. He organizes and speaks in many other conferences in his country.

Anastasia Lubennikova is a Senior Developer at Postgres Professional and a PostgreSQL Global Development Group Contributor. She contributes to the PostgreSQL community as a core developer and speaker. As a part of her job, she also helps with mentoring and onboarding new developers.

Ilya Kosmodemiansky, who served on the initial Committee, is stepping down this year. We appreciate his involvement the past two years.

There will be a short transition period, ending October 31, 2020 to allow the transfer of information and responsibilities. The new term runs through September 30, 2021.

The continuing Committee members are:

Stacey Haysler (Chair) is the CFO and COO of PostgreSQL Experts, Inc., in Alameda, California. She is a PostgreSQL Global Development Group Contributor, and the President of the United States PostgreSQL Association (PgUS). She has worked as an organizer and conference staff for a number of conferences, both in North America and Europe, and is also a principal organizer of the San Francisco PostgreSQL Users’ Group.

Jonathan S. Katz is the Vice President of Platform Engineering at Crunchy Data, and lives in New York. He is a PostgreSQL Global Development Group Major Contributor focused on advocacy, the website, and releases, and also serves on the boards of the United States PostgreSQL Association & the PostgreSQL Community Association of Canada.

Carole Arnaud is an executive board member of Dalibo and team manager. She lives in Nantes, France. She was part of the PGDay France committee from 2015 to 2018, and has been a co-organizer of pgDay Paris since 2018.

Umair Shahid is a Member of the Marketing Leadership at EDB and is based in Islamabad, Pakistan. He serves as a member of PgUS User Group committee along with being the organizer for Islamabad and Dubai PostgreSQL Users' Groups.

The Committee is comprised of 4 women, 3 men, and 0 nonbinary individuals. No two members work at the same company.

We have again expanded our geographical diversity, which now includes our first member from South America. The specific country representation is:

  • Brazil: 1
  • France: 1
  • Pakistan: 1
  • Russian Federation: 1
  • United Kingdom: 1
  • United States: 2

The full list of Committee members is always available at: https://www.postgresql.org/about/policies/coc_committee/

The Committee can be contacted at coc@postgresql.org.

Kategóriák: Informatika

Announcing Memhive PostgreSQL

2020, október 13 - 02:00

Memhive PostgreSQL acceleration with Persistent Memory (PMEM) is now available! Memhive PostgreSQL has been built on PMDK and accelerates storage and memory access using libpmem. Our benchmarking with Intel Optane PMEM has yielded impressive results!

Advantages of Memhive PostgreSQL:
  • Scaling up performance: PMEM resident persistent cache, fast WAL and relational data files..
  • Reduction in TCO: Lower DRAM and fast SSD capacity requirement.
  • Easy upgrade: no change to client-side behavior, core business logic or on-disk layout.
More information:

Visit our website: https://www.memhive.io

Write to us at: info@memhive.io

Kategóriák: Informatika

PostgreSQL JDBC 42.2.17 released

2020, október 10 - 02:00

Due to some small issues with the way GSS Encryption was implemented we have released 42.2.17. The major change is not to attempt a GSS Encrypted connection by default.

There were a number of small issues fixed:

  • Avoid NullPointerException when receiving PGbox, PGcircle, PGline, PGlseg, PGpath, PGpoint, PGpolygon, and PGmoney PR 1873..
  • The driver returns enum and jsonb arrays elements as String objects (like in 42.2.14 and earlier versions) PR 1879.
  • PgTokenizer was ignoring last empty token PR #1882
  • Remove osgi from karaf fixes Issue #1891 PR #1902

See the complete list of changes here

Thanks to everyone who contributed !

Kategóriák: Informatika

Crunchy PostgreSQL Operator 4.5: Enhanced Monitoring, Custom Annotations, PostgreSQL 13

2020, október 6 - 02:00

Crunchy Data is pleased to announce the release of the Crunchy PostgreSQL Operator 4.5, which automates and simplifies deploying and managing open source PostgreSQL clusters on Kubernetes and other Kubernetes-enabled Platforms. Instructions for getting started with the PostgreSQL Operator can be found here:

https://access.crunchydata.com/documentation/postgres-operator/latest/quickstart/

This release makes several changes to the PostgreSQL Operator Monitoring solution, notably making it much easier to set up a turnkey PostgreSQL monitoring with the PostgreSQL Operator using the open source pgMonitor project.

pgMonitor combines insightful queries for PostgreSQL with several proven tools for statistics collection, data visualization, and alerting to allow one to deploy a turnkey monitoring solution for PostgreSQL. Now with support for Kubernetes environments, pgMonitor uses open source pgnodemx that allows one to get host-like information from the Kubernetes Pod a PostgreSQL instance is deployed within.

Major features of the 4.5 release include:

For a full list of features, including detailed descriptions of these changes, please see the release notes.

Links

Crunchy Data is proud to support the development and maintenance of the PostgreSQL Operator.

Kategóriák: Informatika

DB Doc 8.0 released

2020, október 6 - 02:00

Yohz Software has released DB Doc 8.0, the PostgreSQL schema documentation tool, and is available for immediate download.

Changes in this version:

  • Added support for PostgreSQL 13
  • Added support for materialized views
  • Updated the HTML noframes layout
  • Updated the HTML preview window

DB Doc benefits:

  • Document a PostgreSQL database in 5 simple steps
  • Create documentation in HTML, XML, PDF, CHM, and MS Word formats. You can view the samples here
  • View database statistics like the largest tables and indexes in each database
  • Document layouts are fully customizable to suit your requirements
  • Eliminate tedious and time-consuming manual documentation tasks
  • Satisfy audit requirements by keeping complete and timely documentation
  • View inter-object and inter-database dependencies in your documents
  • Keep teams up to date by distributing timely and accurate documentation
  • Supports PostgreSQL 8.3 and newer, without the need for any additional database drivers.
  • Runs on Windows 7 to Windows 10

For more details about DB Doc, please visit the product page. DB Doc-related technical blogs are available here.

Kategóriák: Informatika

pgmetrics 1.10 released

2020, október 6 - 02:00

Hello All,

We're happy to announce the release of v1.10 of pgmetrics. Changes since the v1.9 release include:

  • Support for Postgres 13
  • Collect information from Citus and Microsoft Azure Hyperscale Citus (more info here [1])
  • Support for CSV-format logs
  • Support for processing multiple log files in one run
  • Option to collect from all available databases of a cluster
  • Option to specify lock timeout
  • Various bug fixes

You can get the latest release from GitHub [2].

Thanks to all the people who pitched in with bug reports, suggestions and patches! Keep it coming!

About pgmetrics

pgmetrics is an open-source, zero-dependency, single-binary tool that can collect a lot of information and statistics from a running PostgreSQL server and display it in easy-to-read text format or export it as JSON or CSV for scripting, monitoring and automation.

Learn more at https://pgmetrics.io/, or see a sample report here [3].

pgmetrics is an open-source project of RapidLoop [4].

[1] https://pgmetrics.io/docs/citus.html [2] https://github.com/rapidloop/pgmetrics/releases [3] https://pgmetrics.io/docs/index.html#example [4] https://www.rapidloop.com

Regards, -Mahadevan

Kategóriák: Informatika

Oldalak

Theme by me