| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, 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-26 22:55:27 |
| Message-ID: | 7231.1048719327@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>>> How about sending an INFO or special taged message to the client when
>>> there is a GUC change, and have report_changes as a GUC variable that
>>> controls it?
>>
>> Having such a variable would break the client libraries that need the
>> information. They won't stop needing the info just because some DBA
>> thinks it's a good idea to save a few bytes of bandwidth ...
> You could configure it so once it is set by the client, only the client
> can change it, meaning it doesn't read from postgresql.conf.
I'm not seeing the point, though. The amount of bandwidth involved is
insignificant, so there's no value in turning it off. AFAICT Peter's
objection to adding this is complexity, not bandwidth --- and adding a
control knob as you suggest will only make it even more complex.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2003-03-26 22:56:57 | Re: A bad behavior under autocommit off mode |
| Previous Message | Bruce Momjian | 2003-03-26 22:45:14 | Re: A bad behavior under autocommit off mode |