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

From Tsunakawa, Takayuki
Subject Re: Crash on promotion when recovery.conf is renamed
Date
Msg-id 0A3221C70F24FB45833433255569204D1F6BC507@G01JPEXMBYT05
Whole thread Raw
In response to Re: Crash on promotion when recovery.conf is renamed  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Crash on promotion when recovery.conf is renamed  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Michael Paquier
> 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
> ERRCODE_TWOPHASE_CORRUPTED?).
> 
> 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.
> 

I get the impression that DATA_CORRUPTED means the table data is corrupted, because there's an error code named
INDEX_CORRUPTED. 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 message
changesto "two-phase state file."
 

Regards
Takayuki Tsunakawa





pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: crashes due to setting max_parallel_workers=0
Next
From: Haribabu Kommi
Date:
Subject: Re: pg_stat_wal_write statistics view