On 27/05/17 17:17, Andres Freund wrote: > > > On May 27, 2017 9:48:22 AM EDT, Petr Jelinek <petr.jeli...@2ndquadrant.com> > wrote: >> Actually, I guess it's the pid 47457 (COPY process) who is actually >> running the xid 73322726. In that case that's the same thing Masahiko >> Sawada reported [1]. Which basically is result of snapshot builder >> waiting for transaction to finish, that's normal if there is a long >> transaction running when the snapshot is being created (and the COPY is >> a long transaction). > > Hm. I suspect the issue is that the exported snapshot needs an xid for some > crosscheck, and that's what we're waiting for. Could you check what happens > if you don't assign one and just content the error checks out? Not at my > computer, just theorizing. >
I don't think that's it, in my opinion it's the parallelization of table data copy where we create snapshot for one process but then the next one has to wait for the first one to finish. Before we fixed the snapshotting, the second one would just use the ondisk snapshot so it would work fine (except the snapshot was corrupted of course). I wonder if we could somehow give it a hint to ignore the read-only txes, but then we have no way to enforce the txes to stay read-only so it does not seem safe. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
