Re: [HACKERS] Reversed sync check in pg_receivewal - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [HACKERS] Reversed sync check in pg_receivewal
Date
Msg-id CABUevEwbXHM8wPmJAkvXogL7Vroym7EM_VAYpcHvrue0eEU6VQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Reversed sync check in pg_receivewal  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


On Tue, Apr 11, 2017 at 6:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
> Something like the attached?

Not sure about

+ * All methods that have a failure path will set errno on failure.

Given that you've got a getlasterror method, I don't think that's really
the API invariant is it?  If it were, you'd just have the callers doing
strerror(errno) for themselves.  I think maybe a more accurate statement
would be

Hmm. You're right, this is what I get for rushing a patch before plane departure :/
 
 * All methods that have a failure return indicator will set state
 * allowing the getlasterror() method to return a suitable message.
 * Commonly, errno is this state (or part of it); so callers must take
 * care not to clobber errno between a failed method call and use of
 * getlasterror() to retrieve the message.


Yeah, that's much better.

 
Also:

* the arguments of open_for_write() could stand to be explained

* what's the return value of finish()?

Both fixed.
 

* wouldn't it be better to declare getlasterror() as returning
  "const char *"?

Yeah, probably is. Will do and push.

Thanks!
 
--

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [pgsql-www] [HACKERS] Small issue in online devel documentation build
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] index-only count(*) for indexes supporting bitmap scans