| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: parallel mode and parallel contexts |
| Date: | 2015-03-24 21:22:11 |
| Message-ID: | 8027.1427232131@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> Also: Man, trying to understand the guts of deadlock.c only made me
> understand how *friggin* expensive deadlock checking is. I'm really
> rather surprised that it only infrequently causes problems.
The reason for that is that we only run deadlock checking if something's
been waiting for at least one second, which pretty much takes it out
of any performance-relevant code pathway. I think it would be a serious
error to put any deadlock-checking-like behavior into mainline code.
Which probably means that Andres is right that teaching deadlock.c
about any new sources of deadlock is the way to approach this.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2015-03-24 21:22:29 | Re: Replication identifiers, take 4 |
| Previous Message | Baker, Keith [OCDUS Non-J&J] | 2015-03-24 21:18:54 | Re: Zero-padding and zero-masking fixes for to_char(float) |