Re: Proposal for CSN based snapshots - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Proposal for CSN based snapshots
Date
Msg-id CA+U5nMLPwbMMrNzhXE0N8S4nCF_GSeuwYujzpDZ5c49pp0NTvg@mail.gmail.com
Whole thread Raw
In response to Re: Proposal for CSN based snapshots  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On 12 May 2014 17:14, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
> On 05/12/2014 06:26 PM, Andres Freund wrote:
>>>
>>> >With the new "commit-in-progress" status in clog, we won't need the
>>> >sub-committed clog status anymore. The "commit-in-progress" status will
>>> >achieve the same thing.
>>
>> Wouldn't that cause many spurious waits? Because commit-in-progress
>> needs to be waited on, but a sub-committed xact surely not?
>
>
> Ah, no. Even today, a subxid isn't marked as sub-committed, until you commit
> the top-level transaction. The sub-commit state is a very transient state
> during the commit process, used to make the commit of the sub-transactions
> and the top-level transaction appear atomic. The commit-in-progress state
> would be a similarly short-lived state. You mark the subxids and the top xid
> as commit-in-progress just before the XLogInsert() of the commit record, and
> you replace them with the real LSNs right after XLogInsert().

My understanding is that we aim to speed up the rate of Snapshot
reads. Which may make it feasible to store autonomous transactions in
shared memory, hopefully DSM.

The above mechanism sounds like it might slow down transaction commit.
Could we prototype that and measure the speed?

More generally, do we have any explicit performance goals or
acceptance criteria for this patch?

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Next
From: Robert Haas
Date:
Subject: Re: delta relations in AFTER triggers