Re: database-level lockdown

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@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 <melvin6925@gmail.com
>>     <mailto:melvin6925@gmail.com>> wrote:
>>
>> --
>> Adrian Klaver adrian.klaver@aklaver.com


--
Adrian Klaver
adrian.klaver@aklaver.com