2011/6/17 Shigeru Hanada :
> (2011/06/12 6:43), Noah Misch wrote:
>> On Wed, Mar 30, 2011 at 04:48:26PM -0400, Robert Haas wrote:
>>> Me neither. If making the deadlock timeout PGC_SUSET is independently
>>> useful, I don't object to doing that first, and then we can wait and
>>> see if anyone fee
(2011/06/12 6:43), Noah Misch wrote:
> On Wed, Mar 30, 2011 at 04:48:26PM -0400, Robert Haas wrote:
>> Me neither. If making the deadlock timeout PGC_SUSET is independently
>> useful, I don't object to doing that first, and then we can wait and
>> see if anyone feels motivated to do more.
>
> Her
On Wed, Mar 30, 2011 at 04:48:26PM -0400, Robert Haas wrote:
> On Tue, Mar 29, 2011 at 2:29 PM, Noah Misch wrote:
> >> It's actually not
> >> clear to me what the user could usefully do other than trying to
> >> preserve his transaction by setting a high deadlock_timeout - what is
> >> the use cas
On Tue, Mar 29, 2011 at 2:29 PM, Noah Misch wrote:
>> It's actually not
>> clear to me what the user could usefully do other than trying to
>> preserve his transaction by setting a high deadlock_timeout - what is
>> the use case, other than that?
>
> The other major use case is reducing latency in
On Tue, Mar 29, 2011 at 08:26:44AM -0400, Robert Haas wrote:
> I'd be inclined to think that PGC_SUSET is plenty.
Agreed. A superuser who would have liked PGC_USERSET can always provide a
SECURITY DEFINER function.
> It's actually not
> clear to me what the user could usefully do other than tryi
Excerpts from Greg Stark's message of mar mar 29 11:15:50 -0300 2011:
> Alternatively we could have the deadlock timer reset all the time and
> fire repeatedly. Then we could just have all backends ignore the
> deadlock if they're not the lowest priority session in the cycle. But
> this depends on
On Tue, Mar 29, 2011 at 2:20 PM, Tom Lane wrote:
> IIRC, the
> current deadlock detector always kills the process that detected the
> deadlock, but I *think* that's just a random choice and not an essential
> feature. If so, it'd be pretty easy to instead kill the lowest-priority
> xact among th
Robert Haas writes:
> On Tue, Mar 29, 2011 at 1:38 AM, Noah Misch wrote:
>> What is notable/surprising about the behavior when two backends have
>> different
>> values for deadlock_timeout?
> I'd be inclined to think that PGC_SUSET is plenty. It's actually not
> clear to me what the user could
On Tue, Mar 29, 2011 at 1:26 PM, Robert Haas wrote:
> Is it worth thinking about having an explicit setting for deadlock
> priority? That'd be more work, of course, and I'm not sure it it's
> worth it, but it'd also provide stronger guarantees than you can get
> with this proposal.
Priority mak
On Tue, Mar 29, 2011 at 1:38 AM, Noah Misch wrote:
> A few years ago, this list had a brief conversation on $SUBJECT:
> http://archives.postgresql.org/message-id/1215443493.4051.600.ca...@ebony.site
>
> What is notable/surprising about the behavior when two backends have different
> values for dea
A few years ago, this list had a brief conversation on $SUBJECT:
http://archives.postgresql.org/message-id/1215443493.4051.600.ca...@ebony.site
What is notable/surprising about the behavior when two backends have different
values for deadlock_timeout? After sleeping to acquire a lock, each backen
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Why is deadlock_timeout set at SIGHUP?
>
> Because it's not clear what the behavior would be like if different
> backends had different settings ... except that it'd probably be
> surprising.
I have added a code comment explaining this
On Mon, 2008-07-07 at 11:16 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Why is deadlock_timeout set at SIGHUP?
>
> Because it's not clear what the behavior would be like if different
> backends had different settings ... except that it'd probably be
> surprising.
Yeh, ag
Simon Riggs <[EMAIL PROTECTED]> writes:
> Why is deadlock_timeout set at SIGHUP?
Because it's not clear what the behavior would be like if different
backends had different settings ... except that it'd probably be
surprising.
regards, tom lane
--
Sent via pgsql-hackers m
Why is deadlock_timeout set at SIGHUP?
If it effects statement behaviour it ought to be a USERSET. Using CPU
time isn't a problem we protect against anywhere else.
I'd like to be able to set deadlock-prone transactions lower, yet keep a
fairly high setting for others.
--
Simon Riggs
15 matches
Mail list logo
