Hi,
Le 4 juin 09 à 15:55, Alvaro Herrera a écrit :
I tend to hate automatic zeroing of pages because there's no way to
get
the contents later for forensics. I would support your proposal if we
had a way of saving the block elsewhere before zeroing it (say
create a
directory corrupted+zeroed
On Thu, 2009-06-04 at 10:02 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > What seems strange about the various errors generated in bufpage.c is
> > that they are marked as ERRORs, yet are executed within a critical
> > section causing the system to PANIC.
>
> The reason we PANIC there is to r
Simon Riggs writes:
> What seems strange about the various errors generated in bufpage.c is
> that they are marked as ERRORs, yet are executed within a critical
> section causing the system to PANIC.
The reason we PANIC there is to reduce the probability that bad data
will be written back to disk
On Thu, Jun 4, 2009 at 2:55 PM, Alvaro Herrera
wrote:
> I tend to hate automatic zeroing of pages because there's no way to get
> the contents later for forensics.
That's why we default to zero_damaged_pages=false. Saving the pages
somewhere seems like it would be a good feature to add for
zero_
Simon Riggs wrote:
> I would much prefer:
>
> * VACUUMs seeing these errors would perform as with zero_damaged_pages.
> * other backends seeing those errors should just ERROR out.
>
> We can do this by having a new function: boolean PageIsValid() which
> performs the sanity checks. This can th
I've seen a couple of *topic issues lately.
What seems strange about the various errors generated in bufpage.c is
that they are marked as ERRORs, yet are executed within a critical
section causing the system to PANIC.
There are a number of sanity checks that are made prior to any changes
taking
