| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: standby promotion can create unreadable WAL |
| Date: | 2022-08-23 02:38:42 |
| Message-ID: | 20220823023842.GA1131902@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Aug 22, 2022 at 02:36:36PM -0400, Robert Haas wrote:
> (Incidentally, there's also a bug in pg_waldump here: it's reporting
> the wrong LSN as the source of the error. 0/4FFF700 is not the record
> that's busted, as shown by the fact that it was successfully decoded
> and shown in the output. The relevant code in pg_waldump should be
> using EndRecPtr instead of ReadRecPtr to report the error. If it did,
> it would complain about 0/4FFFEA8, which is where the problem really
> is. This is of the same vintage as the bug fixed by
> d9fbb8862959912c5266364059c0abeda0c93bbf, though in that case the
> issue was reporting all errors using the start LSN of the first of
> several records read no matter where the error actually happened,
> whereas in this case the error is using the start LSN of the previous
> record instead of the current one.)
There was some previous discussion on this [0] [1].
[0] https://postgr.es/m/2B4510B2-3D70-4990-BFE3-0FE64041C08A%40amazon.com
[1] https://postgr.es/m/20220127.100738.1985658263632578184.horikyota.ntt%40gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro Horiguchi | 2022-08-23 02:53:30 | Re: Improve description of XLOG_RUNNING_XACTS |
| Previous Message | Michael Paquier | 2022-08-23 02:36:57 | Re: pg_basebackup: add test about zstd compress option |