Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, rootcause000(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows
Date: 2023-10-05 20:18:24
Message-ID: CA+hUKGLPnyQ+WEZLs6QcH3cwnsciG3CH5KeRq2GpjoTRXHfHUQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Oct 6, 2023 at 8:55 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> ... DELAY_CHKPT_COMPLETE ...

About that... If the lights go out after the truncation and the
delayed logging of the checkpoint, how do we know the truncation has
actually reached the disk? mdtruncate() enqueues fsync() calls, but
if we were already in phase 2 (see proc.h) of a checkpoint at that
moment, they might be processed by the *next* checkpoint, not the one
whose phase 3 we've carefully delayed there, no?

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2023-10-05 21:44:27 BUG #18149: Incorrect lexeme for english token "proxy"
Previous Message Thomas Munro 2023-10-05 19:55:58 Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows