Fix thinko with definition of REINDEXOPT_MISSING_OK
This had no direct consequences, but let's be consistent and it would be
confusing when adding new flags. Oversight in 1d65416.
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20200902024148.gb20...@telsasoft.com
Branch
--
maste
Avoid unnecessary acquisition of SyncRepLock in transaction commit time.
In SyncRepWaitForLSN() routine called in transaction commit time,
SyncRepLock is necessary to atomically both check the shared
sync_standbys_defined flag and operate the sync replication wait-queue.
On the other hand, when th
Fix typo in comment
Introduced by 8b08f7d4820f; backpatch to 11.
Discussion: https://postgr.es/m/20200812214918.GA30353@alvherre.pgsql
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/fcc42756818cef68e61e35e6d71cac6a73e24bb9
Modified Files
--
src
Fix typo in comment
Introduced by 8b08f7d4820f; backpatch to 11.
Discussion: https://postgr.es/m/20200812214918.GA30353@alvherre.pgsql
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/70ccff88d910f57e427331afcbd6322ff7c80d18
Modified Files
--
src
Fix typo in comment
Introduced by 8b08f7d4820f; backpatch to 11.
Discussion: https://postgr.es/m/20200812214918.GA30353@alvherre.pgsql
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/352b8cf59f400e69a80db12f920adf12a1b0607c
Modified Files
--
src
Fix typo in comment
Introduced by 8b08f7d4820f; backpatch to 11.
Discussion: https://postgr.es/m/20200812214918.GA30353@alvherre.pgsql
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/05c16b827f3ae66ec718e9af49e4d96906fa2ffb
Modified Files
--
src/bin/pg
Improve handling of dropped relations for REINDEX DATABASE/SCHEMA/SYSTEM
When multiple relations are reindexed, a scan of pg_class is done first
to build the list of relations to work on. However the REINDEX logic
has never checked if a relation listed still exists when beginning the
work on it,
Improve test coverage of ginvacuum.c.
Add a test case that exercises vacuum's deletion of empty GIN
posting pages. Since this is a temp table, it should now work
reliably to delete a bunch of rows and immediately VACUUM.
Before the preceding commit, this would not have had the desired
effect, at
Set cutoff xmin more aggressively when vacuuming a temporary table.
Since other sessions aren't allowed to look into a temporary table
of our own session, we do not need to worry about the global xmin
horizon when setting the vacuum XID cutoff. Indeed, if we're not
inside a transaction block, we
doc: clarify that max_wal_size is "during" checkpoints
Previous wording was "between".
Reported-by: Pavel Luzanov
Discussion:
https://postgr.es/m/26906a54-d7cb-2f8e-eed7-e31660024...@postgrespro.ru
Backpatch-through: 9.5
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org
doc: clarify that max_wal_size is "during" checkpoints
Previous wording was "between".
Reported-by: Pavel Luzanov
Discussion:
https://postgr.es/m/26906a54-d7cb-2f8e-eed7-e31660024...@postgrespro.ru
Backpatch-through: 9.5
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org
doc: clarify that max_wal_size is "during" checkpoints
Previous wording was "between".
Reported-by: Pavel Luzanov
Discussion:
https://postgr.es/m/26906a54-d7cb-2f8e-eed7-e31660024...@postgrespro.ru
Backpatch-through: 9.5
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org
doc: clarify that max_wal_size is "during" checkpoints
Previous wording was "between".
Reported-by: Pavel Luzanov
Discussion:
https://postgr.es/m/26906a54-d7cb-2f8e-eed7-e31660024...@postgrespro.ru
Backpatch-through: 9.5
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org
doc: clarify that max_wal_size is "during" checkpoints
Previous wording was "between".
Reported-by: Pavel Luzanov
Discussion:
https://postgr.es/m/26906a54-d7cb-2f8e-eed7-e31660024...@postgrespro.ru
Backpatch-through: 9.5
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org
doc: clarify that max_wal_size is "during" checkpoints
Previous wording was "between".
Reported-by: Pavel Luzanov
Discussion:
https://postgr.es/m/26906a54-d7cb-2f8e-eed7-e31660024...@postgrespro.ru
Backpatch-through: 9.5
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org
doc: clarify that max_wal_size is "during" checkpoints
Previous wording was "between".
Reported-by: Pavel Luzanov
Discussion:
https://postgr.es/m/26906a54-d7cb-2f8e-eed7-e31660024...@postgrespro.ru
Backpatch-through: 9.5
Branch
--
master
Details
---
https://git.postgresql.org/pg/com
Raise error on concurrent drop of partitioned index
We were already raising an error for DROP INDEX CONCURRENTLY on a
partitioned table, albeit a different and confusing one:
ERROR: DROP INDEX CONCURRENTLY must be first action in transaction
Change that to throw a more comprehensible error:
Raise error on concurrent drop of partitioned index
We were already raising an error for DROP INDEX CONCURRENTLY on a
partitioned table, albeit a different and confusing one:
ERROR: DROP INDEX CONCURRENTLY must be first action in transaction
Change that to throw a more comprehensible error:
Raise error on concurrent drop of partitioned index
We were already raising an error for DROP INDEX CONCURRENTLY on a
partitioned table, albeit a different and confusing one:
ERROR: DROP INDEX CONCURRENTLY must be first action in transaction
Change that to throw a more comprehensible error:
Raise error on concurrent drop of partitioned index
We were already raising an error for DROP INDEX CONCURRENTLY on a
partitioned table, albeit a different and confusing one:
ERROR: DROP INDEX CONCURRENTLY must be first action in transaction
Change that to throw a more comprehensible error:
Teach libpq to handle arbitrary-length lines in .pgpass files.
Historically there's been a hard-wired assumption here that no line of
a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit
shaky to start off with, because (a) there's no reason to suppose that
host names fit in NAMED
Teach libpq to handle arbitrary-length lines in .pgpass files.
Historically there's been a hard-wired assumption here that no line of
a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit
shaky to start off with, because (a) there's no reason to suppose that
host names fit in NAMED
Teach libpq to handle arbitrary-length lines in .pgpass files.
Historically there's been a hard-wired assumption here that no line of
a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit
shaky to start off with, because (a) there's no reason to suppose that
host names fit in NAMED
Teach libpq to handle arbitrary-length lines in .pgpass files.
Historically there's been a hard-wired assumption here that no line of
a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit
shaky to start off with, because (a) there's no reason to suppose that
host names fit in NAMED
Teach libpq to handle arbitrary-length lines in .pgpass files.
Historically there's been a hard-wired assumption here that no line of
a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit
shaky to start off with, because (a) there's no reason to suppose that
host names fit in NAMED
Teach libpq to handle arbitrary-length lines in .pgpass files.
Historically there's been a hard-wired assumption here that no line of
a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit
shaky to start off with, because (a) there's no reason to suppose that
host names fit in NAMED
Teach libpq to handle arbitrary-length lines in .pgpass files.
Historically there's been a hard-wired assumption here that no line of
a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit
shaky to start off with, because (a) there's no reason to suppose that
host names fit in NAMED
27 matches
Mail list logo
