Re: [HACKERS] Reversed sync check in pg_receivewal
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Reversed sync check in pg_receivewal |
Дата | |
Msg-id | 16119.1491929489@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Reversed sync check in pg_receivewal (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: [HACKERS] Reversed sync check in pg_receivewal
|
Список | pgsql-hackers |
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 * All methods that have a failure return indicator will set state* allowing the getlasterror() method to return a suitablemessage.* Commonly, errno is this state (or part of it); so callers must take* care not to clobber errno betweena failed method call and use of* getlasterror() to retrieve the message. Also: * the arguments of open_for_write() could stand to be explained * what's the return value of finish()? * wouldn't it be better to declare getlasterror() as returning "const char *"? regards, tom lane
В списке pgsql-hackers по дате отправления: