[COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Fix freezing of a dead HOT-updated tuple Vacuum calls page-level HOT prune to remove dead HOT tuples before doing liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But concurrent transaction commit/abort may turn DEAD some of the HOT tuples that survived the prune, before

[COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Fix freezing of a dead HOT-updated tuple Vacuum calls page-level HOT prune to remove dead HOT tuples before doing liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But concurrent transaction commit/abort may turn DEAD some of the HOT tuples that survived the prune, before

Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Thu, Sep 28, 2017 at 7:47 AM, Alvaro Herrera wrote: > Fix freezing of a dead HOT-updated tuple If I run Dan Wood's test case again, the obvious symptom (spurious duplicates) goes away. However, the enhanced amcheck, and thus CREATE INDEX/REINDEX, still isn't happy

[COMMITTERS] pgsql: Remove SGML marked sections

Remove SGML marked sections For XML compatibility, replace marked sections with comments . In some cases it seemed better to remove the ignored text altogether, and in one case the text should not have been ignored. Branch -- master Details ---

[COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Fix freezing of a dead HOT-updated tuple Vacuum calls page-level HOT prune to remove dead HOT tuples before doing liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But concurrent transaction commit/abort may turn DEAD some of the HOT tuples that survived the prune, before

[COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Fix freezing of a dead HOT-updated tuple Vacuum calls page-level HOT prune to remove dead HOT tuples before doing liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But concurrent transaction commit/abort may turn DEAD some of the HOT tuples that survived the prune, before

[COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Fix freezing of a dead HOT-updated tuple Vacuum calls page-level HOT prune to remove dead HOT tuples before doing liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But concurrent transaction commit/abort may turn DEAD some of the HOT tuples that survived the prune, before

[COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Fix freezing of a dead HOT-updated tuple Vacuum calls page-level HOT prune to remove dead HOT tuples before doing liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But concurrent transaction commit/abort may turn DEAD some of the HOT tuples that survived the prune, before

PartitionSchemaData & partcollation (Re: [COMMITTERS] pgsql: Associate partitioning information with each RelOptInfo.)

On 2017/09/21 12:42, Robert Haas wrote: > Associate partitioning information with each RelOptInfo. > > This is not used for anything yet, but it is necessary infrastructure > for partition-wise join and for partition pruning without constraint > exclusion. > > Ashutosh Bapat, reviewed by Amit

Re: [HACKERS] PartitionSchemaData & partcollation (Re: [COMMITTERS] pgsql: Associate partitioning information with each RelOptInfo.)

Sorry, I meant to say PartitionSchem"e"Data in subject. Thanks, Amit -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

Andres Freund writes: > If the buildfarm doesn't complain about the use of IPC::Run's timeout > functionality, we should probably patch that into the other use of > IPC::Run as well, but especially into the other user of the pump() until > ... scheme. jacana hasn't passed

[COMMITTERS] pgsql: Have lcov exclude external files

Have lcov exclude external files Call lcov with --no-external option to exclude external files (for example, system headers with inline functions) from output. Reviewed-by: Michael Paquier Branch -- master Details ---

[COMMITTERS] pgsql: Run only top-level recursive lcov

Run only top-level recursive lcov This is the way lcov was intended to be used. It is much faster and more robust and makes the makefiles simpler than running it in each subdirectory. The previous coding ran gcov before lcov, but that is useless because lcov/geninfo call gcov internally and use

Re: [HACKERS] PartitionSchemaData & partcollation (Re: [COMMITTERS] pgsql: Associate partitioning information with each RelOptInfo.)

On Thu, Sep 28, 2017 at 11:47 AM, Amit Langote wrote: > On 2017/09/21 12:42, Robert Haas wrote: >> Associate partitioning information with each RelOptInfo. >> >> This is not used for anything yet, but it is necessary infrastructure >> for partition-wise join and for

Re: [HACKERS] PartitionSchemaData & partcollation (Re: [COMMITTERS] pgsql: Associate partitioning information with each RelOptInfo.)

On 2017/09/28 16:13, Ashutosh Bapat wrote: > On Thu, Sep 28, 2017 at 11:47 AM, Amit Langote wrote: >> On 2017/09/21 12:42, Robert Haas wrote: >>> Associate partitioning information with each RelOptInfo. >>> >>> This is not used for anything yet, but it is necessary infrastructure >>> for