On 07/06/2015 07:10 AM, Filipe Pina wrote:
It's not necessary to commit at all costs, it can fail, just not due to
serialization..
And the transaction can be something as simple as updating a field or
inserting a record (with foreign keys which is one the serialization
checks).
Not following, why throw serialization at a FK?
On Sáb, Jul 4, 2015 at 7:23 , Adrian Klaver <adrian.kla...@aklaver.com>
wrote:
On 07/04/2015 10:49 AM, Filipe Pina wrote:
Thanks for the suggestion. I read that some people do use that
strategy for maintenance sometimes but it's no feasible in this
scenario. I would have to disallow new connections AND kill all
existing connections (as there would be an existing connection
pool), but this won't have the same impact as using LOCKs..
Terminating all sessions will break every other transaction
(except for the one doing it). Locking database will put all the
other on hold. As we're talking about quick/instant operations on
hold will have impact on performance but won't cause anything to
abort.. I really can't find any other solution for what I need (in
short: make sure no transactions are left out due to serialization
failures)
Which would seem to indicate you have painted yourself into a corner.
The idea of locking an entire database to get one transaction to
commit seems a little extreme to me. What is this transaction trying
to do and why is it necessary that it commit at all costs?
On 03/07/2015, at 19:00, Melvin Davidson <melvin6...@gmail.com
<mailto:melvin6...@gmail.com>> wrote:
--
Adrian Klaver adrian.kla...@aklaver.com
--
Adrian Klaver
adrian.kla...@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general