From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reversed sync check in pg_receivewal |
Date: | 2017-04-11 16:51:29 |
Message-ID: | 16119.1491929489@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)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 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2017-04-11 17:05:21 | logical rep worker for table sync can start and stop very frequently unexpectedly |
Previous Message | Dmitry Ivanov | 2017-04-11 16:36:11 | Possible problem in Custom Scan API |