Simon Riggs <si...@2ndquadrant.com> wrote: > I looked at the patch to begin a review and immediately saw > "dtest". There's no docs to explain what it is, but a few comments > fill me in a little more. Can we document that please? And/or > explain why its an essential part of this commit? Could we keep it > out of core, or if not, just commit that part separately? I notice > the code is currently copyright someone else than PGDG. I'm including Markus on this reply, because he's the only one who can address the copyright issue. I will say that while the dcheck make target is not required for a proper build, and the tests run for too long to consider including this in the check target, I would not recommend that anybody hack on SSI without regularly running these tests or some equivalent.. When I suggested breaking this out of the patch, everybody who spoke up said not to do so. How the eventual committer commits it is of course up to that person. > Pounding for hours on 16 CPU box sounds good. What diagnostics or > instrumentation are included with the patch? How will we know > whether pounding for hours is actually touching all relevant parts > of code? I've done such things myself only to later realise I > wasn't actually testing the right piece of code. We've looked at distributions of failed transactions by ereport statement. This confirms that we are indeed exercising the vast majority of the code. See separate post for how we pushed execution into the summarization path to test code related to that. I do have some concern that the 2PC testing hasn't yet covered all code paths. I don't see how the problem found by Jeff during review could have survived thorough testing there. > When this runs in production, how will we know whether SSI is > stuck Stuck? I'm not sure what you mean by that. Other than LW locking (which I believe is always appropriately brief, with rules for order of acquisition which should prevent deadlocks), the only blocking introduced by SSI is when there is an explicit request for DEFERRABLE READ ONLY transactions. Such a transaction may take a while to start. Is that what you're talking about? > or is consuming too much memory? Relevant shared memory is allocated at startup, with strategies for living within that as suggested by Heikki and summarized in a recent post by Jeff. It's theoretically possible to run out of certain objects, in which case there is an ereport, but we haven't seen anything like that since the mitigation and graceful degradation changes were implemented. > e.g. Is there a dynamic view e.g. pg_prepared_xacts, We show predicate locks in the pg_locks view with mode SIReadLock. > is there a log mode log_ssi_impact, etc?? Don't have that. What would you expect that to show? -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
