|From:||Simon Riggs <simon(at)2ndQuadrant(dot)com>|
|To:||Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>|
|Subject:||Re: Deriving Recovery Snapshots|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Wed, 2008-10-22 at 17:29 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > You may be missing my point.
> > We need an initial state to work from.
> > I am proposing we write a full snapshot after each checkpoint because it
> > allows us to start recovery again from that point. If we wrote only
> > OldestXmin as you suggest it would optimise the size of the WAL record
> > but it would prevent us from restarting at that point.
> Well, you'd just need to treat anything > oldestxmin, and not marked as
> finished in clog, as unobserved. Which doesn't seem too bad. Not that
> storing the full list of in-progress xids is that bad either, though.
As I said, I'm storing the whole list to give me an initial state.
> Hmm. What about in-progress subtransactions that have overflowed the
> shared mem cache? Can we rely that subtrans is up-to-date, up to the
> checkpoint record that recovery starts from?
Yes, we can't use snapshots as an initial state if they have overflowed.
In that case we could avoid dropping full snapshot to WAL, yes. That's
probably trivial to implement.
Currently, the patch can start from a non-overflowed snapshot, but it
could also start from an overflowed snapshot and wait until we receive a
snapshot with an xmin > the xmax of the first snapshot. That seemed too
much icing for the first patch. I think we need to all agree on the
correctness aspects before we attempt too much tuning and tweaking.
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
|Next Message||Simon Riggs||2008-10-22 14:53:38||Re: Deriving Recovery Snapshots|
|Previous Message||Jaime Casanova||2008-10-22 14:44:46||Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1|