Re: logical changeset generation v3 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: logical changeset generation v3
Date
Msg-id 20121121232555.GC6658@awork2.anarazel.de
Whole thread Raw
In response to Re: logical changeset generation v3  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: logical changeset generation v3  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On 2012-11-21 18:35:34 +0900, Michael Paquier wrote:
> On Wed, Nov 21, 2012 at 4:34 PM, Andres Freund <andres@2ndquadrant.com>wrote:
> 
> > On 2012-11-21 14:57:08 +0900, Michael Paquier wrote:
> >
> > Ah, I see. Could you try the following diff?
> >
> > diff --git a/src/backend/replication/logical/snapbuild.c
> > b/src/backend/replication/logical/snapbuild.c
> > index df24b33..797a126 100644
> > --- a/src/backend/replication/logical/snapbuild.c
> > +++ b/src/backend/replication/logical/snapbuild.c
> > @@ -471,6 +471,7 @@ SnapBuildDecodeCallback(ReorderBuffer *reorder,
> > Snapstate *snapstate,
> >                  */
> >                 snapstate->transactions_after = buf->origptr;
> >
> > +               snapstate->nrrunning = running->xcnt;
> >                 snapstate->xmin_running = InvalidTransactionId;
> >                 snapstate->xmax_running = InvalidTransactionId;
> >
> I am still getting the same assertion failure even with this diff included.

I really don't understand whats going on here then. Youve said you made
sure that there is a catalog snapshot. Which means you would need
something like:
WARNING:  connecting to postgres
WARNING:  Initiating logical rep
LOG:  computed new xmin: 16566894
LOG:  start reading from 3/E62457C0, scrolled back to 3/E6244000
LOG:  found initial snapshot (via running xacts). Done: 1
WARNING:  reached consistent point, stopping!
WARNING:  Starting logical replication
LOG:  start reading from 3/E62457C0, scrolled back to 3/E6244000
LOG:  found initial snapshot (via running xacts). Done: 1

in the log *and* it means that snapbuild->state has to be
CONSISTENT. But the backtrace youve posted:

#3  0x000000000070c409 in SnapBuildTxnIsRunning (snapstate=0x19e4f10,xid=0) at snapbuild.c:877
#4  0x000000000070b8e4 in SnapBuildProcessChange (reorder=0x19e4e80,snapstate=0x19e4f10, xid=0, buf=0x1a0a368,
relfilenode=0x1a0a450)at snapbuild.c:388
 
#5  0x000000000070c088 in SnapBuildDecodeCallback (reorder=0x19e4e80,snapstate=0x19e4f10, buf=0x1a0a368) at
snapbuild.c:732

shows pretty clearly that snapstate *can't* be consistent because line 387ff is:     else if (snapstate->state <
SNAPBUILD_CONSISTENT&&              SnapBuildTxnIsRunning(snapstate, xid))    ;
 
so #3 #4 can't happen at those line numbers with state == CONSISTENT.

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: auto_explain WAS: RFC: Timing Events
Next
From: Gavin Flower
Date:
Subject: Re: auto_explain WAS: RFC: Timing Events