pgsql: Check status of nodes after regression test run in 027_stream_re

2025-07-18 Thread Michael Paquier
Check status of nodes after regression test run in 027_stream_regress This commit improves the recovery TAP test 027_stream_regress so as regression diffs are printed only if both the primary and the standby are still alive after the main regression test suite finishes, relying on d4c9195eff41 to

pgsql: Add PostgreSQL::Test::Cluster::is_alive()

2025-07-18 Thread Michael Paquier
Add PostgreSQL::Test::Cluster::is_alive() This new routine acts as a wrapper of pg_isready, that can be run on a node to check its connection status. This will be used in a recovery test in a follow-up commit. Suggested-by: Andres Freund Author: Nazir Bilal Yavuz Discussion: https://postgr.es

pgsql: Speed up byteain by not parsing traditional-style input twice.

2025-07-18 Thread Tom Lane
Speed up byteain by not parsing traditional-style input twice. Instead of laboriously computing the exact output length, use strlen to get an upper bound cheaply. (This is still O(N) of course, but the constant factor is a lot less.) This will typically result in overallocating the output datum,

pgsql: Remove unused variable in generate-lwlocknames.pl.

2025-07-18 Thread Nathan Bossart
Remove unused variable in generate-lwlocknames.pl. Oversight in commit da952b415f. Author: Bertrand Drouvot Discussion: https://postgr.es/m/aHpOgwuFQfcFMZ/B%40ip-10-97-1-34.eu-west-3.compute.internal Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/84409ed640568d8

pgsql: pg_upgrade: Use COPY for large object metadata.

2025-07-18 Thread Nathan Bossart
pg_upgrade: Use COPY for large object metadata. Presently, pg_dump generates commands like SELECT pg_catalog.lo_create('5432'); ALTER LARGE OBJECT 5432 OWNER TO alice; GRANT SELECT ON LARGE OBJECT 5432 TO bob; for each large object. This is particularly slow at restore time, especia

pgsql: Fix a typo in the deparseArrayCoerceExpr() header comment

2025-07-18 Thread Alexander Korotkov
Fix a typo in the deparseArrayCoerceExpr() header comment Discussion: https://postgr.es/m/CAHewXNn%3D_ykCtcTw5SCfZ-eVr4m%2BCuc804rGeMsKuj%3DD4xpL4w%40mail.gmail.com Author: Tender Wang Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4c5159a2d8c01e6f08ce20a51bb2dca

pgsql: Fix concurrent update trigger issues with MERGE in a CTE.

2025-07-18 Thread Dean Rasheed
Fix concurrent update trigger issues with MERGE in a CTE. If a MERGE inside a CTE attempts an UPDATE or DELETE on a table with BEFORE ROW triggers, and a concurrent UPDATE or DELETE happens, the merge code would fail (crashing in the case of an UPDATE action, and potentially executing the wrong ac

pgsql: Fix concurrent update trigger issues with MERGE in a CTE.

2025-07-18 Thread Dean Rasheed
Fix concurrent update trigger issues with MERGE in a CTE. If a MERGE inside a CTE attempts an UPDATE or DELETE on a table with BEFORE ROW triggers, and a concurrent UPDATE or DELETE happens, the merge code would fail (crashing in the case of an UPDATE action, and potentially executing the wrong ac

pgsql: Fix concurrent update trigger issues with MERGE in a CTE.

2025-07-18 Thread Dean Rasheed
Fix concurrent update trigger issues with MERGE in a CTE. If a MERGE inside a CTE attempts an UPDATE or DELETE on a table with BEFORE ROW triggers, and a concurrent UPDATE or DELETE happens, the merge code would fail (crashing in the case of an UPDATE action, and potentially executing the wrong ac

pgsql: Support for deparsing of ArrayCoerceExpr node in contrib/postgre

2025-07-18 Thread Alexander Korotkov
Support for deparsing of ArrayCoerceExpr node in contrib/postgres_fdw When using a prepared statement to select data from a PostgreSQL foreign table (postgres_fdw) with the "field = ANY($1)" expression, the operation is not pushed down when an implicit type case is applied, and a generic plan is u