Tom,
> So at this point we are facing three options:
> - throw in a large and poorly tested "fix" at the last moment;
> - postpone 8.2 until we can think of a real fix, which might
> be a major undertaking;
> - ship 8.2 with the same behavior 8.0 and 8.1 had.
> None of these are very attractive, but I'm starting to think the last
> is the least bad.
Yes. If it was earlier in the beta cycle I'd say no, but frankly this
behavior has existed for two years without examples of real-life data
loss. Further, the TPC tests, which are supposed to give ACID properties
a workout, would not break this, so the industry doesn't consider it very
important either.
So, I think it needs to go on the list for 8.2.1 or 8.3 (depending on what
changes the fix requires) but I don't think we should hold up the release.
As PR maven, though, you know I'm biased about the release date.
I would suggest a last-minute doc patch documenting the behavior and
suggesting that locks should always be declared in the outer transaction
prior to any savepoints.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco