pgsql: To improve the code, move the error check in logical_read_xlog_p

To improve the code, move the error check in logical_read_xlog_page(). Commit 0fdab27ad6 changed the code to wait for WAL to be available before determining the timeline but forgot to move the failure check. This change is to make the related code easier to understand and enhance otherwise there

pgsql: Use pgstat_kind_infos to write fixed shared statistics

Use pgstat_kind_infos to write fixed shared statistics This is similar to 9004abf6206e, but this time for the write part of the stats file. The code is changed so as, rather than referring to individual members of PgStat_Snapshot in an order based on their PgStat_Kind value, a loop based on pgsta

pgsql: Avoid JIT-related test instability in EXPLAIN ANALYZE

Avoid JIT-related test instability in EXPLAIN ANALYZE 036bdcec9 added some code to perform some verification on portions of the planner costs in EXPLAIN ANALYZE but failed to consider that some buildfarm animals such as bushmaster and taipan are running very low jit thresholds. This caused these

pgsql: Revert "Force nodes for SSL tests to start in TCP mode"

Revert "Force nodes for SSL tests to start in TCP mode" This reverts commit 198088dc63de4f89835419969c7b5d1640be3441. This is causing errors on Release 12, so revert for now to keep the buildfarm green. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8b03d74

pgsql: Fix limit block handling in pg_wal_summary_contents().

Fix limit block handling in pg_wal_summary_contents(). Previously, pg_wal_summary_contents() had two issues, causing discrepancies between pg_wal_summary_contents() and the pg_walsummary command on the same WAL summary file: (1) It did not emit the limit block when that's the only data for a

pgsql: Fix limit block handling in pg_wal_summary_contents().

Fix limit block handling in pg_wal_summary_contents(). Previously, pg_wal_summary_contents() had two issues, causing discrepancies between pg_wal_summary_contents() and the pg_walsummary command on the same WAL summary file: (1) It did not emit the limit block when that's the only data for a

pgsql: Show Parallel Bitmap Heap Scan worker stats in EXPLAIN ANALYZE

Show Parallel Bitmap Heap Scan worker stats in EXPLAIN ANALYZE Nodes like Memoize report the cache stats for each parallel worker, so it makes sense to show the exact and lossy pages in Parallel Bitmap Heap Scan in a similar way. Likewise, Sort shows the method and memory used for each worker. T

Re: pgsql: Teach planner how to estimate rows for timestamp generate_series

On Tue, 9 Jul 2024 at 09:55, David Rowley wrote: > src/test/regress/expected/misc_functions.out | 110 +++ > src/test/regress/sql/misc_functions.sql | 84 I'll look at fixing bushmaster [1] shortly. David [1] https://buildfarm.postgresql.org/cgi

pgsql: Perform forgotten cat version bump

Perform forgotten cat version bump I missed this in 036bdcec9 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e41f7130979442362d9053d1ae24b2f87980e842 Modified Files -- src/include/catalog/catversion.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-

pgsql: Teach planner how to estimate rows for timestamp generate_series

Teach planner how to estimate rows for timestamp generate_series This provides the planner with row estimates for generate_series(TIMESTAMP, TIMESTAMP, INTERVAL), generate_series(TIMESTAMPTZ, TIMESTAMPTZ, INTERVAL) and generate_series(TIMESTAMPTZ, TIMESTAMPTZ, INTERVAL, TEXT) when the input parame

pgsql: Symlink pg_replslot robustly on Windows in pg_basebackup test

Symlink pg_replslot robustly on Windows in pg_basebackup test This reverts commit e9f15bc9. Instead of a hacky solution that didn't work on Windows, we avoid trying to move the directory possibly across drives, and instead remove it and recreate it in the new location. Discussion: https://postgr

pgsql: Symlink pg_replslot robustly on Windows in pg_basebackup test

Symlink pg_replslot robustly on Windows in pg_basebackup test This reverts commit e9f15bc9. Instead of a hacky solution that didn't work on Windows, we avoid trying to move the directory possibly across drives, and instead remove it and recreate it in the new location. Discussion: https://postgr

pgsql: Symlink pg_replslot robustly on Windows in pg_basebackup test

Symlink pg_replslot robustly on Windows in pg_basebackup test This reverts commit e9f15bc9. Instead of a hacky solution that didn't work on Windows, we avoid trying to move the directory possibly across drives, and instead remove it and recreate it in the new location. Discussion: https://postgr

pgsql: Symlink pg_replslot robustly on Windows in pg_basebackup test

Symlink pg_replslot robustly on Windows in pg_basebackup test This reverts commit e9f15bc9. Instead of a hacky solution that didn't work on Windows, we avoid trying to move the directory possibly across drives, and instead remove it and recreate it in the new location. Discussion: https://postgr

pgsql: Symlink pg_replslot robustly on Windows in pg_basebackup test

Symlink pg_replslot robustly on Windows in pg_basebackup test This reverts commit e9f15bc9. Instead of a hacky solution that didn't work on Windows, we avoid trying to move the directory possibly across drives, and instead remove it and recreate it in the new location. Discussion: https://postgr

pgsql: Use CREATE DATABASE ... STRATEGY = FILE_COPY in pg_upgrade.

Use CREATE DATABASE ... STRATEGY = FILE_COPY in pg_upgrade. While this strategy is ordinarily quite costly because it requires performing two checkpoints, testing shows that it tends to be a faster choice than WAL_LOG during pg_upgrade, presumably because fsync is turned off. Furthermore, we can

pgsql: Force nodes for SSL tests to start in TCP mode

Force nodes for SSL tests to start in TCP mode Currently they are started in unix socket mode in ost cases, and then converted to run in TCP mode. This can result in port collisions, and there is no virtue in startng in unix socket mode, so start as we will be going on. Discussion: https://postgr

pgsql: Choose ports for test servers less likely to result in conflicts

Choose ports for test servers less likely to result in conflicts If we choose ports in the range typically used for ephemeral ports there is a danger of encountering a port conflict due to a race condition between the time we choose the port in a range below that typically used to allocate ephemer

pgsql: Force nodes for SSL tests to start in TCP mode

Force nodes for SSL tests to start in TCP mode Currently they are started in unix socket mode in ost cases, and then converted to run in TCP mode. This can result in port collisions, and there is no virtue in startng in unix socket mode, so start as we will be going on. Discussion: https://postgr

pgsql: Force nodes for SSL tests to start in TCP mode

Force nodes for SSL tests to start in TCP mode Currently they are started in unix socket mode in ost cases, and then converted to run in TCP mode. This can result in port collisions, and there is no virtue in startng in unix socket mode, so start as we will be going on. Discussion: https://postgr

pgsql: Force nodes for SSL tests to start in TCP mode

Force nodes for SSL tests to start in TCP mode Currently they are started in unix socket mode in ost cases, and then converted to run in TCP mode. This can result in port collisions, and there is no virtue in startng in unix socket mode, so start as we will be going on. Discussion: https://postgr

pgsql: Choose ports for test servers less likely to result in conflicts

Choose ports for test servers less likely to result in conflicts If we choose ports in the range typically used for ephemeral ports there is a danger of encountering a port conflict due to a race condition between the time we choose the port in a range below that typically used to allocate ephemer

pgsql: Choose ports for test servers less likely to result in conflicts

Choose ports for test servers less likely to result in conflicts If we choose ports in the range typically used for ephemeral ports there is a danger of encountering a port conflict due to a race condition between the time we choose the port in a range below that typically used to allocate ephemer

pgsql: Force nodes for SSL tests to start in TCP mode

Force nodes for SSL tests to start in TCP mode Currently they are started in unix socket mode in ost cases, and then converted to run in TCP mode. This can result in port collisions, and there is no virtue in startng in unix socket mode, so start as we will be going on. Discussion: https://postgr

pgsql: Choose ports for test servers less likely to result in conflicts

Choose ports for test servers less likely to result in conflicts If we choose ports in the range typically used for ephemeral ports there is a danger of encountering a port conflict due to a race condition between the time we choose the port in a range below that typically used to allocate ephemer

pgsql: Choose ports for test servers less likely to result in conflicts

Choose ports for test servers less likely to result in conflicts If we choose ports in the range typically used for ephemeral ports there is a danger of encountering a port conflict due to a race condition between the time we choose the port in a range below that typically used to allocate ephemer

pgsql: Choose ports for test servers less likely to result in conflicts

Choose ports for test servers less likely to result in conflicts If we choose ports in the range typically used for ephemeral ports there is a danger of encountering a port conflict due to a race condition between the time we choose the port in a range below that typically used to allocate ephemer

pgsql: Force nodes for SSL tests to start in TCP mode

Force nodes for SSL tests to start in TCP mode Currently they are started in unix socket mode in ost cases, and then converted to run in TCP mode. This can result in port collisions, and there is no virtue in startng in unix socket mode, so start as we will be going on. Discussion: https://postgr

pgsql: Choose ports for test servers less likely to result in conflicts

Choose ports for test servers less likely to result in conflicts If we choose ports in the range typically used for ephemeral ports there is a danger of encountering a port conflict due to a race condition between the time we choose the port in a range below that typically used to allocate ephemer

pgsql: Force nodes for SSL tests to start in TCP mode

Force nodes for SSL tests to start in TCP mode Currently they are started in unix socket mode in ost cases, and then converted to run in TCP mode. This can result in port collisions, and there is no virtue in startng in unix socket mode, so start as we will be going on. Discussion: https://postgr

pgsql: Use xmlParseInNodeContext not xmlParseBalancedChunkMemory.

Use xmlParseInNodeContext not xmlParseBalancedChunkMemory. xmlParseInNodeContext has basically the same functionality with a different API: we have to supply an xmlNode that's attached to a document rather than just the document. That's not hard though. The benefits are two: * Early 2.13.x relea

pgsql: Fix scale clamping in numeric round() and trunc().

Fix scale clamping in numeric round() and trunc(). The numeric round() and trunc() functions clamp the scale argument to the range between +/- NUMERIC_MAX_RESULT_SCALE (2000), which is much smaller than the actual allowed range of type numeric. As a result, they return incorrect results when asked

pgsql: Fix scale clamping in numeric round() and trunc().

Fix scale clamping in numeric round() and trunc(). The numeric round() and trunc() functions clamp the scale argument to the range between +/- NUMERIC_MAX_RESULT_SCALE (2000), which is much smaller than the actual allowed range of type numeric. As a result, they return incorrect results when asked

pgsql: Fix scale clamping in numeric round() and trunc().

Fix scale clamping in numeric round() and trunc(). The numeric round() and trunc() functions clamp the scale argument to the range between +/- NUMERIC_MAX_RESULT_SCALE (2000), which is much smaller than the actual allowed range of type numeric. As a result, they return incorrect results when asked

pgsql: Fix scale clamping in numeric round() and trunc().

Fix scale clamping in numeric round() and trunc(). The numeric round() and trunc() functions clamp the scale argument to the range between +/- NUMERIC_MAX_RESULT_SCALE (2000), which is much smaller than the actual allowed range of type numeric. As a result, they return incorrect results when asked

pgsql: Fix scale clamping in numeric round() and trunc().

Fix scale clamping in numeric round() and trunc(). The numeric round() and trunc() functions clamp the scale argument to the range between +/- NUMERIC_MAX_RESULT_SCALE (2000), which is much smaller than the actual allowed range of type numeric. As a result, they return incorrect results when asked

pgsql: Fix scale clamping in numeric round() and trunc().

Fix scale clamping in numeric round() and trunc(). The numeric round() and trunc() functions clamp the scale argument to the range between +/- NUMERIC_MAX_RESULT_SCALE (2000), which is much smaller than the actual allowed range of type numeric. As a result, they return incorrect results when asked

pgsql: Fix scale clamping in numeric round() and trunc().

Fix scale clamping in numeric round() and trunc(). The numeric round() and trunc() functions clamp the scale argument to the range between +/- NUMERIC_MAX_RESULT_SCALE (2000), which is much smaller than the actual allowed range of type numeric. As a result, they return incorrect results when asked

pgsql: Typo fix

Typo fix Reported-by: Junwang Zhao Discussion: https://postgr.es/m/CAEG8a3KPi=layitwj11ikf7bcqnzurcj8ngx0v8no1mqkz9...@mail.gmail.com Backpatch-through: 17 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/519d710720159046c90c08095e70fdb486d38053 Modified Files ---

pgsql: Typo fix

Typo fix Reported-by: Junwang Zhao Discussion: https://postgr.es/m/CAEG8a3KPi=layitwj11ikf7bcqnzurcj8ngx0v8no1mqkz9...@mail.gmail.com Backpatch-through: 17 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d4f8517b0b9436fa3478851024870d8ee0b67801 Modified Fi

pgsql: Fix outdated comment after removal of direct SSL fallback

Fix outdated comment after removal of direct SSL fallback The option to fall back from direct SSL to negotiated SSL or a plaintext connection was removed in commit fb5718f35f. Discussion: https://www.postgresql.org/message-id/c82ad227-e049-4e18-8898-475a748b5...@iki.fi Branch -- REL_17_STAB

pgsql: Fix outdated comment after removal of direct SSL fallback

Fix outdated comment after removal of direct SSL fallback The option to fall back from direct SSL to negotiated SSL or a plaintext connection was removed in commit fb5718f35f. Discussion: https://www.postgresql.org/message-id/c82ad227-e049-4e18-8898-475a748b5...@iki.fi Branch -- master Det