| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Excessive CPU usage in StandbyReleaseLocks() |
| Date: | 2018-06-19 17:44:58 |
| Message-ID: | 30018.1529430298@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-06-19 13:05:48 -0400, Robert Haas wrote:
>> I don't expect you to agree with my vote, but I stand by it.
> Yea, I didn't expect (but hoped!) to change your mind... ;)
FWIW, I agree with Robert --- a PANIC here will certainly create
problems, and it's much less clear what problems it might prevent.
However, the trouble with LOG is that we would be unlikely to
notice such a message in testing, so that a test case triggering
an issue of this type would not get recognized as such.
Hence, I have a modest proposal: use elog(LOG) followed by Assert(false),
so that debug builds report such problems loudly but production builds
do not. We've done that before, see e.g. load_relcache_init_file around
relcache.c:5718.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2018-06-19 17:53:45 | Re: MERGE SQL statement for PG12 |
| Previous Message | Peter Geoghegan | 2018-06-19 17:43:10 | Re: Making all nbtree entries unique by having heap TIDs participate in comparisons |