From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Error code for "terminating connection due to conflict with recovery" |
Date: | 2011-01-14 16:48:16 |
Message-ID: | AANLkTiky+Dsur2MQKXcov3wus+DUj0uP+BTEYd1niGfO@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 14, 2011 at 10:53 AM, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>> Review:
>>
>> The only possible point of concern I see here is the naming of the C
>> identifier. Everything else in class 40 uses ERRCODE_T_R_whatever,
>> with T_R standing for transaction rollback. It's not obvious to me
>> that that convention has any real value, but perhaps we ought to
>> follow it here for the sake of consistency?
>
> Yeah. Actually at first I used "T_R" convention. After a few seconds
> thought, I realized that "T_R" is not appropreate by the same reason
> you feel. Possible other argument might be "Terminating connection
> always involves transaction rollback. So using T_R is ok". I'm not
> sure this argument is reasonable enough though.
Looking at this a bit more carefully, I notice that there are two
cases when a recovery conflict occurs:
- we cancel the currently running statement, or
- we kill the whole connection
Should those use the same error code, or different ones? This patch
doesn't appear to update all the places where recovery conflicts can
occur, which is probably not ideal.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2011-01-14 16:48:40 | Re: Add support for logging the current role |
Previous Message | Robert Haas | 2011-01-14 16:45:08 | Re: kill -KILL: What happens? |