Fix relcache leaks in get_object_address_publication_rel()
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/115cb31597fac8a17202d1e41da8baf33fcb60cf
Modified Files
--
src/backend/catalog/objectaddress.c | 4
1 file changed, 4 insertions(+)
--
Sent v
doc: Some improvements in CREATE SUBSCRIPTION ref page
Add link to description of libpq connection strings. Add link to
explanation of replication access control. This currently points to the
description of streaming replication access control, which is currently
the same as for logical replicat
Tag refs/tags/REL9_4_11 was created.
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Tag refs/tags/REL9_2_20 was created.
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Tag refs/tags/REL9_5_6 was created.
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Tag refs/tags/REL9_6_2 was created.
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Tag refs/tags/REL9_3_16 was created.
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Revise the way the element allocator for a simplehash is specified.
This method is more elegant and more efficient.
Per a suggestion from Andres Freund, who also briefly reviewed
the patch.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/c3c4f6e1740be256178cd7551d5b
Speed up "brin" regression test a little bit.
In the large DO block, collect row TIDs into array variables instead of
creating and dropping a pile of temporary tables. In a normal build,
this reduces the brin test script's runtime from about 1.1 sec to 0.4 sec
on my workstation. That's not all t
Avoid redefining simplehash_allocate/simplehash_free.
There's no generic guard against multiple inclusion in this file,
for good reason. But these typedefs need one, as per a report
from Jeff Janes.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/ac8eb972f268c787bfe
Allow the element allocator for a simplehash to be specified.
This is infrastructure for a pending patch to allow parallel bitmap
heap scans.
Dilip Kumar, reviewed (in earlier versions) by Andres Freund and
(more recently) by me. Some further renaming by me, also.
Branch
--
master
Details
Fix compiler warning.
Mithun Cy, per a report by Erik Rijkers
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/94708c0e8c32ad1c9c6ffbdb894fe158eda596e7
Modified Files
--
src/backend/access/hash/hashpage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
Cache hash index's metapage in rel->rd_amcache.
This avoids a very significant amount of buffer manager traffic and
contention when scanning hash indexes, because it's no longer
necessary to lock and pin the metapage for every scan. We do need
some way of figuring out when the cache is too stale
Correct thinko in last-minute release note item.
The CREATE INDEX CONCURRENTLY bug can only be triggered by row updates,
not inserts, since the problem would arise from an update incorrectly
being made HOT. Noted by Alvaro.
Branch
--
REL9_3_STABLE
Details
---
http://git.postgresql.org/p
Correct thinko in last-minute release note item.
The CREATE INDEX CONCURRENTLY bug can only be triggered by row updates,
not inserts, since the problem would arise from an update incorrectly
being made HOT. Noted by Alvaro.
Branch
--
REL9_6_STABLE
Details
---
http://git.postgresql.org/p
Correct thinko in last-minute release note item.
The CREATE INDEX CONCURRENTLY bug can only be triggered by row updates,
not inserts, since the problem would arise from an update incorrectly
being made HOT. Noted by Alvaro.
Branch
--
REL9_4_STABLE
Details
---
http://git.postgresql.org/p
Correct thinko in last-minute release note item.
The CREATE INDEX CONCURRENTLY bug can only be triggered by row updates,
not inserts, since the problem would arise from an update incorrectly
being made HOT. Noted by Alvaro.
Branch
--
REL9_2_STABLE
Details
---
http://git.postgresql.org/p
Correct thinko in last-minute release note item.
The CREATE INDEX CONCURRENTLY bug can only be triggered by row updates,
not inserts, since the problem would arise from an update incorrectly
being made HOT. Noted by Alvaro.
Branch
--
REL9_5_STABLE
Details
---
http://git.postgresql.org/p
Correct thinko in last-minute release note item.
The CREATE INDEX CONCURRENTLY bug can only be triggered by row updates,
not inserts, since the problem would arise from an update incorrectly
being made HOT. Noted by Alvaro.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commi
Initialize number_of_jobs in NewRestoreOptions
Now that we're checking that the number_of_jobs passed in isn't zero or
negative, we need to actually initialize number_of_jobs to '1' when it
isn't set.
Pointed out by Rushabh Lathia, though not his patch.
Discussion:
https://postgr.es/m/CAGPqQf2u
20 matches
Mail list logo
