pgsql: Fix _equalA_Const

2021-09-09 Thread Peter Eisentraut
Fix _equalA_Const 639a86e36aaecb84faaf941dcd0b183ba0aba9e9 neglected to make the necessary adjustments to _equalA_Const. Found only via COPY_PARSE_PLAN_TREES. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0ffbe900ce599d204536b9623291e05e965da23e Modified Files -

pgsql: Fix issue with WAL archiving in standby.

2021-09-09 Thread Fujii Masao
Fix issue with WAL archiving in standby. Previously, walreceiver always closed the currently-opened WAL segment and created its archive notification file, after it finished writing the current segment up and received any WAL data that should be written into the next segment. If walreceiver exited

pgsql: Fix issue with WAL archiving in standby.

2021-09-09 Thread Fujii Masao
Fix issue with WAL archiving in standby. Previously, walreceiver always closed the currently-opened WAL segment and created its archive notification file, after it finished writing the current segment up and received any WAL data that should be written into the next segment. If walreceiver exited

pgsql: Fix issue with WAL archiving in standby.

2021-09-09 Thread Fujii Masao
Fix issue with WAL archiving in standby. Previously, walreceiver always closed the currently-opened WAL segment and created its archive notification file, after it finished writing the current segment up and received any WAL data that should be written into the next segment. If walreceiver exited

pgsql: Fix issue with WAL archiving in standby.

2021-09-09 Thread Fujii Masao
Fix issue with WAL archiving in standby. Previously, walreceiver always closed the currently-opened WAL segment and created its archive notification file, after it finished writing the current segment up and received any WAL data that should be written into the next segment. If walreceiver exited

pgsql: Fix issue with WAL archiving in standby.

2021-09-09 Thread Fujii Masao
Fix issue with WAL archiving in standby. Previously, walreceiver always closed the currently-opened WAL segment and created its archive notification file, after it finished writing the current segment up and received any WAL data that should be written into the next segment. If walreceiver exited

pgsql: Fix issue with WAL archiving in standby.

2021-09-09 Thread Fujii Masao
Fix issue with WAL archiving in standby. Previously, walreceiver always closed the currently-opened WAL segment and created its archive notification file, after it finished writing the current segment up and received any WAL data that should be written into the next segment. If walreceiver exited

pgsql: Fix issue with WAL archiving in standby.

2021-09-09 Thread Fujii Masao
Fix issue with WAL archiving in standby. Previously, walreceiver always closed the currently-opened WAL segment and created its archive notification file, after it finished writing the current segment up and received any WAL data that should be written into the next segment. If walreceiver exited

pgsql: Check for relation length overrun soon enough.

2021-09-09 Thread Tom Lane
Check for relation length overrun soon enough. We don't allow relations to exceed 2^32-1 blocks, because block numbers are 32 bits and the last possible block number is reserved to mean InvalidBlockNumber. There is a check for this in mdextend, but that's really way too late, because the smgr API

pgsql: Check for relation length overrun soon enough.

2021-09-09 Thread Tom Lane
Check for relation length overrun soon enough. We don't allow relations to exceed 2^32-1 blocks, because block numbers are 32 bits and the last possible block number is reserved to mean InvalidBlockNumber. There is a check for this in mdextend, but that's really way too late, because the smgr API

pgsql: Check for relation length overrun soon enough.

2021-09-09 Thread Tom Lane
Check for relation length overrun soon enough. We don't allow relations to exceed 2^32-1 blocks, because block numbers are 32 bits and the last possible block number is reserved to mean InvalidBlockNumber. There is a check for this in mdextend, but that's really way too late, because the smgr API

pgsql: Check for relation length overrun soon enough.

2021-09-09 Thread Tom Lane
Check for relation length overrun soon enough. We don't allow relations to exceed 2^32-1 blocks, because block numbers are 32 bits and the last possible block number is reserved to mean InvalidBlockNumber. There is a check for this in mdextend, but that's really way too late, because the smgr API

pgsql: Check for relation length overrun soon enough.

2021-09-09 Thread Tom Lane
Check for relation length overrun soon enough. We don't allow relations to exceed 2^32-1 blocks, because block numbers are 32 bits and the last possible block number is reserved to mean InvalidBlockNumber. There is a check for this in mdextend, but that's really way too late, because the smgr API

pgsql: Check for relation length overrun soon enough.

2021-09-09 Thread Tom Lane
Check for relation length overrun soon enough. We don't allow relations to exceed 2^32-1 blocks, because block numbers are 32 bits and the last possible block number is reserved to mean InvalidBlockNumber. There is a check for this in mdextend, but that's really way too late, because the smgr API

pgsql: Check for relation length overrun soon enough.

2021-09-09 Thread Tom Lane
Check for relation length overrun soon enough. We don't allow relations to exceed 2^32-1 blocks, because block numbers are 32 bits and the last possible block number is reserved to mean InvalidBlockNumber. There is a check for this in mdextend, but that's really way too late, because the smgr API

pgsql: pgbench: Stop counting skipped transactions as soon as timer is

2021-09-09 Thread Fujii Masao
pgbench: Stop counting skipped transactions as soon as timer is exceeded. When throttling is used, transactions that lag behind schedule by more than the latency limit are counted and reported as skipped. Previously, there was the case where pgbench counted all skipped transactions even if the tim

pgsql: pgbench: Stop counting skipped transactions as soon as timer is

2021-09-09 Thread Fujii Masao
pgbench: Stop counting skipped transactions as soon as timer is exceeded. When throttling is used, transactions that lag behind schedule by more than the latency limit are counted and reported as skipped. Previously, there was the case where pgbench counted all skipped transactions even if the tim

pgsql: Avoid fetching from an already-terminated plan.

2021-09-09 Thread Tom Lane
Avoid fetching from an already-terminated plan. Some plan node types don't react well to being called again after they've already returned NULL. PortalRunSelect() has long dealt with this by calling the executor with NoMovementScanDirection if it sees that we've already run the portal to the end.

pgsql: Avoid fetching from an already-terminated plan.

2021-09-09 Thread Tom Lane
Avoid fetching from an already-terminated plan. Some plan node types don't react well to being called again after they've already returned NULL. PortalRunSelect() has long dealt with this by calling the executor with NoMovementScanDirection if it sees that we've already run the portal to the end.

pgsql: Avoid fetching from an already-terminated plan.

2021-09-09 Thread Tom Lane
Avoid fetching from an already-terminated plan. Some plan node types don't react well to being called again after they've already returned NULL. PortalRunSelect() has long dealt with this by calling the executor with NoMovementScanDirection if it sees that we've already run the portal to the end.

pgsql: Avoid fetching from an already-terminated plan.

2021-09-09 Thread Tom Lane
Avoid fetching from an already-terminated plan. Some plan node types don't react well to being called again after they've already returned NULL. PortalRunSelect() has long dealt with this by calling the executor with NoMovementScanDirection if it sees that we've already run the portal to the end.

pgsql: Avoid fetching from an already-terminated plan.

2021-09-09 Thread Tom Lane
Avoid fetching from an already-terminated plan. Some plan node types don't react well to being called again after they've already returned NULL. PortalRunSelect() has long dealt with this by calling the executor with NoMovementScanDirection if it sees that we've already run the portal to the end.

pgsql: Revoke PUBLIC CREATE from public schema, now owned by pg_databas

2021-09-09 Thread Noah Misch
Revoke PUBLIC CREATE from public schema, now owned by pg_database_owner. This switches the default ACL to what the documentation has recommended since CVE-2018-1058. Upgrades will carry forward any old ownership and ACL. Sites that declined the 2018 recommendation should take a fresh look. Reci