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:10 |
Message-ID: | E1UyS8U-0006tP-Jc@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | 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
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/d368a301b3a4bf5fec17e81c630adddeac80a7fc
Modified Files
--------------
src/bin/pg_basebackup/streamutil.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2013-07-14 19:39:22 | pgsql: pg_receivexlog - Exit on failure to parse |
Previous Message | Stephen Frost | 2013-07-14 18:40:28 | pgsql: During parallel pg_dump, free commands from master |