Hi, On 2023-06-20 15:14:26 +0530, Amit Kapila wrote: > On Mon, Jun 19, 2023 at 5:13 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Sun, Jun 18, 2023 at 12:18 AM Peter Geoghegan <p...@bowt.ie> wrote: > > > > > > On Sat, Jun 17, 2023 at 11:29 AM Jaime Casanova > > > <jcasa...@systemguards.com.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