Re: Crash on promotion when recovery.conf is renamed - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Crash on promotion when recovery.conf is renamed
Date
Msg-id CAB7nPqT1+5wcjqH4gPhJ+a9uz+neVFaYCW1dywrpPTOEbv98kw@mail.gmail.com
Whole thread Raw
In response to Re: Crash on promotion when recovery.conf is renamed  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses Re: Crash on promotion when recovery.conf is renamed  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
On Tue, Mar 28, 2017 at 1:33 PM, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> I get the impression that DATA_CORRUPTED means the table data is corrupted, because there's an error code named
INDEX_CORRUPTED.

I have interpreted that as the other way around, aka DATA_CORRUPTED
could be used as well to 2PC files :)
But grepping around it seems that you are grabbing the meaning better
than I do, ERRCODE_DATA_CORRUPTED is only used now for relation pages
or large pages.

>  Anyway, I don't think this patch needs to attach an error code because:
> * Currently, other interlal files (not tables or indexes) seem to use INTERNAL_ERROR (XX000).  For example, see
ReadControlFile()in xlog.c and pgstat_read_statsfiles() in pgstat.c. 
> * It doesn't seem that the user needs distinction.  I don't object to providing a specific error code for this case,
butif the patch needs a specific error code to be committed, I'd like to know how that's useful (e.g. how it affects
therecovery action the user takes.) 
> So, I'd like to mark the patch as ready for committer when ereport() and errmsg() are on separate lines and the
messagechanges to "two-phase state file." 

Okay. I got the message, and I agree with what you say here. You are
right by the way, the error messages just use "two-phase file" and not
"two-phase STATE file", missed that previously.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Nikhil Sontakke
Date:
Subject: Re: Speedup twophase transactions
Next
From: Mithun Cy
Date:
Subject: Re: [POC] A better way to expand hash indexes.