From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | vignesh C <vignesh21(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: initdb SegFault |
Date: | 2019-11-19 17:06:50 |
Message-ID: | 19334.1574183210@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> Agreed wrt this specific failure scenario. It does however seem not
> great that callsites for PQExpBuffer ought to check every call for
> allocation failures, in the general case.
It is possible to check just once at the end, using the PQExpBufferBroken
API, and I believe that libpq for instance is fairly careful about that.
I agree that programs that just need to print something and exit could
perhaps ask pqexpbuffer.c to handle that for them. (But initdb still
doesn't fall in that category, because of its very nontrivial atexit
handler :-(.)
> I wonder if, for frontend paths, a simplified error handling path would
> be worthwhile for OOM paths. Doing only a write() or such to print an
> error message.
Perhaps. You wouldn't get any translation --- but then, gettext is
probably going to fail anyway under such conditions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-11-19 17:47:31 | Re: BUG #16119: pg_dump omits columns specification for matviews |
Previous Message | Andres Freund | 2019-11-19 16:10:59 | Re: initdb SegFault |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-11-19 18:21:37 | Re: Role membership and DROP |
Previous Message | Andres Freund | 2019-11-19 16:10:59 | Re: initdb SegFault |