Re: Assert while autovacuum was executing - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Assert while autovacuum was executing
Date
Msg-id 20230622163813.sygaitdplm4wfr2a@awork3.anarazel.de
Whole thread Raw
In response to Re: Assert while autovacuum was executing  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Hi,

On 2023-06-22 10:00:01 +0530, Amit Kapila wrote:
> On Wed, Jun 21, 2023 at 11:53 AM Peter Geoghegan <pg@bowt.ie> wrote:
> >
> > On Tue, Jun 20, 2023 at 10:27 PM Andres Freund <andres@anarazel.de> wrote:
> > > As far as I can tell 72e78d831a as-is is just bogus. Unfortunately that likely
> > > also means 3ba59ccc89 is not right.
> >
> > Quite possibly. But I maintain that ginInsertCleanup() is probably
> > also bogus in a way that's directly relevant.
> >
> > Did you know that ginInsertCleanup() is the only code that uses
> > heavyweight page locks these days? Though only on the index metapage!
> >
> > Isn't this the kind of thing that VACUUM's relation level lock is
> > supposed to take care of?
> >
> 
> Yeah, I also can't see why that shouldn't be sufficient for VACUUM.

I'd replied on that point to Peter earlier, accidentlly loosing the CC
list. The issue is that ginInsertCleanup() isn't just called from VACUUM, but
also from normal inserts (to reduce the size of the fastupdate list).

You can possibly come up with another scheme, but I think just doing this via
the relation lock might be problematic. Suddenly an insert would, temporarily,
also block operations that don't normally conflict with inserts etc.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tommy Pavlicek
Date:
Subject: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges
Next
From: Andres Freund
Date:
Subject: Re: vac_truncate_clog()'s bogus check leads to bogusness