| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, 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>, 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-22 23:35:05 |
| Message-ID: | CA+hUKGK1+3rj3c7L9HPCc8HajTVmkTx1CEkU5=rqgV3b4OvWeQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Sep 22, 2023 at 4:02 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Fri, Sep 22, 2023 at 03:11:54PM +1200, Thomas Munro wrote:
> > A thought: commit 8fcb32db prevented us from logging messages that are
> > too big to be decoded, but it wasn't back-patched.
>
> Yes, there was one part done in ffd1b6bb6f8 that has required ABI
> breakages, as well. There is an argument against a backpatch as a
> set of records in a given range may fail to replay while they were
> allowed before (I forgot the exact math, but I recall that this was
> for records larger than XLogRecordMaxSize, still lower than the max
> allocation mark.).
Hmm, OK, tricky choices. Anyway, I guess the next thing to straighten
out in this area is the OOM policy.
Pushed. Thanks Alexander and everyone for the report, testing and
help! Time to watch the build farm to see if that Perl turns out to
be robust enough...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-09-23 00:05:42 | Re: BUG #17928: Standby fails to decode WAL on termination of primary |
| Previous Message | Andrew Dunstan | 2023-09-22 21:37:37 | Re: why are null bytes allowed in JSON columns? |