Re: database-level lockdown

Exactly, that's the twist I've decided after some tests yesterday (the
"lock all tables on last try" degraded performance in an obscene way):
giving up on serializable by default.

I wanted to use serializable so developers wouldn't have to worry about
properly using locks, but implementing this "serialization failure"
handler is becoming a major headache...

Thanks guys!

On Ter, Jul 7, 2015 at 1:41 , Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:
> On 07/06/2015 07:15 AM, Filipe Pina wrote:
>> Yes, I've tried to come up with guideline to enumerate tables used in
>> each process, but it's not simple because it's python application
>> calling pgsql functions that use other functions, so it's tricky for
>> a
>> developer re-using existing functions to enumerate the tables used
>> for
>> those. Even if everything is well documented and can be re-used seems
>> like a nasty task...
>
> Still not sure what is you are trying to accomplish.
>
> Is it really necessary that every transaction be serialized?
>
> Or to put it another way, why are you running in serializable by
> default?
>
> Or yet another way, what is the problem you are trying to solve with
> serialized transactions?
>
>
>
>>
>> For now, I'm locking all to be able to close the gap, but I'm also
>> wondering if I could do it in a pgsql function as I mentioned in the
>> question:
>>
>> FUNCTION A
>> -> FUNCTION B
>> ----> lock TABLE
>> -> FUNCTION C
>> ----> TABLE is not locked anymore because function B frees it as
>> soon as
>> it returns
>>
>> Is there someway to have a function that locks some tables on the
>> "outter" transaction instead of its own subtransaction?
>
>
>
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)com