Re: A bad behavior under autocommit off mode
От | Bruce Momjian |
---|---|
Тема | Re: A bad behavior under autocommit off mode |
Дата | |
Msg-id | 200303211513.h2LFDtM26526@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: A bad behavior under autocommit off mode (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: A bad behavior under autocommit off mode
Re: A bad behavior under autocommit off mode |
Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: