|From:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Crash on promotion when recovery.conf is renamed|
|Views:||Raw Message | Whole Thread | Download mbox|
On Mon, Mar 27, 2017 at 11:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
>> On Mon, Mar 27, 2017 at 4:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Actually, the *real* problem with that coding is it lacks a SQLSTATE
>>> (errcode call). The only places where it's acceptable to leave that
>>> out are for internal "can't happen" cases, which this surely isn't.
>> Surrounding code also has ereports lacking SQLSTATE. And that isn't "can't
>> happen" case as well.
>> Should we consider fixing them?
> Yup. Just remember that the default is
> XX000 E ERRCODE_INTERNAL_ERROR internal_error
> If that's not how you want the error case reported, you need an errcode()
> We might need more ERRCODEs than are there now, if none of the existing
> ones seem to fit these cases. There's already ERRCODE_DATA_CORRUPTED
> and ERRCODE_INDEX_CORRUPTED; maybe we need ERRCODE_WAL_CORRUPTED, for
While I agree with that in general, we are taking about 2PC files that
are on disk in patch 0001, so I would think that in this case
ERRCODE_DATA_CORRUPTED is the most adapted (or
The other WARNING messages refer to stale files of already committed
transactions, which are not actually corrupted. What about in this
case having a ERRCODE_TWOPHASE_INVALID?
Updated patches are attached, I did not change the WARNING portion
though as I am not sure what's the consensus on the matter.
|Next Message||Craig Ringer||2017-03-28 02:53:55||Re: logical decoding of two-phase transactions|
|Previous Message||Robert Haas||2017-03-28 02:52:02||Re: O(1) DSM handle operations|