Re: database-level lockdown

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Filipe Pina <filipe(dot)pina(at)impactzero(dot)pt>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: database-level lockdown
Date: 2015-07-07 00:41:12
Message-ID: 559B2028.4040809@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Nolan 2015-07-07 01:18:42 Re: Average New Users Per DOW
Previous Message Adrian Klaver 2015-07-07 00:33:05 Re: database-level lockdown