pgsql: Use multi-inserts for pg_depend

2020-09-04 Thread Michael Paquier
Use multi-inserts for pg_depend This is a follow-up of the work done in e3931d01. This case is a bit different than pg_attribute and pg_shdepend: the maximum number of items to insert is known in advance, but there is no need to handle pinned dependencies. Hence, the base allocation for slots is

pgsql: Make new authentication test case more robust.

2020-09-04 Thread Tom Lane
Make new authentication test case more robust. I happened to notice that the new test case I added in b55b4dad9 falls over if one runs "make check" repeatedly; though not in branches after v10. That's because it was assuming that tmp_check/pgpass wouldn't exist already. However, it's only been s

pgsql: Make new authentication test case more robust.

2020-09-04 Thread Tom Lane
Make new authentication test case more robust. I happened to notice that the new test case I added in b55b4dad9 falls over if one runs "make check" repeatedly; though not in branches after v10. That's because it was assuming that tmp_check/pgpass wouldn't exist already. However, it's only been s

pgsql: Make new authentication test case more robust.

2020-09-04 Thread Tom Lane
Make new authentication test case more robust. I happened to notice that the new test case I added in b55b4dad9 falls over if one runs "make check" repeatedly; though not in branches after v10. That's because it was assuming that tmp_check/pgpass wouldn't exist already. However, it's only been s

pgsql: Make new authentication test case more robust.

2020-09-04 Thread Tom Lane
Make new authentication test case more robust. I happened to notice that the new test case I added in b55b4dad9 falls over if one runs "make check" repeatedly; though not in branches after v10. That's because it was assuming that tmp_check/pgpass wouldn't exist already. However, it's only been s

pgsql: Make new authentication test case more robust.

2020-09-04 Thread Tom Lane
Make new authentication test case more robust. I happened to notice that the new test case I added in b55b4dad9 falls over if one runs "make check" repeatedly; though not in branches after v10. That's because it was assuming that tmp_check/pgpass wouldn't exist already. However, it's only been s

pgsql: Fix over-eager ping'ing in logical replication receiver.

2020-09-04 Thread Tom Lane
Fix over-eager ping'ing in logical replication receiver. Commit 3f60f690f only partially fixed the broken-status-tracking issue in LogicalRepApplyLoop: we need ping_sent to have the same lifetime as last_recv_timestamp. The effects are much less serious than what that commit fixed, though. AFAIC

pgsql: Fix over-eager ping'ing in logical replication receiver.

2020-09-04 Thread Tom Lane
Fix over-eager ping'ing in logical replication receiver. Commit 3f60f690f only partially fixed the broken-status-tracking issue in LogicalRepApplyLoop: we need ping_sent to have the same lifetime as last_recv_timestamp. The effects are much less serious than what that commit fixed, though. AFAIC

pgsql: Fix over-eager ping'ing in logical replication receiver.

2020-09-04 Thread Tom Lane
Fix over-eager ping'ing in logical replication receiver. Commit 3f60f690f only partially fixed the broken-status-tracking issue in LogicalRepApplyLoop: we need ping_sent to have the same lifetime as last_recv_timestamp. The effects are much less serious than what that commit fixed, though. AFAIC

pgsql: Fix over-eager ping'ing in logical replication receiver.

2020-09-04 Thread Tom Lane
Fix over-eager ping'ing in logical replication receiver. Commit 3f60f690f only partially fixed the broken-status-tracking issue in LogicalRepApplyLoop: we need ping_sent to have the same lifetime as last_recv_timestamp. The effects are much less serious than what that commit fixed, though. AFAIC

pgsql: Fix over-eager ping'ing in logical replication receiver.

2020-09-04 Thread Tom Lane
Fix over-eager ping'ing in logical replication receiver. Commit 3f60f690f only partially fixed the broken-status-tracking issue in LogicalRepApplyLoop: we need ping_sent to have the same lifetime as last_recv_timestamp. The effects are much less serious than what that commit fixed, though. AFAIC

pgsql: Remove still more useless assignments.

2020-09-04 Thread Tom Lane
Remove still more useless assignments. Fix some more things scan-build pointed to as dead stores. In some of these cases, rearranging the code a little leads to more readable code IMO. It's all cosmetic, though. Discussion: https://postgr.es/m/CAEudQAo1+AcGppxDSg8k+zF4+Kv+eJyqzEDdbpDg58-=mqc..

pgsql: Fix bogus MaxAllocSize check in logtape.c.

2020-09-04 Thread Jeff Davis
Fix bogus MaxAllocSize check in logtape.c. Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wz=NZPZc3-fkdmvu=w2itx0pib-g6qpxhxzojuvfazp...@mail.gmail.com Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4a4f3bf983b4abd90

pgsql: Fix bogus MaxAllocSize check in logtape.c.

2020-09-04 Thread Jeff Davis
Fix bogus MaxAllocSize check in logtape.c. Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wz=NZPZc3-fkdmvu=w2itx0pib-g6qpxhxzojuvfazp...@mail.gmail.com Backpatch-through: 13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0852006a946aa9795b4913bc

pgsql: Report expected contrecord length on mismatch

2020-09-04 Thread Alvaro Herrera
Report expected contrecord length on mismatch When reading a WAL record fails to find continuation record(s) of the proper length, report what it expects, for clarity. Reviewed-by: Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- master Details -

pgsql: Remove some more useless assignments.

2020-09-04 Thread Tom Lane
Remove some more useless assignments. Found with clang's scan-build tool. It also whines about a lot of other dead stores that we should *not* change IMO, either as a matter of style or future-proofing. But these places seem like clear oversights. Discussion: https://postgr.es/m/CAEudQAo1+AcGp

pgsql: Collect attribute data on extension owned tables being dumped

2020-09-04 Thread Andrew Dunstan
Collect attribute data on extension owned tables being dumped If this data is not collected, pg_dump segfaults if asked for column inserts. Fix by Fabrízio de Royes Mello Backpatch to release 12 where the bug was introduced. Branch -- REL_12_STABLE Details --- https://git.postgresql.or

pgsql: Collect attribute data on extension owned tables being dumped

2020-09-04 Thread Andrew Dunstan
Collect attribute data on extension owned tables being dumped If this data is not collected, pg_dump segfaults if asked for column inserts. Fix by Fabrízio de Royes Mello Backpatch to release 12 where the bug was introduced. Branch -- REL_13_STABLE Details --- https://git.postgresql.or

pgsql: Collect attribute data on extension owned tables being dumped

2020-09-04 Thread Andrew Dunstan
Collect attribute data on extension owned tables being dumped If this data is not collected, pg_dump segfaults if asked for column inserts. Fix by Fabrízio de Royes Mello Backpatch to release 12 where the bug was introduced. Branch -- master Details --- https://git.postgresql.org/pg/co

pgsql: C comment: correct use of 64-"byte" cache line size

2020-09-04 Thread Bruce Momjian
C comment: correct use of 64-"byte" cache line size Reported-by: Kelly Min Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=dqf...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/56f42cf906

pgsql: C comment: correct use of 64-"byte" cache line size

2020-09-04 Thread Bruce Momjian
C comment: correct use of 64-"byte" cache line size Reported-by: Kelly Min Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=dqf...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/63abf9ad9b

pgsql: C comment: correct use of 64-"byte" cache line size

2020-09-04 Thread Bruce Momjian
C comment: correct use of 64-"byte" cache line size Reported-by: Kelly Min Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=dqf...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7f79f95821

pgsql: C comment: correct use of 64-"byte" cache line size

2020-09-04 Thread Bruce Momjian
C comment: correct use of 64-"byte" cache line size Reported-by: Kelly Min Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=dqf...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7574af1e1b

pgsql: C comment: correct use of 64-"byte" cache line size

2020-09-04 Thread Bruce Momjian
C comment: correct use of 64-"byte" cache line size Reported-by: Kelly Min Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=dqf...@mail.gmail.com Backpatch-through: 9.5 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3b5af0e95ad5a3d9b

pgsql: C comment: correct use of 64-"byte" cache line size

2020-09-04 Thread Bruce Momjian
C comment: correct use of 64-"byte" cache line size Reported-by: Kelly Min Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=dqf...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/226fd0c518

pgsql: C comment: correct use of 64-"byte" cache line size

2020-09-04 Thread Bruce Momjian
C comment: correct use of 64-"byte" cache line size Reported-by: Kelly Min Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=dqf...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cb9d1faa4a

pgsql: Fix rare deadlock failure in create_am regression test.

2020-09-04 Thread Tom Lane
Fix rare deadlock failure in create_am regression test. The "DROP ACCESS METHOD gist2" test will require locking the index to be dropped and then its table; while most ordinary operations lock a table first then its index. While no concurrent test scripts should be touching fast_emp4000, autovacu

pgsql: Fix rare deadlock failure in create_am regression test.

2020-09-04 Thread Tom Lane
Fix rare deadlock failure in create_am regression test. The "DROP ACCESS METHOD gist2" test will require locking the index to be dropped and then its table; while most ordinary operations lock a table first then its index. While no concurrent test scripts should be touching fast_emp4000, autovacu

pgsql: Fix rare deadlock failure in create_am regression test.

2020-09-04 Thread Tom Lane
Fix rare deadlock failure in create_am regression test. The "DROP ACCESS METHOD gist2" test will require locking the index to be dropped and then its table; while most ordinary operations lock a table first then its index. While no concurrent test scripts should be touching fast_emp4000, autovacu

pgsql: Fix rare deadlock failure in create_am regression test.

2020-09-04 Thread Tom Lane
Fix rare deadlock failure in create_am regression test. The "DROP ACCESS METHOD gist2" test will require locking the index to be dropped and then its table; while most ordinary operations lock a table first then its index. While no concurrent test scripts should be touching fast_emp4000, autovacu

pgsql: Fix rare deadlock failure in create_am regression test.

2020-09-04 Thread Tom Lane
Fix rare deadlock failure in create_am regression test. The "DROP ACCESS METHOD gist2" test will require locking the index to be dropped and then its table; while most ordinary operations lock a table first then its index. While no concurrent test scripts should be touching fast_emp4000, autovacu

pgsql: Fix rare deadlock failure in create_am regression test.

2020-09-04 Thread Tom Lane
Fix rare deadlock failure in create_am regression test. The "DROP ACCESS METHOD gist2" test will require locking the index to be dropped and then its table; while most ordinary operations lock a table first then its index. While no concurrent test scripts should be touching fast_emp4000, autovacu