Re: time table for beta1 - Mailing list pgsql-hackers

Robert Haas <robertmhaas@gmail.com> wrote:
> I have the impression from the SSI threads that there might be an
> issue or two there that needs to be dealt with, but there again I
> think that there are patches already posted, and that we just need
> to get around to dealing with them.
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:
http://archives.postgresql.org/pgsql-hackers/2011-04/msg00083.php
An earlier assertion failure found by YAMAMOTO Takashi is fixed by a
patch I posted:
http://archives.postgresql.org/pgsql-bugs/2011-03/msg00352.php
While not bugs, per se, the reporting for out-of-shared-memory was
clumsy.  This is addressed with this patch:
http://archives.postgresql.org/pgsql-hackers/2011-03/msg01170.php
The only user-visible change of that one is that a hint will appear
when intended rather than getting the identical message without the
hint from a lower-level function.
The above patches look to me like they should be committable without
needing a lot of committer time.  None of them are very big.
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:
http://archives.postgresql.org/pgsql-hackers/2011-04/msg00033.php
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.
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.
Should these items be on the open issues list?
> At the risk of getting laughed at, how about, say, ~2 weeks from
> now? Plus or minus a couple of days based on people's schedules
> and which day of the week we'd like the wrap to happen on.
I feel good about that from an SSI perspective, as long as some
committer can look at these patches.  I can't comment on any of the
other areas.
-Kevin