Re: reducing the overhead of frequent table locks - now, with WIP patch - Mailing list pgsql-hackers

From Dave Page
Subject Re: reducing the overhead of frequent table locks - now, with WIP patch
Date
Msg-id BANLkTikknw=w6wetxg3ZTsC_gw9iwCx_8A@mail.gmail.com
Whole thread Raw
In response to Re: reducing the overhead of frequent table locks - now, with WIP patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: reducing the overhead of frequent table locks - now, with WIP patch
List pgsql-hackers
On Tue, Jun 7, 2011 at 12:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>> On Mon, Jun 6, 2011 at 8:44 PM, Stephen Frost <sfrost@snowman.net> wrote:
>>> If we're going to start putting in changes like this, I'd suggest that
>>> we try and target something like September for 9.1 to actually be
>>> released.  Playing with the lock management isn't something we want to
>>> be doing lightly and I think we definitely need to have serious testing
>>> of this, similar to what has been done for the SSI changes, before we're
>>> going to be able to release it.
>
>> Completely aside from the issue at hand, aren't we looking at a
>> September release by now anyway (assuming we have to void late
>> July/August as we usually do)?
>
> Very possibly.  So if we add this in, we're talking November or December
> instead of September.  You can't argue that July/August will be lost
> time for one development path but not another.

That would depend on 2 things - a) whether testing and review of this
single patch would really add 2 - 3 months to the schedule (I'm no
expert on our locking, but I suspect it would not), and b) whether
there are people around over the summer who could test/review. The
reason we usually skip the summer isn't actually a wholesale lack of
people - it's because it's not so good from a publicity perspective,
and it's hard to get all the packagers around at the same time.


--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: HuangQi
Date:
Subject: Re: gdb with postgres
Next
From: Simon Riggs
Date:
Subject: Re: WALInsertLock tuning