Re: ERROR during end-of-xact/FATAL - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: ERROR during end-of-xact/FATAL
Date
Msg-id 20131128151018.GF5513@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: ERROR during end-of-xact/FATAL  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: ERROR during end-of-xact/FATAL  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas escribió:
> On Wed, Nov 6, 2013 at 9:40 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> > Noah Misch wrote:
> >> Incomplete list:
> >>
> >> - If smgrDoPendingDeletes() finds files to delete, mdunlink() and its callee
> >>   relpathbackend() call palloc(); this is true in all supported branches.  In
> >>   9.3, due to commit 279628a0, smgrDoPendingDeletes() itself calls palloc().
> >>   (In fact, it does so even when the pending list is empty -- this is the only
> >>   palloc() during a trivial transaction commit.)  palloc() failure there
> >>   yields a PANIC during commit.
> >
> > I think we should fix this routine to avoid the palloc when not necessary.
> > That initial palloc is pointless.

Here's a trivial patch we could apply to 9.3 immediately.  Anything else
such as the ideas proposed below would require more effort than anyone
can probably spend here soon.


> > Also, there have been previous discussions about having relpathbackend
> > not use palloc at all.  That was only because we wanted to use it in
> > pg_xlogdump which didn't have palloc support at the time, so it's no
> > longer as pressing; but perhaps it's still worthy of consideration.
>
> +1, but I'd like it better if we could find a way of avoiding the
> palloc in all cases.  Panicking because we run out of memory at the
> wrong time isn't really very nice.  Maybe the information needs to be
> maintained in the format in which it ultimately needs to be returned,
> so that we needn't rejigger it in the middle of a critical section.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Another bug introduced by fastpath patch
Next
From: Andres Freund
Date:
Subject: Heads-Up: multixact freezing bug