Sean Chittenden wrote:
> > Yes, with the BEGIN, it will roll back. With autocommit off, this:
> >
> > > >
> > > > set statement_timeout = 20;
> > > > query_with_error;
> > > > set statement_timeout = 0;
> > > > COMMIT;
> >
> > will not roll back to 0. I
> Yes, with the BEGIN, it will roll back. With autocommit off, this:
>
> > >
> > > set statement_timeout = 20;
> > > query_with_error;
> > > set statement_timeout = 0;
> > > COMMIT;
>
> will not roll back to 0. It will be 20.
But that's the correct/expected behavior, is it not? Th
Sean Chittenden wrote:
> > > Of course, the reason they're rollbackable is:
> > >
> > > begin;
> > > create schema newschema;
> > > set search_path = newschema;
> > > rollback;
> > >
> > > create table junk; -- DOH!
> >
> > And:
> >
> > set statement_timeout = 20;
> > query_with_e
On Wed, 2002-09-18 at 17:08, Anto Prijosoesilo wrote:
> I was afraid that you're going to say that (use
> triggers) :-).
>
> I'm trying _not_ to use triggers because rules are
> more maintainable than triggers here in my
> environment. At least with rules someone who knows SQL
> would be able to
> > Of course, the reason they're rollbackable is:
> >
> > begin;
> > create schema newschema;
> > set search_path = newschema;
> > rollback;
> >
> > create table junk; -- DOH!
>
> And:
>
> set statement_timeout = 20;
> query_with_error;
> set statement_timeout = 0;
>
Rod Taylor wrote:
> > > What about that doesn't make sense? Having SET begin a transaction
> > > seems like a gross violation of POLS and likely to contradict the spec
> > > and cause problems with many applications. -sc
> >
> > I think we left the standard when we made SET rollbackable. Maybe
> > What about that doesn't make sense? Having SET begin a transaction
> > seems like a gross violation of POLS and likely to contradict the spec
> > and cause problems with many applications. -sc
>
> I think we left the standard when we made SET rollbackable. Maybe that
> has to be reopened b
Stephan Szabo wrote:
> On Wed, 18 Sep 2002, Bruce Momjian wrote:
>
> > Sean Chittenden wrote:
> > > > But it seems so illogical that SET doesn't start a transaction, but
> > > > if it is in a transaction, it is rolled back, and this doesn't help
> > > > our statement_timeout example except to req
On Wed, 18 Sep 2002, Bruce Momjian wrote:
> Sean Chittenden wrote:
> > > But it seems so illogical that SET doesn't start a transaction, but
> > > if it is in a transaction, it is rolled back, and this doesn't help
> > > our statement_timeout example except to require that they do BEGIN
> > > to
Sean Chittenden wrote:
> > But it seems so illogical that SET doesn't start a transaction, but
> > if it is in a transaction, it is rolled back, and this doesn't help
> > our statement_timeout example except to require that they do BEGIN
> > to start the transaction even when autocommit is off.
>
> > > I am fine with special casing autocommit. Is that what you are
> > > suggesting?
> >
> > I think he means:
> >
> > Ex:
> > SET autocommit TO off;
> > SHOW autocommit;
> > ROLLBACK;
> > # warning about being outside of a transaction
> > BEGIN;
> > SET autocommit TO on;
> > SHOW autocommit;
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Why exactly did you want the initial SET to not be part of the
> > transaction?
>
> Primarily because existing client-side libraries issue lots of SETs
> while starting a connection.
>
> We may just have to say "those guys are broke
Sean Chittenden wrote:
> > I am fine with special casing autocommit. Is that what you are
> > suggesting?
>
> I think he means:
>
> Ex:
> SET autocommit TO off;
> SHOW autocommit;
> ROLLBACK;
> # warning about being outside of a transaction
> BEGIN;
> SET autocommit TO on;
> SHOW autocommit;
> > ...
> > > I think if we special case autocommit we have to force it to start a
> > > transaction.
> >
> > Be aware that "SET AUTOCOMMIT" does *not* start a transaction in
> > other systems (at least in Ingres, where I first ran into the
> > feature).
> >
> > This case is illustrating a gener
Thomas Lockhart wrote:
> ...
> > I think if we special case autocommit we have to force it to start a
> > transaction.
>
> Be aware that "SET AUTOCOMMIT" does *not* start a transaction in other
> systems (at least in Ingres, where I first ran into the feature).
>
> This case is illustrating a ge
Sean Chittenden wrote:
> > > But that'd result in at least two transactions per connection because
> > > in my database class wrapper I turn autocommit off. Under any kind of
> > > load or performance situations, that's pretty unacceptable. Granted
> > > there's nothing that would need to be flu
> > But that'd result in at least two transactions per connection because
> > in my database class wrapper I turn autocommit off. Under any kind of
> > load or performance situations, that's pretty unacceptable. Granted
> > there's nothing that would need to be flushed to disk (hopefully), it
>
Sean Chittenden wrote:
> > Why exactly did you want the initial SET to not be part of the
> > transaction?
>
> Is having an exception all that bad? What other tunables should be
> outside of the reach of transactions? Maybe an exception should be
> applied to a class of SET tunables. -sc
I am
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Why exactly did you want the initial SET to not be part of the
> transaction?
Primarily because existing client-side libraries issue lots of SETs
while starting a connection.
We may just have to say "those guys are broken if you turn off
autocommit in
Sean Chittenden wrote:
> > > db.transaction do |dbh|
> > > db.do('DELETE FROM tbl WHERE id = 5')
> > > db['AutoCommit'] = true
> > > end
> > >
> > > Because there wasn't a commit given, that shouldn't actually
> > > delete the rows found, but by tossing that AutoCommit in there, it
> > > shou
> > >>> Does turnning autocommit off enter you into a transaction? Am I
> > >>> smoking something or does that seems broken?
> >
> > > Tom, do you want to special case autocommit? I think that would be OK.
> >
> > No, I don't like that either ... in general I do not think SET's
> > behavior sh
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Sean Chittenden <[EMAIL PROTECTED]> writes:
> >>> Does turnning autocommit off enter you into a transaction? Am I
> >>> smoking something or does that seems broken?
>
> > Tom, do you want to special case autocom
> > db.transaction do |dbh|
> > db.do('DELETE FROM tbl WHERE id = 5')
> > db['AutoCommit'] = true
> > end
> >
> > Because there wasn't a commit given, that shouldn't actually
> > delete the rows found, but by tossing that AutoCommit in there, it
> > should and will generate a nifty warning if
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Sean Chittenden <[EMAIL PROTECTED]> writes:
>>> Does turnning autocommit off enter you into a transaction? Am I
>>> smoking something or does that seems broken?
> Tom, do you want to special case autocommit? I think that would be OK
Sean Chittenden wrote:
> db.transaction do |dbh|
> db.do('DELETE FROM tbl WHERE id = 5')
> db['AutoCommit'] = true
> end
>
> Because there wasn't a commit given, that shouldn't actually delete
> the rows found, but by tossing that AutoCommit in there, it should and
> will generate a nifty war
> > > > Problem is that through various DB APIs such as DBI, you can't
> > > > garuntee to the user doing development that that it's the 1st command
> > > > that they're performing.
> > >
> > > OK, but why does my suggestion not work:
> > >
> > > SET autocommit = ON;
> > > COMMIT;
> >
> > H
Sean Chittenden wrote:
> > > > Well there is discussion on whether a SET with autocommit off should
> > > > start a transaction if it is the first command. Right now it does, and
> > > > clearly you have a case where it acts strangely.
> > >
> > > Problem is that through various DB APIs such as
> > > Well there is discussion on whether a SET with autocommit off should
> > > start a transaction if it is the first command. Right now it does, and
> > > clearly you have a case where it acts strangely.
> >
> > Problem is that through various DB APIs such as DBI, you can't
> > garuntee to th
Tom Lane wrote:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> > Does turnning autocommit off enter you into a transaction? Am I
> > smoking something or does that seems broken?
>
> I don't like it either, but Bruce is objecting to changing it.
Tom, do you want to special case autocommit? I t
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Does turnning autocommit off enter you into a transaction? Am I
> smoking something or does that seems broken?
I don't like it either, but Bruce is objecting to changing it.
regards, tom lane
---(end
Sean Chittenden wrote:
> > Well there is discussion on whether a SET with autocommit off should
> > start a transaction if it is the first command. Right now it does, and
> > clearly you have a case where it acts strangely.
>
> Problem is that through various DB APIs such as DBI, you can't
> gar
> > Here's the simplest way of reproducing this:
> >
> > ways# psql -q template1 pgsql
> > template1=# SET AUTOCOMMIT TO OFF;
> > template1=# DROP DATABASE my_db_name;
> > ERROR: DROP DATABASE: may not be called in a transaction block
> >
> > 2002-09-18 11:05:19 LOG: query: select getdatabasee
Sean Chittenden wrote:
-- Start of PGP signed section.
> Here's the simplest way of reproducing this:
>
> ways# psql -q template1 pgsql
> template1=# SET AUTOCOMMIT TO OFF;
> template1=# DROP DATABASE my_db_name;
> ERROR: DROP DATABASE: may not be called in a transaction block
>
> 2002-09-18 11
Tom Lane writes:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> > Is there a place where -fno-fast-math
> > could be used as a CC option if the CC is gcc?
>
> configure is what I had in mind ;-). I can't think of any part of the
> code where we'd really want this sort of optimization enabled.
On Wed, 2002-09-18 at 15:18, [EMAIL PROTECTED] wrote:
> Anto Prijosoesilo ([EMAIL PROTECTED]) reports a bug with a severity of 1
> The lower the number the more severe it is.
>
> Short Description
> Rewriting on multi-record updates is unreliable
I believe this is the proper (or explained) resul
Anto Prijosoesilo ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
Rewriting on multi-record updates is unreliable
Long Description
Using RULEs to push values up a hierarchy of relations fail to work correctly when
multiple rec
> > After looking through gcc, using -O and -ffast-math will create broken
> > code, but -O2 -ffast-math _should_ be okay.
>
> At least in the gcc shipped with Red Hat 7.2, it doesn't seem to matter:
> you get the wrong answer regardless of -O level. Here's the test case
> I used:
>
> [tgl@rh1
Here's the simplest way of reproducing this:
ways# psql -q template1 pgsql
template1=# SET AUTOCOMMIT TO OFF;
template1=# DROP DATABASE my_db_name;
ERROR: DROP DATABASE: may not be called in a transaction block
2002-09-18 11:05:19 LOG: query: select getdatabaseencoding()
2002-09-18 11:05:19 LO
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Is there a place where -fno-fast-math
> could be used as a CC option if the CC is gcc?
configure is what I had in mind ;-). I can't think of any part of the
code where we'd really want this sort of optimization enabled.
> After looking through gcc,
> > Out of curiosity: why does -ffast-math break the datetime rounding code?
What code bits is this for? Is there a place where -fno-fast-math
could be used as a CC option if the CC is gcc? After looking through
gcc, using -O and -ffast-math will create broken code, but -O2
-ffast-math _should_
40 matches
Mail list logo
