On Mon, Apr 04, 2011 at 10:33:22AM -0500, Kevin Grittner wrote: > There are patches for all known issues except one. Dan Ports was > able to replicate the latest issue uncovered by YAMAMOTO Takashi > using a particular DBT-2 configuration, found the issue, and posted > a patch:
Well, it would be good to have confirmation from Takashi that it actually fixed the problem he was seeing. I expect it did. If so, then yes, we do have a handle on all open SSI issues. > In investigating the locks which were not being cleaned up properly, > Dan noticed that the pid wasn't showing on SIReadLock rows in > pg_locks. He submitted a patch here which would always show the pid > responsible for the lock: > > Jeff Davis questioned whether pid should continue to show after the > end of the transaction or the closing of the connection (and > therefore the process which the pid identifies). Not showing it for > completed transactions would be trivial. Showing it after the > transaction completes, until the connection closes should be doable, > but not trivial. Of course, we could just leave it alone, but > leaving the pid out for these rows looks a little funny and reduces > useful information a bit. I see Robert committed that one already. If there's a consensus that omitting the pid for committed transactions is the right thing to do, I'm happy to put together a patch. I think that is a better approach than trying to keep it after commit until the connection closes, but all of this is sufficiently minor that it's probably not worth worrying much about. > The one issue without a reasonable patch is that there are now three > HTABs in shared memory which can grow until shared memory is > exhausted, rather than the one in heavyweight locks which we had > prior to 9.1. I think we're agreed that this is a bad thing, but my > attempts to address this so far haven't satisfied Heikki. Heikki > suggested an approach, but didn't respond as to whether I should try > to code it up. I wasn't sure whether he might be going at it > himself. I'll happily take a run at it if people want that. I believe implementing that should just be a matter of making get_hash_entry bail out before element_alloc if the right flag is set, because partitioned hash tables already don't split buckets. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers