Re: The ability of postgres to determine loss of files of the main fork - Mailing list pgsql-hackers

From Jakub Wartak
Subject Re: The ability of postgres to determine loss of files of the main fork
Date
Msg-id CAKZiRmz8FzrPg_r1uRYN4J04zv2CTdk=KoCpxCXf5P-M7pQvDw@mail.gmail.com
Whole thread Raw
In response to Re: The ability of postgres to determine loss of files of the main fork  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-hackers
On Mon, Oct 6, 2025 at 2:07 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> On Mon, 2025-10-06 at 11:19 +0200, Jakub Wartak wrote:
> > Anyway, I do not know if opening all the files on startup (or just
> > crash-recovery?) is the proper way
>
> I am not sure if you understand the problem at hand: how can you
> tell that a segment of a relation is missing?  You have to know that
> there should be a file before you can try to open it.

I'm pretty aware that PG doesnt track the relation segment count, but
possibly it should as without that nasty stuff can happen. Then the
discussion was mostly on how practical it would be to just open all
files on big DBs during startup (if we know them in advance), but it
is just one of the ideas I suspect, I've just checked those timings
out of curiosity.

Anyway there's also a referenced earlier idea for single file relation
model by Thomas.

Another fun-fact: see READ_ONLY_OPEN_DELAYED details in Oracle.

-J.



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Eager aggregation, take 3
Next
From: Ashutosh Bapat
Date:
Subject: Re: Improve pg_sync_replication_slots() to wait for primary to advance