pgsql: Remove duplicate assignment when initializing logical decoder co

Remove duplicate assignment when initializing logical decoder context The private data in the WAL reader is already getting set when allocating it. Author: Antonin Houska Reviewed-by: Tom Lane Discussion: https://postgr.es/m/30563.1555329094@localhost Branch -- master Details --- https:

Re: pgsql: Consistently test for in-use shared memory.

Noah Misch writes: > No. We expect never to run one; it was there for the unexpected case of > "postgres --single" startup succeeding. I pushed a change to close the stdin > of "postgres --single" instead of writing to it. Ah, good, that's safer than what I was imagining. > I probably worried

Re: pgsql: Consistently test for in-use shared memory.

On Mon, Apr 15, 2019 at 09:01:45PM -0400, Tom Lane wrote: > Noah Misch writes: > >> Perhaps I should write the 'SELECT 1 + 1' to a regular file and redirect > >> input > >> from that file. > > Actually ... we don't need to run a query at all do we? No. We expect never to run one; it was there

pgsql: Don't write to stdin of a test process that could have already e

Don't write to stdin of a test process that could have already exited. Instead, close that stdin. Per buildfarm member conchuela. Back-patch to 9.6, where the test was introduced. Discussion: https://postgr.es/m/26478.1555373...@sss.pgh.pa.us Branch -- REL_10_STABLE Details --- https:

pgsql: Don't write to stdin of a test process that could have already e

Don't write to stdin of a test process that could have already exited. Instead, close that stdin. Per buildfarm member conchuela. Back-patch to 9.6, where the test was introduced. Discussion: https://postgr.es/m/26478.1555373...@sss.pgh.pa.us Branch -- master Details --- https://git.p

pgsql: Don't write to stdin of a test process that could have already e

Don't write to stdin of a test process that could have already exited. Instead, close that stdin. Per buildfarm member conchuela. Back-patch to 9.6, where the test was introduced. Discussion: https://postgr.es/m/26478.1555373...@sss.pgh.pa.us Branch -- REL9_6_STABLE Details --- https:

pgsql: Don't write to stdin of a test process that could have already e

Don't write to stdin of a test process that could have already exited. Instead, close that stdin. Per buildfarm member conchuela. Back-patch to 9.6, where the test was introduced. Discussion: https://postgr.es/m/26478.1555373...@sss.pgh.pa.us Branch -- REL_11_STABLE Details --- https:

Re: pgsql: Consistently test for in-use shared memory.

Noah Misch writes: >> Perhaps I should write the 'SELECT 1 + 1' to a regular file and redirect >> input >> from that file. Actually ... we don't need to run a query at all do we? Although this would only help if Perl will optimize away an attempt to write zero bytes to the pipe, which seems lik

Re: pgsql: Consistently test for in-use shared memory.

Noah Misch writes: > On Mon, Apr 15, 2019 at 08:08:48PM -0400, Tom Lane wrote: >> I interpret this as "the single-user backend exited before we could stuff >> 'SELECT 1 + 1' down the pipe to it, and the Perl script is not expecting >> to get a write failure there". > Perhaps I should write the 'S

Re: pgsql: Consistently test for in-use shared memory.

On Mon, Apr 15, 2019 at 08:08:48PM -0400, Tom Lane wrote: > Noah Misch writes: > > Consistently test for in-use shared memory. > > Hmm ... conchuela has just found another problem with this test case: > > ok 2 - detected live backend via shared memory > # Running: postgres --single -D > /home/p

Re: pgsql: Consistently test for in-use shared memory.

Noah Misch writes: > Consistently test for in-use shared memory. Hmm ... conchuela has just found another problem with this test case: ok 2 - detected live backend via shared memory # Running: postgres --single -D /home/pgbf/buildroot/HEAD/pgsql.build/src/test/recovery/tmp_check/t_017_shm_gnat_

pgsql: Use [FLEXIBLE_ARRAY_MEMBER] not [1] in MultiSortSupportData.

Use [FLEXIBLE_ARRAY_MEMBER] not [1] in MultiSortSupportData. This struct seems to have not gotten the word about preferred coding style for variable-length arrays. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/dde7fb7836c7428f79cb3cd88ca5febb802e767e Modified Fil

pgsql: Convert pre-existing stats_ext tests to new style

Convert pre-existing stats_ext tests to new style The regression tests added in commit 7300a69950 test cardinality estimates using a function that extracts the interesting pieces from the EXPLAIN output, instead of testing the whole plan. That seems both easier to understand and less fragile, so t

pgsql: Fix pg_mcv_list deserialization

Fix pg_mcv_list deserialization The memcpy() was copying type OIDs in the wrong direction, so the deserialized MCV list always had them as 0. This is mostly harmless except when printing the data in pg_mcv_list_items(), in which case it reported ERROR: cache lookup failed for type 0 Also ad

pgsql: Fix failure with textual partition hash keys.

Fix failure with textual partition hash keys. Commit 5e1963fb7 overlooked two places in partbounds.c that now need to pass a collation identifier to the hash functions for a partition key column. Amit Langote, per report from Jesper Pedersen Discussion: https://postgr.es/m/a620f85a-42ab-e0f3-333

pgsql: Avoid possible regression test instability in timestamp.sql.

Avoid possible regression test instability in timestamp.sql. Concurrent autovacuum could result in a change in the order of the live rows in timestamp_tbl. While this would not happen with the default autovacuum parameters, it's fairly easy to hit if autovacuum_vacuum_threshold is made small enou

Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor

On Mon, Apr 15, 2019 at 11:28 AM Masahiko Sawada wrote: > On Mon, Apr 15, 2019 at 11:57 AM Alexander Korotkov > wrote: > > > > Hi! > > > > On Sun, Apr 14, 2019 at 11:00 PM Piotr Stefaniak > > wrote: > > > UB Sanitizer points out that prev_num_heap_tuples is sometimes 0, > > > leading to division

pgsql: Fix division by zero in _bt_vacuum_needs_cleanup()

Fix division by zero in _bt_vacuum_needs_cleanup() Checks inside _bt_vacuum_needs_cleanup() allow division by zero to happen when metad->btm_last_cleanup_num_heap_tuples == 0. This commit adjusts the expression so that no division by zero might happen. Reported-by: Piotr Stefaniak Discussion: h

pgsql: Fix division by zero in _bt_vacuum_needs_cleanup()

Fix division by zero in _bt_vacuum_needs_cleanup() Checks inside _bt_vacuum_needs_cleanup() allow division by zero to happen when metad->btm_last_cleanup_num_heap_tuples == 0. This commit adjusts the expression so that no division by zero might happen. Reported-by: Piotr Stefaniak Discussion: h

pgsql: Fix thinko in ExecCleanupTupleRouting().

Fix thinko in ExecCleanupTupleRouting(). Commit 3f2393edef changed ExecCleanupTupleRouting() so that it skipped cleaning up subplan resultrels before calling EndForeignInsert(), but that would cause an issue: when those resultrels were foreign tables, the FDWs would fail to shut down. Repair by s

Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor

On Mon, Apr 15, 2019 at 11:57 AM Alexander Korotkov wrote: > > Hi! > > On Sun, Apr 14, 2019 at 11:00 PM Piotr Stefaniak > wrote: > > On 26/06/2018 14.35, Alexander Korotkov wrote: > > > Increase upper limit for vacuum_cleanup_index_scale_factor > > > > > > Upper limits for vacuum_cleanup_index_sc

pgsql: Unbreak index optimization for LIKE on bytea

Unbreak index optimization for LIKE on bytea The same code is used to handle both text and bytea, but bytea is not collation-aware, so we shouldn't call get_collation_isdeterministic() in that case, since that will error out with an invalid collation. Reported-by: Jeevan Chalke Discussion: http