On Sat, 2009-08-29 at 11:19 -0400, Tom Lane wrote: > Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
