Гость
Войти | Профиль | Очистить
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / стоит ли выдумывать свою сериализацию / 10 сообщений из 10, страница 1 из 1
28.05.2018, 15:13
    #39651129
Я вам не Димон.
Я вам не Димон.
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
стоит ли выдумывать свою сериализацию
Устроил эксперимент по стресс-тестированию функции, которая должна выполняться в режиме SERIALIZABLE
Проверку проводил так:

4 разных клиента почти одновременно запускали функцию с интервалом от 90 до 200 миллисекунд с разными параметрами (в цикле - по 100 запусков каждый клиент), код запуска со стороны клиента примерно такой:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
select test.f_change_data(аргумент1, аргумент2, ..., аргументN);

Несмотря на заданный уровень изоляции, иногда функция выдавала EXCEPTION типа serialization_failure.
Значение переменной current_setting('transaction_isolation') из функции видно как 'serializable'.

В голову лезут мысли написать свою "велосипедную" логику выстраивания очереди на выполнение функции, например, создать таблицу очередей на выполнение. Как думаете, есть смысл писать свою сериализацию, или она ничем не будет лучше уже имеющейся?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.05.2018, 15:25
    #39651135
PgSQLanonymous3
PgSQLanonymous3
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
стоит ли выдумывать свою сериализацию
Я вам не Димон.Несмотря на заданный уровень изоляции, иногда функция выдавала EXCEPTION типа serialization_failure.
Значение переменной current_setting('transaction_isolation') из функции видно как 'serializable'.

Не "не смотря", а "потому что". Т.е. так и должно быть!
Прочитайте http://www.postgresql.org/docs/current/static/transaction-iso.html .

Я вам не Димон.В голову лезут мысли написать свою "велосипедную" логику выстраивания очереди на выполнение функции, например, создать таблицу очередей на выполнение. Как думаете, есть смысл писать свою сериализацию, или она ничем не будет лучше уже имеющейся?
Так что вам нужно, очередь (когда какие-то "задания" должны быть обработаны, каждое один раз) или строго последовательное выполнение (когда только одна из конкурентных транзакций может выполнять эту функцию, а остальные ждать или получать ошибку)?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.05.2018, 15:55
    #39651157
Я вам не Димон.
Я вам не Димон.
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
стоит ли выдумывать свою сериализацию
вот это нужно:
PgSQLanonymous3строго последовательное выполнение (когда только одна из конкурентных транзакций может выполнять эту функцию, а остальные ждать
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.05.2018, 16:36
    #39651185
Maxim Boguk
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
стоит ли выдумывать свою сериализацию
Я вам не Димон.вот это нужно:
PgSQLanonymous3строго последовательное выполнение (когда только одна из конкурентных транзакций может выполнять эту функцию, а остальные ждать

advisory locks внутри хранимки вам в помощь
https://www.postgresql.org/docs/10/static/explicit-locking.html#ADVISORY-LOCKS

--
Maxim Boguk
dataegret.ru
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.05.2018, 20:42
    #39651353
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
стоит ли выдумывать свою сериализацию
Я вам не Димон.,

смешалисьфкучуконилюди иядра ты сячиа рудий

субд реализует очередность подхода к снаряду == данным
а очередность доступа и исполнения хфункцей -- дело кодера. на строго монопольную ф-ю вна входе вешаем транзакционный адвайзори на ее процид например. если адвайзори забиты -- заводим табличку локов, доступом к которым будет рулить бд. в ридкоммитеде.

а скрипач не нужен.
сериалазебл бишь
он представляет академический интерес --"как работать с базой, если никто не знает что делает другой."
и именно этот случай нихера не покрывает. посколь другой дропнет вам ваши серийные данные кхерам, снесёт инстанс, на. а то спалит халабуду ,
и пойдёт пиво пит.


всё в рид--коммитед пишецца и фурыкает. и очередицца.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.05.2018, 22:44
    #39651383
PgSQLanonymous3
PgSQLanonymous3
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
стоит ли выдумывать свою сериализацию
qwwqЯ вам не Димон.,
а очередность доступа и исполнения хфункцей -- дело кодера.
Я бы не сказал. IMHO, для того, чтобы управлять очередностью, должна быть веская причина (которую автор темы не указал, к сожалению).

qwwqна строго монопольную ф-ю вна входе вешаем транзакционный адвайзори на ее процид например. если адвайзори забиты -- заводим табличку локов, доступом к которым будет рулить бд.

Можно ещё создать отдельную таблицу (под эту функцию), а потом "BEGIN; LOCK TABLE my_function_lock; ... ;".

qwwqв ридкоммитеде.

Не обязательно. Но при такой постановке может и помочь.

qwwqа скрипач не нужен.
сериалазебл бишь
он представляет академический интерес --"как работать с базой, если никто не знает что делает другой."

Вполне практический интерес, и нормальная ситуация.
Но на самом деле "не быть вынужденным думать, что делает каждый другой".

qwwqи именно этот случай нихера не покрывает. посколь другой дропнет вам ваши серийные данные кхерам, снесёт инстанс, на. а то спалит халабуду ,
и пойдёт пиво пит.

Что-что?

qwwqвсё в рид--коммитед пишецца и фурыкает. и очередицца.
Да-да, слышали уже...
 

— Я печатаю 1200 знаков в минуту!
— Какая скорость!!!
(Тихо, в сторону):
— Но такая ерунда получается...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.05.2018, 18:10
    #39652754
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
стоит ли выдумывать свою сериализацию
PgSQLanonymous3Можно ещё создать отдельную таблицу (под эту функцию), а потом "BEGIN; LOCK TABLE my_function_lock; ... ;".

тоже вариант.
так дешевле :
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
create or replace function testlock () returns int
as 
'
SELECT from pg_proc pc where oid =''testlock''::regproc for UPDATE;
select pg_sleep (10);
select 1;
' language sql;

select testlock();
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.05.2018, 23:12
    #39652896
PgSQLanonymous3
PgSQLanonymous3
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
стоит ли выдумывать свою сериализацию
qwwqтак дешевле :
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
create or replace function testlock () returns int
as 
'
SELECT from pg_proc pc where oid =''testlock''::regproc for UPDATE;
select pg_sleep (10);
select 1;
' language sql;
select testlock();


Только вот работает только для superuser-a.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 09:57
    #39653057
Melkij
Melkij
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
стоит ли выдумывать свою сериализацию
а главное зачем извращаться если есть штатные advisory locks?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 10:04
    #39653061
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
стоит ли выдумывать свою сериализацию
Melkijа главное зачем извращаться если есть штатные advisory locks?

товарищу ононимусу похер, он за идею фикс сражаица. за насериалазебл. кучкой.

а вам-то грех не въезжать, что на хера расходовать общий ресурс адвайзори
весьма ограниченный
//кстати не столь родной как роу-лок, и не настолько давно штатный
когда у ф--ии есть свой природный ресурс -- её роу в плпроке.

ну и секьюрити дефайнер никто не отменял. это если про шашечки.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / стоит ли выдумывать свою сериализацию / 10 сообщений из 10, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 416ms
Закрыть
start [/forum/topic.php?fid=53&mobile=1&tid=1995751]:
 0ms
get settings:
 8ms
get forum list:
 11ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 55ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 43ms
get tp. blocked users:
 1ms
others: 279ms
total:  416ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]