Re: initdb SegFault

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

In response to

Responses

Browse pgsql-bugs by date

  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

Browse pgsql-hackers by date

  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