| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: deadlock_timeout at < PGC_SIGHUP? |
| Date: | 2011-03-29 13:20:38 |
| Message-ID: | 12687.1301404838@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Mar 29, 2011 at 1:38 AM, Noah Misch <noah(at)leadboat(dot)com> 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 usefully do other than trying to
> preserve his transaction by setting a high deadlock_timeout - what is
> the use case, other than that?
Yeah, that was my reaction too: what is the use case for letting
different backends have different settings? It fails to give any real
guarantees about who wins a deadlock, and I can't see any other reason
for wanting session-specific settings.
I don't know how difficult a priority setting would be. 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 those involved in the deadlock.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-03-29 13:24:49 | Re: Replication server timeout patch |
| Previous Message | Simon Riggs | 2011-03-29 12:58:24 | Re: deadlock_timeout at < PGC_SIGHUP? |