On Tue, 17 Jan 2017 23:00:43 +0100
Gilles Darold <gilles.dar...@dalibo.com> wrote:

> Le 17/01/2017 à 19:58, Karl O. Pinc a écrit :
> > On Tue, 17 Jan 2017 19:06:22 +0100
> > Gilles Darold <gilles.dar...@dalibo.com> wrote:
> >  
> >> Le 17/01/2017 à 03:22, Michael Paquier a écrit :  
> >>> On Tue, Jan 17, 2017 at 2:21 AM, Karl O. Pinc <k...@meme.com>
> >>> wrote:    
> >>>> On January 15, 2017 11:47:51 PM CST, Michael Paquier
> >>>> <michael.paqu...@gmail.com> wrote:    
> >  
> >>>>> Also, I would rather see an ERROR returned to the user in case
> >>>>> of bad data in current_logfiles, I did not change that either as
> >>>>> that's the original intention of Gilles.    
> >> I'm not against adding a warning or error message here even if it
> >> may never occurs, but we need a new error code as it seems to me
> >> that no actual error code can be used.    
> > Seems to me the XX001 "data_corrupted" sub-category of
> > XX000 "internal_error" is appropriate.  
> I don't think so, this file doesn't contain any data and we must not
> report such error in this case. Somethink like "bad/unknow file
> format" would be better.

Maybe.  It's not user-supplied data that's corrupted but it is
PG generated data which is generated for and supplied to the user.
I just looked at all uses of XX001 and it is true that they all
involve corruption of user-supplied data.

If you don't want to use XX001 use XX000.  It does not seem worth
making a new error code for just this one case.


Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to