Re: database-level lockdown

Поиск
Список
Период
Сортировка
От Filipe Pina
Тема Re: database-level lockdown
Дата
Msg-id 1436266531.23458.0@smtp.gmail.com
обсуждение исходный текст
Ответ на Re: database-level lockdown  (Adrian Klaver <adrian.klaver@aklaver.com>)
Ответы Re: database-level lockdown  (Alban Hertroys <haramrae@gmail.com>)
Список pgsql-general
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.klaver@aklaver.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.klaver@aklaver.com

В списке pgsql-general по дате отправления:

Предыдущее
От: pinker
Дата:
Сообщение: pg_dump (PostgreSQL) 9.4.1 - delay in checking if file exists
Следующее
От: John McKown
Дата:
Сообщение: Re: [pg_hba.conf] publish own Python application using PostgreSQL