| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Boszormenyi Zoltan <zb(at)cybertec(dot)at>, 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 16:08:30 |
| Message-ID: | 8675.1264090110@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Jan 21, 2010 at 10:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Why is this a good idea at all? I can easily see somebody feeling that
>> he'd like autovacuums to fail rather than block on locks for a long
>> time, for example.
> What I can see happening is someone setting this GUC in
> postgresql.conf and then being surprised that it applied to thinks
> like walreceiver and autovacuum, in addition to user queries. Are we
> even sure that that code would all behave sanely with this behavior?
No, I'm not sure, as I said before ;-). But a 100%-arbitrary
restriction like "it doesn't apply to background processes" will not
make it noticeably safer. There is very damn little code that only
executes in background and never anywhere else.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Boszormenyi Zoltan | 2010-01-21 16:09:35 | Re: lock_timeout GUC patch |
| Previous Message | Tom Lane | 2010-01-21 16:03:55 | Re: About "Our CLUSTER implementation is pessimal" patch |