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 по дате отправления:

Предыдущее
От: Dmitry Ivanov
Дата:
Сообщение: [HACKERS] Possible problem in Custom Scan API
Следующее
От: Fujii Masao
Дата:
Сообщение: [HACKERS] logical rep worker for table sync can start and stop very frequently unexpectedly