From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Assert while autovacuum was executing |
Date: | 2023-06-21 05:27:13 |
Message-ID: | 20230621052713.wc5377dyslxpckfj@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-06-20 15:14:26 +0530, Amit Kapila wrote:
> On Mon, Jun 19, 2023 at 5:13 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Sun, Jun 18, 2023 at 12:18 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> > >
> > > On Sat, Jun 17, 2023 at 11:29 AM Jaime Casanova
> > > <jcasanov(at)systemguards(dot)com(dot)ec> wrote:
> > > > I have been testing 16beta1, last commit
> > > > a14e75eb0b6a73821e0d66c0d407372ec8376105
> > > > I just let sqlsmith do its magic before trying something else, and
> > > > today I found a core with the attached backtrace.
> > >
> > > The assertion that fails is the IsPageLockHeld assertion from commit 72e78d831a.
> > >
> >
> > I'll look into this and share my analysis.
> >
>
> This failure mode appears to be introduced in commit 7d71d3dd08 (in
> PG16) where we started to process the config file after acquiring page
> lock during autovacuum.
I find it somewhat hard to believe that this is the only way to reach this
issue. You're basically asserting that there's not a single cache lookup
reachable from inside ginInsertCleanup() - which seems unlikely, given the
range of comparators that can exist.
<plays around>
Yep. Doesn't even require enabling debug_discard_caches or reconnecting.
DROP TABLE IF EXISTS tbl_foo;
DROP TYPE IF EXISTS Foo;
CREATE TYPE foo AS ENUM ('a', 'b', 'c');
ALTER TYPE foo ADD VALUE 'ab' BEFORE 'b';
CREATE TABLE tbl_foo (foo foo);
CREATE INDEX tbl_foo_idx ON tbl_foo USING gin (foo) WITH (fastupdate = on);
INSERT INTO tbl_foo(foo) VALUES ('ab'), ('a'), ('b'), ('c');
SELECT gin_clean_pending_list('tbl_foo_idx');
As far as I can tell 72e78d831a as-is is just bogus. Unfortunately that likely
also means 3ba59ccc89 is not right.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-06-21 05:39:24 | Re: Adding further hardening to nbtree page deletion |
Previous Message | Michael Paquier | 2023-06-21 05:14:52 | Re: [BUG] recovery of prepared transactions during promotion can fail |