On Sat, 2009-08-29 at 11:19 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > Specifically, should I remove the parts of the HS patch that refresh
> > those files?
>
> Yes. This was the last part that I was afraid might have insurmountable
> problems. There are some bits yet to do but they're in the nature of
> crank-turning, I believe. I think it's a good bet the flat files will
> be gone before the next commitfest starts.
OK, its gone. Shame really, took a while to make that work. :)
> BTW, one of the to-do bits is to find another way to initialize the
> XID wrap limit at database start. Right now that's set up as a
> side-effect of scanning pg_database to create the flat DB file.
> The idea I had about it was to store the current wrap limit in
> checkpoint WAL records and use the most recent checkpoint's value
> as the initial limit. Can you tell me what you're doing about the
> wrap limit in HS and whether that solution would be an issue for you?
...quakes in boots...
We're weren't doing anything at all. I guess we will be now; thanks for
alerting me.
In general we don't look at the actual xid values themselves, so going
past the xid max value itself shouldn't present an issue (that I can
see, but I will think longer on this).
A problem could occur if a standby query/snapshot lived long enough to
see the same xid in different epochs. Realistically that's a long time
and a query would be unlikely to survive that long without having first
constrained the flow of cleaning records by holding a snapshot open on
the primary. However, it could present a problem to someone and agree we
must have a clear remedial action.
The standard remedial action is to kill queries that cause conflicts, so
we would need to kill queries based upon a wrap test. We could do that
as each xid arrives, but it would be best to do that via something rare
like checkpoint records, so that works for me.
-- Simon Riggs www.2ndQuadrant.com
