Re: The ability of postgres to determine loss of files of the main fork

From: Frits Hoogland <frits(dot)hoogland(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Aleksander Alekseev <aleksander(at)tigerdata(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: The ability of postgres to determine loss of files of the main fork
Date: 2025-10-01 15:25:00
Message-ID: BED39015-2035-4565-80C1-3B9C40EA01CB@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> On 1 Oct 2025, at 15:49, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2025-10-01 15:39:04 +0200, Laurenz Albe wrote:
>> On Wed, 2025-10-01 at 13:58 +0200, Frits Hoogland wrote:
>>> I am proposing the database to have the ability to detect when it has missing segments.
>>
>> Just a random idea: one solution would be if each segment has a flag that indicates
>> if that is the last segment or not. But that would break the on-disk storage format,
>> unless there is room left for an extra flag somewhere in the current layout.
>
> It'd also make extensions / truncations more complicated. I rather doubt we're
> going there. Right now relation extension aren't WAL logged. While there might
> be reasons to change that, I don't think this is enough justification for
> doing so.
>

What would be a achievable way of making postgres under the relation size?
How about a field in pg_class that keeps the final data page, so that the catalog
keeps the size, which then allows utilities and the database itself to understand how
many segments should exist?

> Greetings,
>
> Andres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2025-10-01 15:53:26 Re: Proposal: Adding compression of temporary files
Previous Message Dilip Kumar 2025-10-01 15:23:01 Re: pgstattuple "unexpected zero page" for gist and hash indexes