Heh pardon me but...
I was under the impression that for a transaction either all commands
succeed or all commands fail, atleast according to everything I've ever
read. So followign that all SETs done within the scope of a
BEGIN/COMMIT pair should only take effect if the whole set finishes, i
On Mon, Apr 08, 2002 at 12:28:18PM -0400, Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > OK, probably good time for summarization. First, consider this:
> >
> > BEGIN WORK;
> > SET something;
> > query fails;
> > SET something else;
> > COMMIT WORK;
> >
> > Under curre
On Mon, Apr 08, 2002 at 01:03:41PM -0400, Tom Lane wrote:
> The search_path case is the main reason why I'm intent on changing
> the behavior of SET; without that, I'd just leave well enough alone.
Is there more variables like "search_path"? If not, I unsure if one
item is good consideration f
Karel Zak <[EMAIL PROTECTED]> writes:
> It's good point. Why not make it more transparent? You want
> encapsulate it to standard and current SET statement, but if it's
> something different why not use for it different statement?
> SET SESSION search_path TO 'something';
But a plain SET i
Tom Lane wrote:
> It is *not* reliable, at least not in the sense of "the message is
> guaranteed to be delivered even if there's a system crash". Which is
> the normal meaning of "reliable" in SQL environments. If you want that
That is exactly what I mean by "reliable".
Please correct me i
Michael Loftis writes:
> I was under the impression that for a transaction either all commands
> succeed or all commands fail, atleast according to everything I've ever
> read.
That's an urban legend.
A transaction guarantees (among other things) that all modifications to
the database with the
This is a good bug report. I can fix pg_upgrade by adding clog files
containing zeros to pad out to the proper length. However, my guess is
that most people have already upgrade to 7.2.X, so there isn't much
value in fixing it now. I have updated pg_upgrade CVS for 7.3, and
hopefully we will h
Peter Eisentraut wrote:
> Michael Loftis writes:
>
> > I was under the impression that for a transaction either all commands
> > succeed or all commands fail, atleast according to everything I've ever
> > read.
>
> That's an urban legend.
>
> A transaction guarantees (among other things) that a
I wouldn't be so quick to assume that almost everyone has upgraded by now. I
know we have not, at least not in production.
On Tuesday 09 April 2002 02:14 pm, Bruce Momjian wrote:
> This is a good bug report. I can fix pg_upgrade by adding clog files
> containing zeros to pad out to the proper
Mikhail Terekhov <[EMAIL PROTECTED]> writes:
> Please correct me if I'm wrong but the buffer overrun problem in the new
> LISTEN/NOTOFY mechanism means that it is perfectly possible that sending
> backend may drop all or some of the pending NOTIFY messages in case of such
> an overrun.
You would
* Mattew T. O'Connor ([EMAIL PROTECTED]) [020409 15:34]:
> I wouldn't be so quick to assume that almost everyone has upgraded by now. I
> know we have not, at least not in production.
yeah, what he said. Test, QA and development yes, production, no.
-Brad
---(end of b
Bruce Momjian wrote:
>
> OK, we have three possibilities:
>
> o All SETs are honored in an aborted transaction
> o No SETs are honored in an aborted transaction
> o Some SETs are honored in an aborted transaction (current)
>
> I think the problem is our current behavio
Tom Lane wrote:
>
> Karel Zak <[EMAIL PROTECTED]> writes:
> > It's good point. Why not make it more transparent? You want
> > encapsulate it to standard and current SET statement, but if it's
> > something different why not use for it different statement?
>
> > SET SESSION search_path TO '
Hiroshi Inoue wrote:
>
> Bruce Momjian wrote:
> >
> > OK, we have three possibilities:
> >
> > o All SETs are honored in an aborted transaction
> > o No SETs are honored in an aborted transaction
> > o Some SETs are honored in an aborted transaction (current)
> >
> > I t
Bradley McLean wrote:
> * Mattew T. O'Connor ([EMAIL PROTECTED]) [020409 15:34]:
> > I wouldn't be so quick to assume that almost everyone has upgraded by now. I
> > know we have not, at least not in production.
>
> yeah, what he said. Test, QA and development yes, production, no.
The questio
Hiroshi Inoue wrote:
> Hiroshi Inoue wrote:
> >
> > Bruce Momjian wrote:
> > >
> > > OK, we have three possibilities:
> > >
> > > o All SETs are honored in an aborted transaction
> > > o No SETs are honored in an aborted transaction
> > > o Some SETs are honored in an a
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Hiroshi Inoue wrote:
> > >
> > > Bruce Momjian wrote:
> > > >
> > > > OK, we have three possibilities:
> > > >
> > > > o All SETs are honored in an aborted transaction
> > > > o No SETs are honored in an aborted transaction
> > >
Hiroshi Inoue wrote:
> > > Oops does the first mean rolling back the variables on abort ?
> > > If so I made a mistake. The current is better than the second.
> >
> > The second means all SET's are rolled back on abort.
>
> I see.
> BTW what varibles are rolled back on abort currently ?
Current
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > > > Oops does the first mean rolling back the variables on abort ?
> > > > If so I made a mistake. The current is better than the second.
> > >
> > > The second means all SET's are rolled back on abort.
> >
> > I see.
> > BTW what varibles are roll
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > > > > Oops does the first mean rolling back the variables on abort ?
> > > > > If so I made a mistake. The current is better than the second.
> > > >
> > > > The second means all SET's are rolled back on abort.
> > >
> >
On Tue, 9 Apr 2002, Tom Lane wrote:
> Mikhail Terekhov <[EMAIL PROTECTED]> writes:
> > Please correct me if I'm wrong but the buffer overrun problem in the new
> > LISTEN/NOTOFY mechanism means that it is perfectly possible that sending
> > backend may drop all or some of the pending NOTIFY messa
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > >
> > > Hiroshi Inoue wrote:
> > > > > > Oops does the first mean rolling back the variables on abort ?
> > > > > > If so I made a mistake. The current is better than the second.
> > > > >
> > > > > The second means all SET
Hi all,
I've attached a patch for doing BETWEEN SYM/ASYM, however it just doesn't
work!!!
test=# select 2 between 1 and 3;
?column?
--
t
(1 row)
test=# select 2 between 3 and 1;
?column?
--
f
(1 row)
test=# select 2 between symmetric 3 and 1;
ERROR: parser: parse error at
On Wed, 10 Apr 2002, Christopher Kings-Lynne wrote:
> Hi all,
>
> I've attached a patch for doing BETWEEN SYM/ASYM, however it just doesn't
> work!!!
>
> test=# select 2 between 1 and 3;
> ?column?
> --
> t
> (1 row)
>
> test=# select 2 between 3 and 1;
> ?column?
> --
> f
> Chris,
>
> You seem to have forgotten to update keywords.c.
OK - works perfectly now :)
Now I'm going to play with making the SYMMERIC and ASYMMETRIC keywords less
reserved...
Can someone comment on my use of %prec BETWEEN? Is that still correct now
that we have the extra BETWEEN forms?
Chr
Hiroshi Inoue wrote:
> > > ??? What do you mean by
> > >o Some SETs are honored in an aborted transaction (current)
> > > ?
> > > Is the current state different from
> > > o All SETs are honored in an aborted transaction
> > > ?
> >
> > In the case of:
> >
> > BEGIN WORK;
> >
Hiroshi Inoue wrote:
> > > ??? What do you mean by
> > >o Some SETs are honored in an aborted transaction (current)
> > > ?
> > > Is the current state different from
> > > o All SETs are honored in an aborted transaction
> > > ?
> >
> > In the case of:
> >
> > BEGIN WORK;
> >
On Wed, 10 Apr 2002, Christopher Kings-Lynne wrote:
> > Chris,
> >
> > You seem to have forgotten to update keywords.c.
>
> OK - works perfectly now :)
>
> Now I'm going to play with making the SYMMERIC and ASYMMETRIC keywords less
> reserved...
>
> Can someone comment on my use of %prec BETWE
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Take out a database other than PostgreSQL and do
> BEGIN; -- or whatever they use; might be implicit
> INSERT INTO existing_table ('legal value');
> barf;
> COMMIT;
> The INSERT will most likely succeed. The reason is that "barf" does not
> modify
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Take out a database other than PostgreSQL and do
>
> > BEGIN; -- or whatever they use; might be implicit
> > INSERT INTO existing_table ('legal value');
> > barf;
> > COMMIT;
>
> > The INSERT will most likely succeed. The reason
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > > > ??? What do you mean by
> > > >o Some SETs are honored in an aborted transaction (current)
> > > > ?
> > > > Is the current state different from
> > > > o All SETs are honored in an aborted transaction
> > > > ?
> > >
> > > In the ca
Bruce Momjian <[EMAIL PROTECTED]> writes:
> In the case of:
> BEGIN WORK;
> SET x=1;
> bad query that aborts transaction;
> SET x=2;
> COMMIT WORK;
> Only the first SET is done, so at the end, x = 1.
Perhaps even more to the point:
SET x=0;
BEGIN;
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Can someone comment on my use of %prec BETWEEN? Is that still correct now
> that we have the extra BETWEEN forms?
Looks fine. AFAICS we want all these forms to have the binding
precedence assigned to BETWEEN. If you don't do the %prec thi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Actually, we could probably prevent transaction abort on syntax(yacc)
> errors, but the other errors like mistyped table names would be hard to
> prevent a rollback, so I guess we just roll back on any error.
I don't think that what we categorize as an
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > Can someone comment on my use of %prec BETWEEN? Is that still
> correct now
> > that we have the extra BETWEEN forms?
>
> Looks fine. AFAICS we want all these forms to have the binding
> precedence assigned to BETWEEN. If you don't do
...
> Please note that even in those other databases, if one replaces the
> COMMIT with ROLLBACK in the above scenario, the effects of the INSERT
> *will* roll back. Transpose this into current Postgres, and replace
> INSERT with SET, and the effects do *not* roll back. How is that a
> good idea
36 matches
Mail list logo
