Re: [BUGS] Bug #613: Sequence values fall back to previously chec

From: "Rod Taylor" <rbt(at)zort(dot)ca>
To: "Clark C (dot) Evans" <cce(at)clarkevans(dot)com>, "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUGS] Bug #613: Sequence values fall back to previously chec
Date: 2002-03-16 02:02:25
Message-ID: 02f601c1cc8e$9e856850$8001a8c0@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

I do basically the same thing for files. Except I md5 a 4 character
random string, and the sequence ID just incase I get the same one
twice -- as it's never been written in stone that I wouldn't -- not to
mention the high number of requests for returning a sequence ID back
to the pool on a rollback.

Anyway, you might try using the OID rather than a sequence ID but if
you rollback the database commit due to failure of an action
externally, shouldn't you be cleaning up that useless external stuff
as well?
--
Rod Taylor

This message represents the official view of the voices in my head

----- Original Message -----
From: "Clark C . Evans" <cce(at)clarkevans(dot)com>
To: "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Sent: Friday, March 15, 2002 8:54 PM
Subject: Re: [HACKERS] [BUGS] Bug #613: Sequence values fall back to
previously chec

> (userland comment)
>
> On Fri, Mar 15, 2002 at 01:05:33AM -0800, Vadim Mikheev wrote:
> | > But sequences should not be under transaction control. Can you
> | > safely rollback a sequence? No! The only way to ensure that
would
> | ...
> | > Placing a restriction on an application that says it must treat
the values
> | > returned from a sequence as if they might not be committed is
absurd.
> |
> | Why? The fact that you are not able to rollback sequences does not
> | necessary mean that you are not required to perform commit to
ensure
> | permanent storage of changes made to database.
>
> I use sequences to generate message identifiers for a simple
> external-to-database message passing system. I also use
> them for file upload identifiers. In both cases, if the
> external action (message or file upload) succeeds, I commit;
> otherwise I roll-back. I assume that the datbase won't give
> me a duplicate sequence... otherwise I'd have to find some
> other way go get sequences or I'd have duplicate messages
> or non-unique file identifiers.
>
> With these changes is this assumption no longer valid? If
> so, this change will break alot of user programs.
>
> | And why? Just for convenience of << 1% applications which need
> | to use sequences in their own, non-database, external objects?
>
> I think you may be underestimating the amount of "external
resources"
> which may be associated with a datbase object. Regardless, may of
the
> database features in PostgreSQL are there for 1% or less of the
> user base...
>
> Best,
>
> Clark
>
> --
> Clark C. Evans Axista, Inc.
> http://www.axista.com 800.926.5525
> XCOLLA Collaborative Project Management Software
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
majordomo(at)postgresql(dot)org
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Vadim Mikheev 2002-03-16 06:04:09 Re: [BUGS] Bug #613: Sequence values fall back to previously chec
Previous Message Clark C . Evans 2002-03-16 01:54:02 Re: [BUGS] Bug #613: Sequence values fall back to previously chec

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2002-03-16 02:30:21 Re: Anyone have a SQL code for cumulative F distribution function?
Previous Message Clark C . Evans 2002-03-16 01:54:02 Re: [BUGS] Bug #613: Sequence values fall back to previously chec