| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi(dot)shinoda(at)hpe(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Jakub Wartak <Jakub(dot)Wartak(at)tomtom(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg15b3: recovery fails with wal prefetch enabled |
| Date: | 2022-09-01 01:37:19 |
| Message-ID: | CA+hUKG+jiB5W7-N4zhvpUXwQ_XZgYLioWxPcXKvmKw4XYKUF4g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 1, 2022 at 12:53 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> Yes, I have a copy that reproduces the issue:
That's good news.
So the last record touching that page was:
> rmgr: Heap2 len (rec/tot): 59/ 59, tx: 0, lsn: 1201/1CAF84B0, prev 1201/1CAF8478, desc: VISIBLE cutoff xid 3678741092 flags 0x01, blkref #0: rel 1663/16881/2840 fork vm blk 0, blkref #1: rel 1663/16881/2840 blk 53
I think the expected LSN for that page is past the end of that record,
so 0x1CAF84B0 + 59 = 0x1caf84eb which rounds up to 0x1CAF84F0, and
indeed we see that in the restored page when recovery succeeds.
Next question: why do we think the WAL finishes at 1201/1CADB730 while
running that checkpoint? Looking...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2022-09-01 01:47:33 | Re: SELECT documentation |
| Previous Message | Kyotaro Horiguchi | 2022-09-01 01:28:20 | Re: Add tracking of backend memory allocated to pg_stat_activity |