Re: reducing the overhead of frequent table locks - now, with WIP patch
От | Dave Page |
---|---|
Тема | Re: reducing the overhead of frequent table locks - now, with WIP patch |
Дата | |
Msg-id | BANLkTikknw=w6wetxg3ZTsC_gw9iwCx_8A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: reducing the overhead of frequent table locks - now, with WIP patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: reducing the overhead of frequent table locks - now,
with WIP patch
|
Список | 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 по дате отправления: