Re: [HACKERS] Reversed sync check in pg_receivewal
От | Magnus Hagander |
---|---|
Тема | Re: [HACKERS] Reversed sync check in pg_receivewal |
Дата | |
Msg-id | CABUevEwbXHM8wPmJAkvXogL7Vroym7EM_VAYpcHvrue0eEU6VQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Reversed sync check in pg_receivewal (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: