ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / стоит ли выдумывать свою сериализацию
10 сообщений из 10, страница 1 из 1
стоит ли выдумывать свою сериализацию
    #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:13
| Ответить | Цитировать | Написать  
стоит ли выдумывать свою сериализацию
    #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:25
| Ответить | Цитировать | Написать  
стоит ли выдумывать свою сериализацию
    #39651157
Я вам не Димон.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Я вам не Димон.
Гость
вот это нужно:
PgSQLanonymous3строго последовательное выполнение (когда только одна из конкурентных транзакций может выполнять эту функцию, а остальные ждать
...
Рейтинг: 0 / 0
28.05.2018, 15:55
| Ответить | Цитировать | Написать  
стоит ли выдумывать свою сериализацию
    #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, 16:36
| Ответить | Цитировать | Написать  
стоит ли выдумывать свою сериализацию
    #39651353
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Я вам не Димон.,

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

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

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


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

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

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

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

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

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

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

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

Что-что?

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

— Я печатаю 1200 знаков в минуту!
— Какая скорость!!!
(Тихо, в сторону):
— Но такая ерунда получается...
...
Рейтинг: 0 / 0
28.05.2018, 22:44
| Ответить | Цитировать | Написать  
стоит ли выдумывать свою сериализацию
    #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, 18:10
| Ответить | Цитировать | Написать  
стоит ли выдумывать свою сериализацию
    #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
30.05.2018, 23:12
| Ответить | Цитировать | Написать  
стоит ли выдумывать свою сериализацию
    #39653057
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkij
Участник
а главное зачем извращаться если есть штатные advisory locks?
...
Рейтинг: 0 / 0
31.05.2018, 09:57
| Ответить | Цитировать | Написать  
стоит ли выдумывать свою сериализацию
    #39653061
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Melkijа главное зачем извращаться если есть штатные advisory locks?

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

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

ну и секьюрити дефайнер никто не отменял. это если про шашечки.
...
Рейтинг: 0 / 0
31.05.2018, 10:04
| Ответить | Цитировать | Написать  
10 сообщений из 10, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / стоит ли выдумывать свою сериализацию
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=39651383&tid=1995751]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 44ms
get topic data:
 12ms
get forum data:
 2ms
get page messages:
 51ms
get tp. blocked users:
 2ms
others: 316ms
total:  457ms
созд. / загр.: 457ms
x
x
Закрыть


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