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
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:
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
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
--
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_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
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
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
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,
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
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
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/fcc42756818cef68e61e35e6d71cac6a73e24bb9
Modified Files
--
src
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 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
27 matches
Mail list logo
