Re: [subxact] Proof-of-concept: report nest level to client

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [subxact] Proof-of-concept: report nest level to client
Date: 2004-07-16 14:10:58
Message-ID: 20487.1089987058@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> Patch attached (surprinsingly small), though it only applies with the
> savepoint patch applied(*). If any driver writer wants to play, however,
> it's easy to see what's going on -- a ParameterStatus message will be
> received from the backend whenever the nesting level changes.

This is really quite the wrong behavior --- think about a function that
executes thousands of subtransactions before returning. You really do
not want to emit a message for every nestlevel change. (That's one of
the reasons I rejected doing this as a regular GUC variable.)

We could possibly send the info as a fake ParameterStatus that's only
sent just before the Z message, ie only when the backend is about to
wait for a command.

Right at the moment though I'm suspending judgment on whether we should
bite the bullet and do a protocol version change to support nested
xacts. Off the top of my head we have a couple of reasons to want one:
- need for xact nest level or something like it in Z message
- need for option to make protocol-created portals act like WITH HOLD cursors
and IIRC we have identified some other minor misfeatures in the 7.4
protocol design as well, though I'd have to dig through the archives
to remember the details. If we find any more I'll start to think that
we should just do it ...

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Fabien COELHO 2004-07-16 14:34:36 pgxs: build infrastructure for extensions v4
Previous Message Bruce Momjian 2004-07-16 13:53:08 Re: serverlog rotation/functions