Re: lock_timeout GUC patch

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

On Tue, Jan 19, 2010 at 6:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> A larger question, which I think has been raised before but I have not
> seen a satisfactory answer for, is whether the system will behave sanely
> at all with this type of patch in place.  I don't really think that a
> single lock timeout applicable to every possible reason to wait is going
> to be nice to use; and I'm afraid in some contexts it could render
> things completely nonfunctional.  (In particular I think that Hot
> Standby is fragile enough already without this.)  It seems particularly
> imprudent to make such a thing USERSET, implying that any clueless or
> malicious user could set it in a way that would cause problems, if there
> are any to cause.

The obvious alternative is to have specific syntax to allow for waits
on specific types of statements; however, based on the previous round
of conversation, I thought we had concluded that the present design
was the least of evils.

http://archives.postgresql.org/pgsql-hackers/2009-09/msg01730.php

I am not too sure what you think this might break?

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Christensen 2010-01-20 00:01:29 Patch rev 2: MySQL-ism help patch for psql
Previous Message Jeff Davis 2010-01-19 23:41:29 Re: Listen / Notify - what to do when the queue is full