Re: ERROR during end-of-xact/FATAL
От | Alvaro Herrera |
---|---|
Тема | Re: ERROR during end-of-xact/FATAL |
Дата | |
Msg-id | 20131128151018.GF5513@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: ERROR during end-of-xact/FATAL (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: ERROR during end-of-xact/FATAL
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: