Re: parallel pg_dump causes assertion failure in HEAD

On 2014-03-05 18:39:52 +0100, Andres Freund wrote:
> On March 5, 2014 6:07:43 PM CET, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >$ pg_dump -F d -j 4 -f foo regression
> >pg_dump: [archiver (db)] query failed: pg_dump: [parallel archiver]
> >query was: SET TRANSACTION SNAPSHOT '00002130-1'
> >pg_dump: [archiver (db)] query failed: pg_dump: [archiver (db)] query
> >failed: pg_dump: [archiver (db)] query failed: $
> >
> >postmaster log shows:
> >
> >TRAP: FailedAssertion("!(HistoricSnapshotActive())", File: "snapmgr.c",
> >Line: 355)
> >TRAP: FailedAssertion("!(HistoricSnapshotActive())", File: "snapmgr.c",
> >Line: 355)
> >TRAP: FailedAssertion("!(HistoricSnapshotActive())", File: "snapmgr.c",
> >Line: 355)
> >TRAP: FailedAssertion("!(HistoricSnapshotActive())", File: "snapmgr.c",
> >Line: 355)
> >LOG: server process (PID 15069) was terminated by signal 6: Aborted
> >DETAIL: Failed process was running: SET TRANSACTION SNAPSHOT
> >'00002130-1'
> >LOG: terminating any other active server processes
> >
> >That Assert appears to have been introduced by commit b89e1510.
>
> It's a typo. It should make sure there is *no* historical
> snapshot. Will later test if it really works, but I'd be surprised if
> not.

So, after crashing my laptop by doing pg_dump -j16 on a cluster with 4GB
of shared_buffers (causing 16 parallel coredumps to be written) I can
confirm that indeed that the reason is just a typo in an assert.

Patch fixing that attached, it also includes a fix for a comment in a
related checks for historical snapshots.

Greetings,

Andres Freund

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