From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: better page-level checksums |
Date: | 2022-06-14 16:26:05 |
Message-ID: | 79532.1655223965@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Tue, Jun 14, 2022 at 8:48 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> However, pg_filedump and I think also some code internal
>> to PostgreSQL try to figure out what kind of page we've got by looking
>> at the *size* of the special space. It's only good luck that we
>> haven't had a collision there yet, and continuing to rely on that
>> seems like a dead end. Perhaps we should start including a per-AM
>> magic number at the beginning of the special space.
It's been some years since I had much to do with pg_filedump, but
my recollection is that the size of the special space is only one
part of its heuristics, because there already *are* collisions.
Moreover, there already are per-AM magic numbers in there that
it uses to resolve those cases. They're not at the front though.
Nobody has ever wanted to break on-disk compatibility just to make
pg_filedump's page-type identification less klugy, so I find it
hard to believe that the above suggestion isn't a non-starter.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Álvaro Herrera | 2022-06-14 16:44:09 | Re: Small TAP improvements |
Previous Message | Tom Lane | 2022-06-14 16:20:56 | Re: Small TAP improvements |