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: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, 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-20 05:17:00
Message-ID: CA+hUKGLtHwNhnphLLUEUpYd2axPeRDp4D9zD5YWSdudYF-3zhQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Oct 20, 2023 at 4:38 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Fri, Oct 20, 2023 at 4:16 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > On Fri, Oct 20, 2023 at 8:50 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > > here are some patches.
> >
> > 0001: LGTM, except in the commit message "By setting
>
> I take that back: there is a palloc() under RelationTruncate(). DNLGTM.

Ooops, I should have quoted to the 0002 patch there.

Hmm. We could teach md.c to do all its path manipulation in
MAXPGPATH-sized output buffers but that still wouldn't be enough
because it might decide to allocate more space for the array of
segments, and I'm not even sure where in PostgreSQL we guarantee that
everything that could appear here would fit in that. But that gives
me an idea. It feels like a bit of a dirty hack, which could perhaps
be made less dirty with some kind of function that includes the word
'ensure' in its name, but I think we can make md.c promise not to
allocate anything before the next CFI with something like this:

* truncate files on disk before they can get the database up
and running
* again. But forcing them to fix permissions (or whatever the
problem is)
* beats corrupting the database.
+ *
+ * First, make sure that smgr doesn't need to allocate any memory to
+ * truncate, since that wouldn't be allowed in a critical
section. We don't
+ * need to call XLogEnsureRecord() for such a small insertion.
*/
+
+ smgrnblocks(RelationGetSmgr(rel), MAIN_FORKNUM);
+ if (fsm)
+ smgrnblocks(RelationGetSmgr(rel), FSM_FORKNUM);
+
START_CRIT_SECTION();

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Vik Fearing 2023-10-20 05:44:23 Re: group by true now errors with non-integer constant in GROUP BY
Previous Message Thomas Munro 2023-10-20 03:38:20 Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows