| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Refactor pg_rewind code and make it work against a standby |
| Date: | 2020-11-15 07:07:02 |
| Message-ID: | 606796.1605424022@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2020-11-15 07:18:25 | Re: Supporting = operator in gin/gist_trgm_ops |
| Previous Message | Amit Kapila | 2020-11-15 06:54:54 | Re: POC: Cleaning up orphaned files using undo logs |