Re: CREATE UNLOGGED TABLE seq faults when debug_discard_caches=1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Spyridon Dimitrios Agathos <spyridon(dot)dimitrios(dot)agathos(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: CREATE UNLOGGED TABLE seq faults when debug_discard_caches=1
Date: 2022-11-17 16:24:29
Message-ID: 1843940.1668702269@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Spyridon Dimitrios Agathos <spyridon(dot)dimitrios(dot)agathos(at)gmail(dot)com> writes:
> while testing the developer settings of PSQL (14.5) I came across this
> issue:

> postgres=# CREATE UNLOGGED TABLE stats (
> postgres(# pg_hash BIGINT NOT NULL,
> postgres(# category TEXT NOT NULL,
> postgres(# PRIMARY KEY (pg_hash, category)
> postgres(# );
> server closed the connection unexpectedly

Hmm ... confirmed in the v14 branch, but v15 and HEAD are fine,
evidently as a result of commit f10f0ae42 having replaced this
unprotected use of index->rd_smgr.

I wonder whether we ought to back-patch f10f0ae42. We could
leave the RelationOpenSmgr macro in existence to avoid unnecessary
breakage of extension code, but stop using it within our own code.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-11-17 16:24:31 Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)
Previous Message Robert Haas 2022-11-17 16:04:52 Re: logical decoding and replication of sequences, take 2