Re: lock_timeout GUC patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Subject: Re: lock_timeout GUC patch
Date: 2010-01-21 14:17:01
Message-ID: 603c8f071001210617n4f952458r1a58f24a97bfaf29@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/1/21 Boszormenyi Zoltan <zb(at)cybertec(dot)at>:
> Tom Lane írta:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> I think that it is a very bad idea to implement this feature in a way
>>> that is not 100% portable.
>>
>> Agreed, this is not acceptable.  If there were no possible way to
>> implement the feature portably, we *might* consider doing it like this.
>> But I think more likely it'd get rejected anyway.  When there is a
>> clear path to a portable solution, it's definitely not going to fly
>> to submit a nonportable one.
>
> OK, I will implement it using setitimer().
> It may not reach 8.5 though, when will this last Commitfest end?

The CommitFest ends 2/15, but that's not really the relevant metric.
Patches will be marked Returned with Feedback if they are not updated
within 4-5 days of the time they were last reviewed, or more
aggressively as we get towards the end. Also, if a patch needs a
major rewrite, it should be marked Returned with Feedback and
resubmitted for this CommitFest. It sounds like this patch meets that
criterion; in addition, Tom has expressed concerns that this might be
something that should be committed early in the release cycle rather
than at the very end.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-01-21 14:30:56 Re: attoptions
Previous Message Heikki Linnakangas 2010-01-21 14:10:39 Re: Streaming replication and a disk full in primary