Re: I am done - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: I am done
Date
Msg-id 200209021646.g82GkAR22754@candle.pha.pa.us
Whole thread Raw
In response to Re: I am done  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: I am done  (Gavin Sherry <swm@linuxworld.com.au>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> I don't think it *can* be fixed in a reasonable fashion until we have
> >> notification to the client side about what the backend's transaction
> >> state is; which is one of the protocol-change items for 7.4.
> 
> > Why can't we just turn on auto-commit when we start the session:
> >     SET autocommit = true;
> 
> How's that help?  If the user turns it off again, we still break.
> 
> More to the point, we can hardly claim any level of SQL compliance if
> either libpq or psql try to prevent you from using the autocommit-off
> mode ... but both contain problematic code (mostly in the startup and
> large-object-support areas).
> 
> The real problem here is that the client code cannot know how to behave
> (ie, whether to issue BEGIN and/or COMMIT) unless it knows the current
> autocommit setting and current transaction state.  And getting that info
> in any reliable fashion requires a protocol change, AFAICS.
> 
> There are some things we can tweak to make the clients less broken than
> they are now --- for instance, all of libpq's startup-time SET commands
> could be switched to "BEGIN; SET ...; COMMIT;" which will work the same
> with or without autocommit --- but I don't think we can expect to fix
> large-object support, for example, without the protocol change.

I was considering the original report that createlang doesn't work. 
Surely we can do some things to fix those at least.  Yes, we clearly
aren't going to get this working 100% in 7.3.  I don't even know what to
put on the TODO list because we don't know what cases have problems.

> >> Oh, didn't you put in that patch to provide a GUC level control?
> 
> > Yes, but what level do you set it at to turn it off?
> 
> FATAL?  PANIC?

He doesn't support those levels:test=> set log_min_error_statement = fatal;ERROR:  invalid value for option
'log_min_error_statement':'fatal'test=> set log_min_error_statement = error;SET
 

and in fact, the default is ERROR. I think the default has to be
something higher, but even FATAL seems wrong.  We have to be able to
turn it off, and have it off by default, rather than saying it only
happens with fatal errors or something like that.

--  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 by date:

Previous
From: Rod Taylor
Date:
Subject: Re: I am done
Next
From: Peter Eisentraut
Date:
Subject: Re: [COMMITTERS] pgsql-server/src/include/port hpux.h