Gavin Sherry wrote:
> On Thu, 5 Sep 2002, Tom Lane wrote:
>
> > Gavin Sherry <[EMAIL PROTECTED]> writes:
> > > Since the flawed code is now in beta, it will need to be fixed. Do people
> > > like the above solution or should I just revert to having a seperate
> > > function for each GUC variable
On Thu, 5 Sep 2002, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > Since the flawed code is now in beta, it will need to be fixed. Do people
> > like the above solution or should I just revert to having a seperate
> > function for each GUC variable affected?
>
> I do not see a go
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > of course I don't think a fatal or panic ever makes it
> > to the client side.
>
> Of course it does. Try entering a bad password as a trivial example.
> We punt *after* we send the elog.
Oh, that's good. I guess it was PANIC I as
Bruce Momjian <[EMAIL PROTECTED]> writes:
> of course I don't think a fatal or panic ever makes it
> to the client side.
Of course it does. Try entering a bad password as a trivial example.
We punt *after* we send the elog.
regards, tom lane
---(
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > But the client side doesn't make any sense to support FATAL. Am I
> > missing something?
>
> Hm. I suppose a client setting above ERROR might break some application
> programs that expect either ERROR or a command-complete response
Bruce Momjian <[EMAIL PROTECTED]> writes:
> But the client side doesn't make any sense to support FATAL. Am I
> missing something?
Hm. I suppose a client setting above ERROR might break some application
programs that expect either ERROR or a command-complete response ...
but do we need to go ou
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> I do not see a good reason why "fatal" and "off" shouldn't be allowed
> >> values for all three message variables. If we just did that, then you'd
> >> be back to sharable code.
>
> > I recommended he only allow valid values for ea
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I do not see a good reason why "fatal" and "off" shouldn't be allowed
>> values for all three message variables. If we just did that, then you'd
>> be back to sharable code.
> I recommended he only allow valid values for each variable. I think if
> w
Tom Lane wrote:
> There's some value in being able to kick the log level up a notch for
> a specific session, but knocking it down from the admin's default could
> be considered a bad thing. I suppose we could invent a PGC_SIGHUP
> "min_server_min_messages" variable that sets a minimum value belo
Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > Since the flawed code is now in beta, it will need to be fixed. Do people
> > like the above solution or should I just revert to having a seperate
> > function for each GUC variable affected?
>
> I do not see a good reason why "fatal"
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Since the flawed code is now in beta, it will need to be fixed. Do people
> like the above solution or should I just revert to having a seperate
> function for each GUC variable affected?
I do not see a good reason why "fatal" and "off" shouldn't be allo
On Wed, 4 Sep 2002, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > Does anyone else have an opinion on this? If not, I will implement it per
> > Bruce's commentary.
>
> > On Mon, 2 Sep 2002, Bruce Momjian wrote:
> >> I think the second, passing an arg to say whether it is server
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, I would like to know if it should be enabled by default, and
> whether we need a way to turn it off.
I feel it should be off by default --- if enough people say "hey, this
is great" then maybe we could turn it on by default, but we don't yet
have t
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Does anyone else have an opinion on this? If not, I will implement it per
> Bruce's commentary.
> On Mon, 2 Sep 2002, Bruce Momjian wrote:
>> I think the second, passing an arg to say whether it is server or
>> client, will do the trick, though now you n
Yes, I would like to know if it should be enabled by default, and
whether we need a way to turn it off. I assume, considering the size of
some of the queries, that we have to have a way to turn it off, and it
is possible the admin may not want queries in the log, even if the
generate errors.
--
Hi all,
Does anyone else have an opinion on this? If not, I will implement it per
Bruce's commentary.
Gavin
On Mon, 2 Sep 2002, Bruce Momjian wrote:
> Gavin Sherry wrote:
> > Okay, my bad. From my reading of the email exchange, I thought people
> > wanted this on -- always. The best solution f
On Tue, 3 Sep 2002, Kaare Rasmussen wrote:
> > Are you guys competing for the modesty award? ;-)
> > I heard Stallman is trying to win it this year. :-)
>
> Hah, that's a good one.
>
> For doing what - telling you not to call it GNU/Linux, only Linux/GNU ?
> :-)
SELECT FreeProject FROM His
On Tue, 3 Sep 2002, Kaare Rasmussen wrote:
> > Are you guys competing for the modesty award? ;-)
> > I heard Stallman is trying to win it this year. :-)
>
> Hah, that's a good one.
>
> For doing what - telling you not to call it GNU/Linux, only Linux/GNU ?
> :-)
SELECT FreeProject FROM His
> Are you guys competing for the modesty award? ;-)
> I heard Stallman is trying to win it this year. :-)
Hah, that's a good one.
For doing what - telling you not to call it GNU/Linux, only Linux/GNU ?
:-)
--
Kaare Rasmussen--Linux, spil,--Tlf:3816 2582
Kaki Data
Gavin Sherry wrote:
> Okay, my bad. From my reading of the email exchange, I thought people
> wanted this on -- always. The best solution for this, in my opinion, is to
> have a magic value "off" which the error code lookup translates to some
> number > PANIC.
What do people think? I thought we
On Mon, 2 Sep 2002, Bruce Momjian wrote:
> > >> 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 = fata
Christopher Kings-Lynne wrote:
> > o -ALTER TABLE ADD PRIMARY KEY (Tom)
> > o -ALTER TABLE ADD UNIQUE (Tom)
> >
> > AFAIR, I didn't do either of those; I think Chris K-L gets the credit.
>
> Actually, I did ADD UNIQUE originally after lots of coding and then you went
> and made it work by
> o -ALTER TABLE ADD PRIMARY KEY (Tom)
> o -ALTER TABLE ADD UNIQUE (Tom)
>
> AFAIR, I didn't do either of those; I think Chris K-L gets the credit.
Actually, I did ADD UNIQUE originally after lots of coding and then you went
and made it work by changing a couple of lines in the gramma
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Perhaps one should consider removing the autocommit option. It's no use
> if it's there but everything breaks when you turn it on.
As far as I'm concerned, it's in there for one reason only (as far as
7.3 goes): so that we can run the NIST SQL compl
Tom Lane writes:
> 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
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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.
>
> > * Have SERIAL generate non-colliding sequence names when we have
> > auto-destruction
> >
> > They should be pretty well non-colliding now. What's the gripe exactly?
>
> The issue was that when there were name collisions, we threw an error
> instead of trying other sequence names. We h
Bruce Momjian <[EMAIL PROTECTED]> 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
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> This isn't really done; the backend side is probably okay, but we have
> >> a ton of client-side code that will malfunction if you try to run it in
> >> autocommit-off state.
>
> > My feeling is that we have to f
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This isn't really done; the backend side is probably okay, but we have
>> a ton of client-side code that will malfunction if you try to run it in
>> autocommit-off state.
> My feeling is that we have to fix this during beta.
No we do
gt;,
> > PostgreSQL-development <[EMAIL PROTECTED]>
> > Subject: Re: [HACKERS] I am done
> >
> > "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > > You can probably nail some TODOs:
> >
>
> Maybe add a TODO item:
>
Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > You can probably nail some TODOs:
>
> > * Allow autocommit so always in a transaction block
>
> This isn't really done; the backend side is probably okay, but we have
> a ton of client-side code that will malfunction if
Tom Lane dijo:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > You can probably nail some TODOs:
>
> o -Cluster all tables at once using pg_index.indisclustered set during
> previous CLUSTER
>
> This is not done, unless we are going to accept Alvaro's last-minute
>
On Mon, 2 Sep 2002, Tom Lane wrote:
> Date: Mon, 02 Sep 2002 10:33:49 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Christopher Kings-Lynne <[EMAIL PROTECTED]>
> Cc: Bruce Momjian <[EMAIL PROTECTED]>,
> PostgreSQL-development <[EMAIL PROTECTED]
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> You can probably nail some TODOs:
> * Allow autocommit so always in a transaction block
This isn't really done; the backend side is probably okay, but we have
a ton of client-side code that will malfunction if you try to run it in
autocommi
t; * Cache most recent query plan(s) (Neil) [prepare]
>
> Chris
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian
> > Sent: Monday, 2 September 2002 2:30 PM
> > To: PostgreSQL-development
> >
On Behalf Of Bruce Momjian
> Sent: Monday, 2 September 2002 2:30 PM
> To: PostgreSQL-development
> Subject: [HACKERS] I am done
>
>
> I have finished going through my email box and applying patches from the
> patches queue. There is one patch left in the queue related to tc
I have finished going through my email box and applying patches from the
patches queue. There is one patch left in the queue related to tcl
notification of connection failure. Tom wants to look at that.
I am running tests now on the code.
Tomorrow, I will run pgindent and create the HISTORY fi
38 matches
Mail list logo
