From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: document and use SPI_result_code_string() |
Date: | 2017-10-05 02:16:02 |
Message-ID: | 3245d1ce-3852-9871-b3cd-2fff883d91fc@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/2/17 03:28, Daniel Gustafsson wrote:
>> On 06 Sep 2017, at 14:25, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>>> Fine for 0002. This reminds me of LockGXact and RemoveGXact in
>>> twophase.c, as well as _hash_squeezebucket that have some code paths
>>> that cannot return... Any thoughts about having some kind of
>>> PG_NOTREACHED defined to 0 which could be put in an assertion?
>>
>> Generally we just do "Assert(false)", maybe with "not reached" in a
>> comment. I don't feel a strong need to invent a new way to do that.
>
> Moving this to the next commitfest and bumping status to Ready for committer
> based on the discussion in this thread.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-10-05 02:17:09 | Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple |
Previous Message | Masahiko Sawada | 2017-10-05 01:50:19 | Re: Block level parallel vacuum WIP |