Re: A bad behavior under autocommit off mode

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Barry Lind <blind(at)xythos(dot)com>, Neil Conway <neilc(at)samurai(dot)com>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A bad behavior under autocommit off mode
Date: 2003-03-21 15:13:54
Message-ID: 200303211513.h2LFDtM26526@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom, did you have any thought of adding the ability to ask for reports
> > on GUC variables on every query return?
>
> That seems excessive. There is a case for reporting autocommit (if
> we don't decide to remove it altogether, which is still an open
> argument). I have not heard any complaints suggesting that we need any
> others.

Well, the jdbc guys like SET, and I haven't seen any proposal that
explains how applications would control a client-based autocommit API
from the client.

> A fixed commitment to report xact status will cost us one byte added to
> Z messages. If we add a commitment to report autocommit status, we
> could choose to pack that bit into the same byte as xact status (still
> only three bits used...). A slightly more forward-looking approach
> would be to decree that Z messages carry labeled status bytes, ie, pairs
> of <label> <status> bytes, which makes total cost 4 bytes to transmit
> xact state and autocommit state. But if we want to say that we'll
> transmit *any* darn random GUC variable you want to hear about, I don't
> think we can use a compact encoding of this sort; instead we're talking
> about sending the whole GUC variable name and string value as label and
> value. In other words the Z message starts to look like
> Z X a c t s t a t u s \0 i d l e \0 a u t o c o m m i t \0 o f f \0
> and somewhere around here my concern for connection bandwidth kicks in.
> A 10X increase in bytes sent is a bit much to cater to hypothetical
> needs.

Very true. The only other environment variable I have heard about was
client encoding. As I remember right now, we do have a problem with SET
changing the client encoding, and the client not realizing that.

My idea may be overdesign.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-03-21 15:18:16 Re: Nested transactions: low level stuff
Previous Message Michael Meskes 2003-03-21 15:04:51 Re: [BUGS] Bug #904: Deallocating of prepared statement in ECPG at