| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Erik Rijkers <er(at)xs4all(dot)nl>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: snapbuild woes |
| Date: | 2017-05-01 02:29:40 |
| Message-ID: | CAMsr+YFMDPm7YcPp57Maw1jYSvD0CooKQSYZ=FAqfJLaYV-=Jw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 1 May 2017 at 09:54, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> wrote:
> But, I still think we need to restart the tracking after new
> xl_running_xacts. Reason for that is afaics any of the catalog snapshots
> that we assigned to transactions at the end of SnapBuildCommitTxn might
> be corrupted otherwise as they were built before we knew one of the
> supposedly running txes was actually already committed and that
> transaction might have done catalog changes.
Due to the race where LogStandbySnapshot() collects running-xacts info
while a concurrent xact commits, such that the xl_xact_commit appears
before the xl_running_xacts, but the xl_running_xacts still has the
commited xact listed as running, right? Because we update PGXACT only
after we write the commit to WAL, so there's a window where an xact is
committed in WAL but not shown as committed in shmem.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2017-05-01 04:18:31 | Re: Declarative partitioning - another take |
| Previous Message | Petr Jelinek | 2017-05-01 01:54:49 | Re: snapbuild woes |