| From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
|---|---|
| To: | Neil Conway <neilc(at)samurai(dot)com> |
| Cc: | adnandursun(at)asrinbilisim(dot)com(dot)tr, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Feature freeze date for 8.1 |
| Date: | 2005-05-02 03:58:50 |
| Message-ID: | 4275A57A.9090907@opencloud.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Neil Conway wrote:
> adnandursun(at)asrinbilisim(dot)com(dot)tr wrote:
>
>> statement_timeout is not a solution if many processes are
>> waiting the resource.
>
>
> Why not?
>
> I think the only problem with using statement_timeout for this purpose
> is that the client connection might die during a long-running
> transaction at a point when no statement is currently executing. Tom's
> suggested transaction_timeout would be a reasonable way to fix this.
> Adnan, if you think this is such a significant problem (I can't say that
> I agree), I'd encourage you to submit a patch.
I raised this a while back on -hackers:
http://archives.postgresql.org/pgsql-hackers/2005-02/msg00397.php
but did not get much feedback.
Does anyone have comments on that email?
It's a problem that is unlikely to happen in normal operation, but you
do need to deal with it to cover the network failure cases if you have
an otherwise failure-tolerant cluster..
-O
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jaime Casanova | 2005-05-02 04:08:39 | Re: Feature freeze date for 8.1 |
| Previous Message | Neil Conway | 2005-05-02 02:05:45 | Re: Feature freeze date for 8.1 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jaime Casanova | 2005-05-02 04:08:39 | Re: Feature freeze date for 8.1 |
| Previous Message | Neil Conway | 2005-05-02 02:05:45 | Re: Feature freeze date for 8.1 |