| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Paul Kim <mok03127(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Be strict when request to flush past end of WAL in WaitXLogInsertionsToFinish |
| Date: | 2026-09-04 00:11:58 |
| Message-ID: | CALj2ACVboxJKWhOf8z-KFStmxjV7RAfVsP73-OuYDvqUHPaDCw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Thu, Sep 3, 2026 at 5:05 PM Paul Kim <mok03127(at)gmail(dot)com> wrote:
>
> Thanks, both. Attached is v2: 0001 is the fix, unchanged from v1, and
> 0002 adds the reproducer as a TAP test on HEAD.
>
> The test adds a small module, src/test/modules/test_walwriter, with one
> C function that requests a segment switch and then stores the resulting
> insert position in asyncXactLSN. After a switch that position is just
> past the new segment's long page header, beyond the end of generated
> WAL, so the walwriter's next cycle requests a flush past the end of
> generated WAL -- the same shape as the production request.
>
> I did look at injection points first, but there is no INJECTION_POINT()
> in this path, and what the reproducer needs is a bogus value stored
> into asyncXactLSN rather than a backend stopped at a particular point,
> which would require a custom callback and hence a test module anyway.
Thanks for the v2 patches. Just curious, how did the bogus LSN end up
in asyncXactLSN in production when you hit the issue?
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2026-09-04 00:23:00 | Re: Use WALReadFromBuffers in more places |
| Previous Message | Paul Kim | 2026-09-04 00:04:47 | Re: Be strict when request to flush past end of WAL in WaitXLogInsertionsToFinish |