Skip site navigation (1) Skip section navigation (2)

Re: time table for beta1

From: Dan Ports <drkp(at)csail(dot)mit(dot)edu>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: time table for beta1
Date: 2011-04-04 18:37:07
Message-ID: 20110404183707.GA90937@csail.mit.edu (view raw or flat)
Thread:
Lists: pgsql-hackers
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/

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-04-04 18:38:59
Subject: Disable optimization when in subtransaction
Previous:From: Josh BerkusDate: 2011-04-04 17:34:20
Subject: Re: time table for beta1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group