From: | Frits Hoogland <frits(dot)hoogland(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | The ability of postgres to determine loss of files of the main fork |
Date: | 2025-09-30 10:01:40 |
Message-ID: | 013D63E2-5D75-492E-85FF-1D5CC0148C82@gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi hackers,
Postgres determines the availability of the main fork, the actual data file,
upon reading it. This is also what amcheck will detect.
However, if a relation exceeds 1GB and has more than a single data file
segment, there is the option of silent data loss. For example, if a table
consists of five segments and the third one goes missing, a sequential scan
will happily conclude that the table consists only of two segments and won't
report an error. Only an index scan that tries to return a row in the
missing segment will report an error.
Currently, this kind of data loss cannot be detected if you check the
integrity of the table using verify_heapam(). Only if you manually use the
primary key index to obtain data from a missing segment, you will get an error.
Therefore, I would like to request an enhancement: add an option to
verify_heapam() that causes the primary key index to be scanned and makes
sure that all line pointers in the index point to existing tuples.
An alternative might be to track the number of segments of a relation in
pg_class, but that may be difficult to make crash-safe.
Frits Hoogland
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2025-09-30 10:05:43 | Re: [BUG]: the walsender does not update its IO statistics until it exits |
Previous Message | shveta malik | 2025-09-30 09:44:57 | Re: Issue with logical replication slot during switchover |