Re: Refactor pg_rewind code and make it work against a standby - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Refactor pg_rewind code and make it work against a standby
Date
Msg-id 606796.1605424022@sss.pgh.pa.us
Whole thread Raw
In response to Re: Refactor pg_rewind code and make it work against a standby  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Refactor pg_rewind code and make it work against a standby  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
I wrote:
> Not sure if you noticed, but piculet has twice failed the
> 007_standby_source.pl test that was added by 9c4f5192f:
> ...
> Now, I'm not sure what to make of that, but I can't help noticing that
> piculet uses --disable-atomics while francolin uses --disable-spinlocks.
> That leads the mind towards some kind of low-level synchronization
> bug ...

Or, maybe it's less mysterious than that.  The failure looks like we
have not waited long enough for the just-inserted row to get replicated
to node C.  That wait is implemented as

    $lsn = $node_a->lsn('insert');
    $node_b->wait_for_catchup('node_c', 'write', $lsn);

which looks fishy ... shouldn't wait_for_catchup be told to
wait for replay of that LSN, not just write-the-WAL?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: POC: Cleaning up orphaned files using undo logs
Next
From: Julien Rouhaud
Date:
Subject: Re: Supporting = operator in gin/gist_trgm_ops