Hi,
On Wed, Oct 1, 2025 at 10:02 AM Michael Banck wrote:
>
> Hi,
>
> wow, this is one of the most terrifying threads I've ever seen...
>
> On Tue, Sep 30, 2025 at 12:41:29PM -0400, Tom Lane wrote:
> > Aleksander Alekseev writes:
> > >> Therefore, I would like to request an enhancement: add an op
Hi,
On Wed, Oct 01, 2025 at 02:05:53PM +0200, Jakub Wartak wrote:
> On Wed, Oct 1, 2025 at 1:46 PM Aleksander Alekseev
> wrote:
> > > IMHO all files should be opened at least on startup to check
> > > integrity,
I would say s/startup/crash recovery/, if any.
> > That might be a lot of files to
Hi Jakub,
> IMHO all files should be opened at least on startup to check integrity,
That might be a lot of files to open. Even if you can open a file it
doesn't mean it's not empty or is not corrupted.
--
Best regards,
Aleksander Alekseev
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 o
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
the
Thank you for looking into this Jakub, Aleksander, Michael, Tom,
There are more scenario's where files might be missing: how about a backup
somehow missing files?
But also deliberate sabotage, you can hide data in this way, and it would be
hard to detect, and even
harder to understand what happe
On Wed, Oct 1, 2025 at 1:46 PM Aleksander Alekseev
wrote:
>
> Hi Jakub,
>
> > IMHO all files should be opened at least on startup to check integrity,
>
> That might be a lot of files to open.
I was afraid of that, but let's say modern high-end is 200TB big DB,
that's like 200*1024 1GB files, but
On Wed, Oct 1, 2025 at 11:25 AM Frits Hoogland wrote:
> 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
> unde
On Mon, Oct 6, 2025 at 2:07 PM Laurenz Albe 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 th
Hi Frits,
> 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.
I'm a bit puzzled by your emphasis on primary keys. In Postgres it is
le
On Wed, Oct 1, 2025 at 9:02 AM Michael Banck wrote:
>
> Hi,
>
> wow, this is one of the most terrifying threads I've ever seen...
Same.
> On Tue, Sep 30, 2025 at 12:41:29PM -0400, Tom Lane wrote:
> > Aleksander Alekseev writes:
> > >> Therefore, I would like to request an enhancement: add an op
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
> indica
On Wed, Oct 1, 2025 at 2:15 PM Michael Banck wrote:
> > > That might be a lot of files to open.
> >
> > I was afraid of that, but let's say modern high-end is 200TB big DB,
> > that's like 200*1024 1GB files, but I'm getting such time(1) timings
> > for 204k files on ext4:
> >
> > $ time ./create
Hi,
wow, this is one of the most terrifying threads I've ever seen...
On Tue, Sep 30, 2025 at 12:41:29PM -0400, Tom Lane wrote:
> Aleksander Alekseev writes:
> >> Therefore, I would like to request an enhancement: add an option to
> >> verify_heapam() that causes the primary key index to be scan
> On 1 Oct 2025, at 15:49, Andres Freund 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:
On Tue, 2025-09-30 at 18:55 +0300, Aleksander Alekseev wrote:
> > 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.
>
> I'm a bit p
Thank you for your answer Tom,
As pointed out in another thread of this topic: using the heapallindexed
option, it is
not possible to detect that the table has missing segments and thus missing
data.
What it will detect is if the index is missing data that is existing in the
table, it validate
I am proposing the database to have the ability to detect when it has missing
segments.
One of the main and basic properties of a database is to store data
consistently and reliably.
If the database cannot detect that is missing things, this is a huge breach to
safety and reliability.
And you'r
Aleksander Alekseev writes:
>> 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.
> ... IMO there is little value in adding a check f
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
cons
20 matches
Mail list logo
