| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | pgsql-committers(at)postgresql(dot)org |
| Subject: | pgsql: pg_receivexlog - Exit on failure to parse |
| Date: | 2013-07-14 19:39:22 |
| Message-ID: | E1UyS8g-0006tu-Px@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
pg_receivexlog - Exit on failure to parse
In streamutil.c:GetConnection(), upgrade failure to parse the
connection string to an exit(1) instead of simply returning NULL.
Most callers already immediately exited, but pg_receivexlog would
loop on this case, continually trying to re-parse the connection
string (which can't be changed after pg_receivexlog has started).
GetConnection() was already expected to exit(1) in some cases
(eg: failure to allocate memory or if unable to determine the
integer_datetimes flag), so this change shouldn't surprise anyone.
Began looking at this due to the Coverity scanner complaining that
we were leaking err_msg in this case- no longer an issue since we
just exit(1) immediately.
Branch
------
REL9_3_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/f5acde9380e164eab10b2dc3281bb1c07f690803
Modified Files
--------------
src/bin/pg_basebackup/streamutil.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2013-07-14 20:11:40 | pgsql: pg_isready: Message improvement |
| Previous Message | Stephen Frost | 2013-07-14 19:39:10 | pgsql: pg_receivexlog - Exit on failure to parse |