Re: lock_timeout GUC patch - Mailing list pgsql-hackers

From Robert Haas
Subject Re: lock_timeout GUC patch
Date
Msg-id 603c8f071001210617n4f952458r1a58f24a97bfaf29@mail.gmail.com
Whole thread Raw
In response to Re: lock_timeout GUC patch  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: lock_timeout GUC patch  (Boszormenyi Zoltan <zb@cybertec.at>)
List pgsql-hackers
2010/1/21 Boszormenyi Zoltan <zb@cybertec.at>:
> Tom Lane írta:
>> Robert Haas <robertmhaas@gmail.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


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Streaming replication and a disk full in primary
Next
From: Robert Haas
Date:
Subject: Re: attoptions