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.klaver@xxxxxxxxxxx> 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 <melvin6925@xxxxxxxxx <mailto:melvin6925@xxxxxxxxx>> wrote: -- Adrian Klaver adrian.klaver@xxxxxxxxxxx
-- Adrian Klaver adrian.klaver@xxxxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
