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
|
Список | 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 по дате отправления: