Re: Hard limit on WAL space used (because PANIC sucks)
От | Joshua D. Drake |
---|---|
Тема | Re: Hard limit on WAL space used (because PANIC sucks) |
Дата | |
Msg-id | 51B39390.3040000@commandprompt.com обсуждение исходный текст |
Ответ на | Re: Hard limit on WAL space used (because PANIC sucks) (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Hard limit on WAL space used (because PANIC sucks)
Re: Hard limit on WAL space used (because PANIC sucks) |
Список | pgsql-hackers |
On 06/08/2013 11:27 AM, Andres Freund wrote: > > On 2013-06-08 11:15:40 -0700, Joshua D. Drake wrote: >> To me, a more pragmatic approach makes sense. Obviously having some kind of >> code that checks the space makes sense but I don't know that it needs to be >> around any operation other than we are creating a segment. What do we care >> why the segment is being created? If we don't have enough room to create the >> segment, the transaction rollsback with some OBVIOUS not OBTUSE error. >> >> Obviously this could cause a ton of transactions to roll back but I think >> keeping the database consistent and rolling back a transaction in case of >> error is exactly what we are supposed to do. > > You know, the PANIC isn't there just because we like to piss of > users. There's actual technical reasons that don't just go away by > judging the PANIC as stupid. Yes I know we aren't trying to piss off users. What I am saying is that it is stupid to the user that it PANICS. I apologize if that came out wrong. > At the points where the XLogInsert()s happens we're in critical sections > out of which we *cannot* ERROR out because we already may have made > modifications that cannot be allowed to be performed > partially/unlogged. That's why we're throwing a PANIC which will force a > cluster wide restart including *NOT* writing any further buffers from > s_b out. > Does this preclude (sorry I don't know this part of the code very well) my suggestion of on log create? JD > Greetings, > > Andres Freund >
В списке pgsql-hackers по дате отправления: