Fix typo in multixact.c
AtEOXact_MultiXact() was referenced in two places with an incorrect
routine name.
Author: Hou Zhijie
Discussion:
https://postgr.es/m/1b41e9311e8f474cb5a360292f0b3cb1@G08CNEXMBPEKD05.g08.fujitsu.local
Branch
--
master
Details
---
https://git.postgresql.org/pg/com
Improve set of candidate multipliers for perfect hash function generation
The previous set of multipliers was not adapted for large sets of short
keys, and this new set of multipliers allows to generate perfect hash
functions for larger sets without having an impact for existing callers
of those f
Track statistics for spilling of changes from ReorderBuffer.
This adds the statistics about transactions spilled to disk from
ReorderBuffer. Users can query the pg_stat_replication_slots view to check
these stats and call pg_stat_reset_replication_slot to reset the stats of
a particular slot. User
On 2020/10/08 0:48, Fujii Masao wrote:
On 2020/10/07 22:25, Fujii Masao wrote:
On 2020/10/07 12:54, Fujii Masao wrote:
On 2020/10/07 11:13, Michael Paquier wrote:
Hi Fujii-san,
On Tue, Oct 06, 2020 at 01:52:55AM +, Fujii Masao wrote:
postgres_fdw: reestablish new connection if ca
Fix optimization hazard in gram.y's makeOrderedSetArgs(), redux.
It appears that commit cf63c641c, which intended to prevent
misoptimization of the result-building step in makeOrderedSetArgs,
didn't go far enough: buildfarm member hornet's version of xlc
is now optimizing back to the old, broken b
Fix optimization hazard in gram.y's makeOrderedSetArgs(), redux.
It appears that commit cf63c641c, which intended to prevent
misoptimization of the result-building step in makeOrderedSetArgs,
didn't go far enough: buildfarm member hornet's version of xlc
is now optimizing back to the old, broken b
Fix optimization hazard in gram.y's makeOrderedSetArgs(), redux.
It appears that commit cf63c641c, which intended to prevent
misoptimization of the result-building step in makeOrderedSetArgs,
didn't go far enough: buildfarm member hornet's version of xlc
is now optimizing back to the old, broken b
Fix optimization hazard in gram.y's makeOrderedSetArgs(), redux.
It appears that commit cf63c641c, which intended to prevent
misoptimization of the result-building step in makeOrderedSetArgs,
didn't go far enough: buildfarm member hornet's version of xlc
is now optimizing back to the old, broken b
Fix optimization hazard in gram.y's makeOrderedSetArgs(), redux.
It appears that commit cf63c641c, which intended to prevent
misoptimization of the result-building step in makeOrderedSetArgs,
didn't go far enough: buildfarm member hornet's version of xlc
is now optimizing back to the old, broken b
Fix optimization hazard in gram.y's makeOrderedSetArgs(), redux.
It appears that commit cf63c641c, which intended to prevent
misoptimization of the result-building step in makeOrderedSetArgs,
didn't go far enough: buildfarm member hornet's version of xlc
is now optimizing back to the old, broken b
Fix optimization hazard in gram.y's makeOrderedSetArgs(), redux.
It appears that commit cf63c641c, which intended to prevent
misoptimization of the result-building step in makeOrderedSetArgs,
didn't go far enough: buildfarm member hornet's version of xlc
is now optimizing back to the old, broken b
Prevent internal overflows in date-vs-timestamp and related comparisons.
The date-vs-timestamp, date-vs-timestamptz, and timestamp-vs-timestamptz
comparators all worked by promoting the first type to the second and
then doing a simple same-type comparison. This works fine, except
when the convers
Prevent internal overflows in date-vs-timestamp and related comparisons.
The date-vs-timestamp, date-vs-timestamptz, and timestamp-vs-timestamptz
comparators all worked by promoting the first type to the second and
then doing a simple same-type comparison. This works fine, except
when the convers
Clean up after newly-added tests for pg_test_fsync and pg_test_timing.
Oversight in 4d29e6dbd.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/6c05e5b77471dfadebe50ad4a8bdedef02ad0078
Modified Files
--
src/bin/pg_test_fsync/Makefile | 1 +
src/bin/pg_te
Rethink recent fix for pg_dump's handling of extension config tables.
Commit 3eb3d3e78 was a few bricks shy of a load: while it correctly
set the table's "interesting" flag when deciding to dump the data of
an extension config table, it was not correct to clear that flag
if we concluded we shouldn
Rethink recent fix for pg_dump's handling of extension config tables.
Commit 3eb3d3e78 was a few bricks shy of a load: while it correctly
set the table's "interesting" flag when deciding to dump the data of
an extension config table, it was not correct to clear that flag
if we concluded we shouldn
Rethink recent fix for pg_dump's handling of extension config tables.
Commit 3eb3d3e78 was a few bricks shy of a load: while it correctly
set the table's "interesting" flag when deciding to dump the data of
an extension config table, it was not correct to clear that flag
if we concluded we shouldn
Rethink recent fix for pg_dump's handling of extension config tables.
Commit 3eb3d3e78 was a few bricks shy of a load: while it correctly
set the table's "interesting" flag when deciding to dump the data of
an extension config table, it was not correct to clear that flag
if we concluded we shouldn
Rethink recent fix for pg_dump's handling of extension config tables.
Commit 3eb3d3e78 was a few bricks shy of a load: while it correctly
set the table's "interesting" flag when deciding to dump the data of
an extension config table, it was not correct to clear that flag
if we concluded we shouldn
Rethink recent fix for pg_dump's handling of extension config tables.
Commit 3eb3d3e78 was a few bricks shy of a load: while it correctly
set the table's "interesting" flag when deciding to dump the data of
an extension config table, it was not correct to clear that flag
if we concluded we shouldn
Rethink recent fix for pg_dump's handling of extension config tables.
Commit 3eb3d3e78 was a few bricks shy of a load: while it correctly
set the table's "interesting" flag when deciding to dump the data of
an extension config table, it was not correct to clear that flag
if we concluded we shouldn
On 2020/10/07 22:25, Fujii Masao wrote:
On 2020/10/07 12:54, Fujii Masao wrote:
On 2020/10/07 11:13, Michael Paquier wrote:
Hi Fujii-san,
On Tue, Oct 06, 2020 at 01:52:55AM +, Fujii Masao wrote:
postgres_fdw: reestablish new connection if cached one is detected as broken.
In postg
On 2020/10/07 12:54, Fujii Masao wrote:
On 2020/10/07 11:13, Michael Paquier wrote:
Hi Fujii-san,
On Tue, Oct 06, 2020 at 01:52:55AM +, Fujii Masao wrote:
postgres_fdw: reestablish new connection if cached one is detected as broken.
In postgres_fdw, once remote connections are establ
23 matches
Mail list logo
