> > > The point is, that the heap page is only modified in
> > > places that were previously empty (except header).
> > > All previous row data stays exactly in the same place.
> > > Thus if a page is only partly written
> > > (any order of page segments) only a new row is affected.
> >
> > Excep
> > The only source of serious problems is thus a bogus write of a page
> > segment (100 bytes ok 412 bytes chunk actually written to disk),
> > but this case is imho sufficiently guarded or at least detected
> > by disk hardware.
>
> With full page logging after checkpoint we would be safe fro
"Mikheev, Vadim" wrote:
>
> > The point is, that the heap page is only modified in places that were
> > previously empty (except header). All previous row data stays exactly
> > in the same place. Thus if a page is only partly written
> > (any order of page segments) only a new row is affected.
>
> The point is, that the heap page is only modified in places that were
> previously empty (except header). All previous row data stays exactly
> in the same place. Thus if a page is only partly written
> (any order of page segments) only a new row is affected.
Exception: PageRepairFragmentatio
A heap page corruption is not very likely in PostgreSQL because of the
underlying page design. Not even on flakey hardware/ossoftware.
(I once read a page design note from pg 4 but don't exactly remember
were or when)
The point is, that the heap page is only modified in places that were
previou
A heap page corruption is not very likely in PostgreSQL because of the
underlying page design. Not even on flakey hardware/ossoftware.
(I once read a page design note from pg 4 but don't exactly remember
were or when)
The point is, that the heap page is only modified in places that were
previou
