Re: Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on
Дата
Msg-id 9837222c0907280537g66922cfai955a02437bd6f030@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Jul 27, 2009 at 16:14, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> To fix that we'd just have to turn those functions all into returning
>> boolean and log with LOG instead. AFAIK, we've had zero reports of
>> this actually happening, so I'm not sure it's worth redesigning.
>> Thoughts?
>
> I'm not really insisting on a redesign.  I'm talking about the places
> where the code author appears not to have understood that ERROR means
> FATAL, because the code keeps plugging on after it anyway.  As far as
> I can see, using ERROR at lines 3630, 3657, 3674, and 3693 is just
> plain bogus, and changing to LOG there requires no other fixing.

3630: can't happen, because we already elog(ERROR) deep in the
function, which is what I tried to outline above. That's the one
requiring a redesign - because the errors *inside* the function it
calls can certainly happen.
3657: is one of those "should never happen" issues - which we haven't
had any reports of.
3674: see above
3693 is a comment, I assume you mean 3683, which is also one of those
can't happen.

But. I'll look into cleaning those up for HEAD anyway, but due to lack
of reports I think we should skip backpatch. Reasonable?


-- Magnus HaganderSelf: http://www.hagander.net/Work: http://www.redpill-linpro.com/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Laurent Laborde
Дата:
Сообщение: Re: Higher TOAST compression.
Следующее
От: KaiGai Kohei
Дата:
Сообщение: Re: SE-PostgreSQL Specifications