Re: database-level lockdown
От | Adrian Klaver |
---|---|
Тема | Re: database-level lockdown |
Дата | |
Msg-id | 55982485.90101@aklaver.com обсуждение исходный текст |
Ответ на | Re: database-level lockdown (Filipe Pina <filipe.pina@impactzero.pt>) |
Ответы |
Re: database-level lockdown
|
Список | pgsql-general |
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@gmail.com > <mailto:melvin6925@gmail.com>> wrote: > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: