Re: A bad behavior under autocommit off mode

From: Barry Lind <blind(at)xythos(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, 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 23:47:47
Message-ID: 3E7BA4A3.6080107@xythos.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Barry Lind <blind(at)xythos(dot)com> writes:
>
>>In the previous email I discusses why autocommit perhaps shouldn't be a
>>GUC parameter. From a jdbc perspective what was said in that email
>>generally applies to client_encoding and datestyle as well.
>
>
> Hmm. I'm not sure that it makes sense for clients to want to change
> client_encoding on the fly, but it's harder to make that claim for
> datestyle. And datestyle has been a SET variable for so long that we
> would get a *lot* of compatibility flak if we took it away.
>

The issues I was raising are more theoretical than practical. The only
reason I was raising them, is that while we are looking at changes to
the FE/BE protocol we should look at all the issues. Good general
purpose mechanisms (like what Tom is suggesting below) can be created
when a better understanding of all the issues is known.

--Barry

> I had originally been thinking of reporting client_encoding as a field
> of some message sent only at backend startup. However, what if we send
> such a message whenever one of the variables it includes changes?
> (This is basically Bruce's idea from last night, but refined to only
> send the data when it changes, rather than on every query; that should
> eliminate the bandwidth-wastage objection.)
>
> I'm not convinced that it's worth the trouble to make the set of
> reported variables be configurable on-the-fly as Bruce was suggesting.
> client_encoding and datestyle are candidates to send this way, but are
> there really others?
>
> A point that would have to be considered is what to do when a SET
> operation is rolled back by transaction abort. I think what we'd need
> to do is retransmit each time the effective value changes; so it'd
> work like this:
>
> -- initial DateStyle is foo
> BEGIN;
> SET DateStyle TO bar;
> -- backend sends status message showing DateStyle = bar
> SELECT ...
> -- reported dates will use DateStyle bar
> ROLLBACK;
> -- backend sends status message showing DateStyle = foo
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Pflug 2003-03-22 00:14:30 conversion problems with domains
Previous Message Josh Berkus 2003-03-21 23:32:11 to_char(interval) --- done?