2013-01-24 18:02 keltezéssel, Tom Lane írta:
Andres Freund <and...@2ndquadrant.com> writes:
On 2013-01-24 11:22:52 -0500, Tom Lane wrote:
Say again? Surely the temp file is being written by whichever backend
is executing SET PERSISTENT, and there could be more than one.
Sure, but the patch acquires SetPersistentLock exlusively beforehand
which seems fine to me.
Why should we have such a lock? Seems like that will probably introduce
as many problems as it fixes. Deadlock risk, blockages, etc. It is not
necessary for atomicity, since rename() would be atomic already.
There is a problem when running SET PERSISTENT for different GUCs
in parallel. All happen to read the same original file, and only one
setting ends up in the result if you rely only on the rename() being atomic.
The LWLock provides the serialization for that problem.
Any opinion whether its acceptable to allow SET PERSISTENT in functions?
It seems absurd to me to allow it, but Amit seems to be of another
opinion.
Well, it's really a definitional question I think: do you expect that
subsequent failure of the transaction should cause such a SET to roll
back?
I think it would be entirely self-consistent to define SET PERSISTENT as
a nontransactional operation. Then the implementation would just be to
write the file immediately when the command is executed, and there's no
particular reason why it can't be allowed inside a transaction block.
If you want it to be transactional, then the point of disallowing it in
transaction blocks (or functions) would be to not have a very large
window between writing the file and committing. But it's still possible
that the transaction would fail somewhere in there, leading to the
inconsistent outcome that the transaction reports failing but we applied
the SET anyway. I do agree that it would be nonsensical to allow SET
PERSISTENT in functions but not transaction blocks.
Another approach is to remember the requested setting until somewhere in
the pre-commit sequence, and then try to do the file write at that time.
I'm not terribly thrilled with that approach, though, because (a) it
only narrows the window for an inconsistent outcome, it doesn't remove
it entirely; (b) there are already too many things that want to be the
"last thing done before commit"; and (c) it adds complexity and overhead
that I'd just as soon this patch not add. But if you want S.P. to be
transactional and allowed inside functions, I think this would be the
only acceptable implementation.
regards, tom lane
--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
