| From: | shihao zhong <zhong950419(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Subject: | Re: Bogus recovery conflicts due to outdated XLogReceiptTime |
| Date: | 2026-10-29 02:37:50 |
| Message-ID: | CAGRkXqRLBMSr+Y6GYj7dX2kJne0e4g-cCUXUj6JNqcxsMf4Wag@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Andres,
I hit this issue today because I am trying to reproduce a buffer pin
conflict workload.
I tried your idea and It gives too much grace when the standby
is really behind. I use max_standby_streaming_delay = 5s and
paused replay for 7 seconds and resumed it. It still waited 5 more
seconds before send signal.
The attached patch uses the time of the previous flushedUpto read
instead of now. The WAL at RecPtr was not flushed yet at that read,
so it arrived after it. A standby that keeps up gets a recent time.
A standby that is behind cancels at once.
Thanks,
Shihao
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Fix-stale-XLogReceiptTime-on-a-standby-that-keeps.patch | application/octet-stream | 3.4 KB |
| nocfbot-repro.patch | application/octet-stream | 5.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2026-10-29 02:41:01 | Re: [PATCH] Fix PITR pause bypass when initial XLOG_RUNNING_XACTS has subxid overflow |
| Previous Message | Michael Paquier | 2026-10-29 02:27:24 | Re: WAL record CRC calculated incorrectly because of underlying buffer modification |