From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Memory context in exception handler |
Date: | 2007-01-14 00:14:52 |
Message-ID: | 28302.1168733692@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> But this fails because CopyErrorData() complains by way of assertion
> that we're still in ErrorContext. A nearby comment suggests to switch
> away to another context to preserve the data across FlushErrorState(),
> but that doesn't seem necessary in this situation. Are there other
> reasons why this rule is so rigorously enforced?
I think it's a good error check because if you are trying to make a copy
of the current error data, doing so within the ErrorContext seems highly
unlikely to be safe.
As near as I can tell, you're using CopyErrorData not because you need
an actual copy but just because elog.c doesn't export any other API to
let you see the current sqlerrorcode. Perhaps adding a function to
return the top stack entry's sqlerrorcode would be a better API change?
(I'm a bit uncomfortable with handing out direct access to the struct,
but getting a peek at sqlerrorcode or other scalar values seems safe
enough.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-01-14 00:24:28 | Re: Performance of Parser? |
Previous Message | elein | 2007-01-14 00:05:43 | Re: [HACKERS] Autovacuum Improvements |