From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Filipe Pina <filipe(dot)pina(at)impactzero(dot)pt>, Melvin Davidson <melvin6925(at)gmail(dot)com> |
Cc: | Postgresql General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: database-level lockdown |
Date: | 2015-07-04 18:23:01 |
Message-ID: | 55982485.90101@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmail(dot)com
> <mailto:melvin6925(at)gmail(dot)com>> wrote:
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Jimit Amin | 2015-07-04 19:19:40 | could not fork new process for connection: Resource temporarily unavailable |
Previous Message | John R Pierce | 2015-07-04 18:10:35 | Re: database-level lockdown |