| 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
| 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 |