On Sun, Jan 04, 2004 at 05:41:37PM -0600, Mike Nolan wrote:
> > How, exactly, would this happen? Is this worry based on an analysis
> > of the source code, or just speculation?
>
> No, I haven't examined that part of the PG source code. However, I've
> beta tested software for several decades, and I'm wary of any promises
> like those proferred for nextval/currval. Besides, Tom has already pointed
> out one flaw in it, involving persistent connections. (And I could
> easily see how in a large project team the person writing the nextval/currval
> code might not know whether or not the connection was persistent.)
If you can't guarentee which connection you're using, you can't use
transactions at all. If you can't guarentee that then currval/nextval is
the least of your problems. You must hold a connection exclusively if you
want to guarentee anything. If PHP can't do that, don't use it but use
something you can rely on (like non-persistant connections).
> Could there be others? I'm not willing to bet my application's consistency
> and data integrity against it. Assuming that there aren't risks or
> problems with accepted techniques is how most large software projects
> create flaws.
We rely on it all the time, but we guarentee each process gets its own
connection so it's fine. currval/nextval is maintained by the server. If the
backend dies, the transaction rolls back and everything is still consistant.
If the frontend dies, the transaction rolls back too.
> If hackers have done anything positive for software development, it is
> that they have demonstrated that nearly all memory-based schemes can
> have overflow problems.
Again, if the backend dies, the transaction rolls back and you're fine.
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> (... have gone from d-i being barely usable even by its developers
> anywhere, to being about 20% done. Sweet. And the last 80% usually takes
> 20% of the time, too, right?) -- Anthony Towns, debian-devel-announce
