Search Postgresql Archives

Re: database-level lockdown

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux