Re: [HACKERS] logical replication busy-waiting on a lock
От | Petr Jelinek |
---|---|
Тема | Re: [HACKERS] logical replication busy-waiting on a lock |
Дата | |
Msg-id | b278554c-112f-b434-a063-2f67ff5a9c70@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] logical replication busy-waiting on a lock (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] logical replication busy-waiting on a lock
|
Список | pgsql-hackers |
On 27/05/17 17:17, Andres Freund wrote: > > > On May 27, 2017 9:48:22 AM EDT, Petr Jelinek <petr.jelinek@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 waitingfor. 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
В списке pgsql-hackers по дате отправления: