| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Sergei Kornilov <sk(at)zsrv(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
| Subject: | Re: BUG #17928: Standby fails to decode WAL on termination of primary |
| Date: | 2023-09-16 04:13:33 |
| Message-ID: | ZQUrbfwQVr417W0v@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Sat, Sep 16, 2023 at 12:20:36PM +1200, Thomas Munro wrote:
> It has to do with initial WAL position after initdb, because I get
> this only on Debian, on REL_12_STABLE (with the commit listed above on
> my public fix-12 branch) and only with --with-icu, but not without it,
> and I can't repro it on my other local OSes.
That's close to my dev environment, with SID and x64 and the only
difference your branch and my local branch is a rename of the TAP
file, and I cannot see the problem.
Some random thoughts: perhaps reducing $page_threshold would help with
more records inserted to get to the limit of a page, reducing noise?
Or perhaps skipping a few pages would?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Lakhin | 2023-09-16 06:00:00 | Re: BUG #17928: Standby fails to decode WAL on termination of primary |
| Previous Message | Thomas Munro | 2023-09-16 00:20:36 | Re: BUG #17928: Standby fails to decode WAL on termination of primary |