On 2015-01-26 10:52:07 -0500, Robert Haas wrote:
> On Sun, Jan 25, 2015 at 2:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > This is scary as hell. I intend to go around and manually audit
> > every single PG_TRY in the current source code, but that is obviously
> > not a long-term solution. Anybody have an idea about how we might
> > get trustworthy mechanical detection of this type of situation?
>
> One idea I've been thinking about for a while is to create some new,
> safer notation. Suppose we did this:
>
> PG_TRY_WITH_CLEANUP(cleanup_function, cleanup_argument);
> {
> /* code requiring cleanup */
> }
> PG_END_TRY_WITH_CLEANUP();
That's pretty similar to to PG_ENSURE_ERROR_CLEANUP, except that that is
also called after FATAL errors. If we do this, we probably should try to
come up with a easier to understand naming scheme. PG_TRY_WITH_CLEANUP
vs. PG_ENSURE_ERROR_CLEANUP isn't very clear to a reader.
> Instead of doing anything with sigsetjmp(), this would just push a
> frame onto a cleanup stack. We would call of those callbacks from
> innermost to outermost before doing siglongjmp(). With this design,
> we don't need any volatile-ization.
On the other hand most of the callsites will need some extra state
somewhere to keep track of what to undo. That's a bit of restructuring
work too. And if the cleanup function needs to reference anything done
in the TRY block, that state will need to be volatile too.
> Aside from any reduction in the need
> for volatile, this might actually perform slightly better, because
> sigsetjmp() is a system call on some platforms. There are probably
> few cases where that actually matters, but the one in pq_getmessage(),
> for example, might not be entirely discountable.
Hm. How would you implement PG_TRY_WITH_CLEANUP without a sigsetjmp()?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
