On May 29, 2017 11:58:05 AM PDT, Petr Jelinek <petr.jeli...@2ndquadrant.com>
>On 27/05/17 17:17, Andres Freund wrote:
>> On May 27, 2017 9:48:22 AM EDT, Petr Jelinek
>>> 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
>>> Sawada reported . 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
>>> 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
>data copy where we create snapshot for one process but then the next
>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
Read-only txs have no xid ...
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: