On Fri, Nov 15, 2013 at 09:51:32AM -0500, Robert Haas wrote:
> On Wed, Nov 13, 2013 at 11:04 AM, Noah Misch wrote:
> >> So, in short, ERROR + ERROR*10 = PANIC, but FATAL + ERROR*10 = FATAL.
> >> That's bizarre.
> >
> > Quite so.
> >
> >> Given that that's where we are, promoting an ERROR during FA
Robert Haas escribió:
> On Thu, Nov 28, 2013 at 10:10 AM, Alvaro Herrera
> wrote:
> > Robert Haas escribió:
> >> On Wed, Nov 6, 2013 at 9:40 AM, Alvaro Herrera
> >> wrote:
> >> > Noah Misch wrote:
> >> >> Incomplete list:
> >> >>
> >> >> - If smgrDoPendingDeletes() finds files to delete, mdunlin
On Thu, Nov 28, 2013 at 10:10 AM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Wed, Nov 6, 2013 at 9:40 AM, Alvaro Herrera
>> wrote:
>> > Noah Misch wrote:
>> >> Incomplete list:
>> >>
>> >> - If smgrDoPendingDeletes() finds files to delete, mdunlink() and its
>> >> callee
>> >> relpat
Robert Haas escribió:
> On Wed, Nov 6, 2013 at 9:40 AM, Alvaro Herrera
> 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.
On Wed, Nov 13, 2013 at 11:04 AM, Noah Misch wrote:
>> So, in short, ERROR + ERROR*10 = PANIC, but FATAL + ERROR*10 = FATAL.
>> That's bizarre.
>
> Quite so.
>
>> Given that that's where we are, promoting an ERROR during FATAL
>> processing to PANIC doesn't seem like it's losing much; we're
>> ess
On Tue, Nov 12, 2013 at 09:55:34AM -0500, Robert Haas wrote:
> On Fri, Nov 8, 2013 at 4:13 PM, Noah Misch wrote:
> > A PANIC will reinitialize everything relevant, largely resolving the
> > problems
> > around ERROR during FATAL. It's a heavy-handed solution, but it may well be
> > the best solu
On Fri, Nov 8, 2013 at 4:13 PM, Noah Misch wrote:
> A PANIC will reinitialize everything relevant, largely resolving the problems
> around ERROR during FATAL. It's a heavy-handed solution, but it may well be
> the best solution. Efforts to harden CommitTransaction() and
> AbortTransaction() seem
On Sat, Nov 9, 2013 at 2:43 AM, Noah Misch wrote:
> On Wed, Nov 06, 2013 at 10:14:53AM +0530, Amit Kapila wrote:
>> On Thu, Oct 31, 2013 at 8:22 PM, Noah Misch wrote:
>> About unclean FATAL-then-ERROR scenario, one way to deal at high level
>> could be to treat such a case as backend crash in whi
On Wed, Nov 06, 2013 at 10:14:53AM +0530, Amit Kapila wrote:
> On Thu, Oct 31, 2013 at 8:22 PM, Noah Misch wrote:
> > If the original AbortTransaction() pertained to a FATAL, the situation is
> > worse. errfinish() promotes the ERROR thrown from AbortTransaction() to
> > another FATAL,
>
> isn't
On Wed, Nov 6, 2013 at 9:40 AM, Alvaro Herrera 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, smgrDo
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 doe
On Thu, Oct 31, 2013 at 8:22 PM, Noah Misch wrote:
> CommitTransaction() and AbortTransaction() both do much work, and large
> portions of that work either should not or must not throw errors. An error
> during either function will, as usual, siglongjmp() out. Ordinarily,
> PostgresMain() will r
CommitTransaction() and AbortTransaction() both do much work, and large
portions of that work either should not or must not throw errors. An error
during either function will, as usual, siglongjmp() out. Ordinarily,
PostgresMain() will regain control and fire off a fresh AbortTransaction().
The c
13 matches
Mail list logo