Re: Avoiding adjacent checkpoint records

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> there is no guarantee that we'll manage to reach a database state
> that is consistent with data already flushed out to disk during
> the last checkpoint.

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> I know of real customers who would have suffered real data loss
> had this code been present in the server version they were using.
> Checkpoints are the *only* mechanism by which SLRU pages get
> flushed to disk on a mostly-idle system. That means if something
> happens to your pg_xlog directory, and you haven't had a
> checkpoint, you're screwed.

Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:

> How come this is a valid discussion? Why does making changes here
> make sense when other changes are said to destabilise the code and
> delay release?

I think the standard has been pretty clear -- at this point in a
release we fix bugs and regressions from previous releases. The bar
for introducing anything which doesn't qualify under either of those
is very high in terms of being obviously useful and *very* low risk.

> Should I revisit all the things others have done that I disagree
> with as well?

If you can spot any serious bugs, I would sure appreciate it if you
point them out while we're still in beta. I think we all would.

> I'll look some more at this, but you should consider why this
> thread even exists.

Because the beta release contains a new data loss bug which needs to
be fixed.

-Kevin