ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / пятничный псто о порядке "событий" записей стейтмента
31 сообщений из 31, показаны все 2 страниц
  все  
пятничный псто о порядке "событий" записей стейтмента
    #38977455
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
//в частности к знатокам лондайста.

-- есть ли какие-то гарантии того, в каком порядке обрабатываются [ и будут и далее] события записей внутри транзакции ?

вводная :
1. есть триггер записи событий, висит на after insert|update|delete каждой записи. генерит [, кроме записи txid_current()], еще и nextval в ev_id (как в pgq.event примерно)

-- идея банальная -- писать события, и обрабатывать в месте назначении в подходящем порядке [пока не уточняем, в каком].

теперь генерю тестовый батч "событий"
 
Код: sql
1.
2.
WITH del AS (DELETE FROM my_table v WHERE my_table_id BETWEEN 0 AND  100 RETURNING v.*)
INSERT INTO my_table SELECT * FROM del;


и вижу -- последними 100 за ev_id пришли обработки события удаления строки (СТЕ-стейтмента), а не вставки строк (того же СТЕ --стейтмента).


-- вот тут то и возникает вопрос, об опущенном выше "подходящем порядке".



PS Вспоминается -- у лондайста[3-го] триггера фиксации событий по умолчанию срабатывают в after [, но есть опция -- перенести триггер на событие before]. А порядок реплицирующих стейтментов внутри батча -- кажется только по ev_id [pgq.batch_event_sql()] . Как они выкручиваются, в свете вышесказанного? кто-нть разбирался ? Или там таки будет дырка ?
...
Рейтинг: 0 / 0
05.06.2015, 14:32
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38978435
Winnipuh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Winnipuh
Участник
"и вижу -- последними 100 за ev_id пришли обработки события удаления строки (СТЕ-стейтмента), а не вставки строк (того же СТЕ --стейтмента). "

ну так может из-за returning?
...
Рейтинг: 0 / 0
07.06.2015, 14:57
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38978449
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Winnipuh"и вижу -- последними 100 за ev_id пришли обработки события удаления строки (СТЕ-стейтмента), а не вставки строк (того же СТЕ --стейтмента). "

ну так может из-за returning?
нежданчик в том, что интуиция о том, что триггера "на запись" отработают (внутри одной и той же транзакции!) в том же порядке. в каком потом "события записи" можно будет накатить на реплику -- разрушается таким вот поведением CTE.

Или в лондайсте это как-то преодолевается, или реализатор именно такой отработки CTE был вредителем из конкурирующей команды "слони" (кстати как там реализована логика -- ещё надо посмотреть) .
...
Рейтинг: 0 / 0
07.06.2015, 15:43
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38983599
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
план надо смотреть -- станет всё понятно, возможны два варианта: ddddd...iiiii... , didididi.... .

но, в любом случае, делит конкретной "строки" будет перед её "следующим" инсертом.
...
Рейтинг: 0 / 0
14.06.2015, 23:45
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38983670
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Misha Tyurinплан надо смотреть -- станет всё понятно, возможны два варианта: ddddd...iiiii... , didididi.... .

но, в любом случае, делит конкретной "строки" будет перед её "следующим" инсертом."если факты не ложатся в теорию -- тем хуже для фактов"

я намерил то что намерил -- сначала за сиквеносм заходят 100 инсертов, потом 100 дилетов. но никаких виолейшенов не наблюдается.
пичалька

надо, кстати, напрячь стандартный лондайст -- посмотреть, что с ним будет

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

за счет мерджа (там на деле партицированный таргет) просел на порядок -- надо что-то придумывать.
...
Рейтинг: 0 / 0
15.06.2015, 08:29
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38983963
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
авторя намерил то что намерил -- сначала за сиквеносм заходят 100 инсертов, потом 100 дилетов

где воспроизводимый код? так не может быть
...
Рейтинг: 0 / 0
15.06.2015, 13:59
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38983996
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Misha Tyurinавторя намерил то что намерил -- сначала за сиквеносм заходят 100 инсертов, потом 100 дилетов

где воспроизводимый код? так не может быть
я тоже сильно обиделся, когда увидел.

а воспроизводимый код -- 2 таблицы (данные + ивенты), один триггер регистрации ивентов, на все события, after
-- лениво пока.

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

У вас под руками лондайст. в нем уже есть pgq.events_i_k -- и триггера публикации.
попробуйте удалить и сразу вставить пачку в какой-то ненужной табличке, результат смотрите в pgq.events_i_k [order by ev_id]
отпишитесь.

если будет что писать (оно таки сдохнет) -- будет интересно
-- а не будет -- будет интересно выяснить, почему оно так, а не этак.
...
Рейтинг: 0 / 0
15.06.2015, 14:37
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38984076
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
всё много раз поверенно, возможны два варианта:
1) didididi...
2) dddd... iiii...

варианта iiiiii dddd
не может быть.

вот тут можно проверять
 

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
  /*

  create table tmp.test_trg(
    id serial primary key,
    tag text
  );
  create table tmp.test_trg_log(  
    ev_id serial primary key,
    txid bigint default txid_current(),    
    xdata text
  );

  create or replace function tmp.test_trg_func() returns trigger language 'plpgsql' as
  $$
    begin    
      insert into tmp.test_trg_log ( xdata ) select TG_OP || ' ' || hstore( case when TG_OP = 'DELETE' then OLD else NEW end );
      return null;
    end;
  $$;

  create trigger test_trg after insert or update or delete on tmp.test_trg for row execute procedure tmp.test_trg_func();

  */

  --truncate tmp.test_trg;
  --truncate tmp.test_trg_log;  

  --insert into tmp.test_trg ( tag ) select md5(oid::text) from pg_class;
  --table tmp.test_trg;

  --table tmp.test_trg_log;

  /*

  --explain -- попробовать seq scan
  with
    del as ( delete from tmp.test_trg t where t.id between 29444 and 29454 returning t.* )
  insert into tmp.test_trg
    select * from del
    ;

  */

  select * from tmp.test_trg_log order by ev_id
  
  ----------------------------------------------------
  
  
   /*

  drop table tmp.test_trg;
  create table tmp.test_trg(
    id serial primary key,
    tag text
  );
  drop table tmp.test_trg_log;
  create table tmp.test_trg_log(  
    ev_id serial primary key,
    txid bigint default txid_current(),    
    xdata text
  );

  create or replace function tmp.test_trg_func() returns trigger language 'plpgsql' as
  $$
    begin    
      insert into tmp.test_trg_log ( xdata ) select TG_OP || ' ' || hstore( case when TG_OP = 'DELETE' then OLD else NEW end );
      return null;
    end;
  $$;

  create trigger test_trg after insert or update or delete on tmp.test_trg for row execute procedure tmp.test_trg_func();

  */

  --truncate tmp.test_trg;
  --truncate tmp.test_trg_log;  

  --insert into tmp.test_trg ( tag ) select md5(oid::text) from pg_class;
  --table tmp.test_trg;

  --table tmp.test_trg_log;

  /*
  set enable_indexscan = false;
  set enable_bitmapscan = false;
  --explain analyze -- попробовать seq scan
  with
    del as ( delete from tmp.test_trg t where t.id between 80 and 90 returning t.* ),
    x as ( select * from del where id in (select * from generate_series(80, 90)) )
  insert into tmp.test_trg
    select * from x
    ;


...
Рейтинг: 0 / 0
15.06.2015, 16:06
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38984120
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Misha Tyurin<>
варианта iiiiii dddd
не может быть.
<>
в вашем кейсе у меня didi

но тем не менее в моем:
 
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
SELECT ev_id, ev_time, ev_txid --,tg_table,tg_schema
	,tg_op --, new_key, old_key, new_body
FROM pgqq.events_10_0

  order by ev_id desc limit 200;
-----------------------------
76809;"2015-06-15 16:43:14.376189+03";15162808;"D"
76808;"2015-06-15 16:43:14.375625+03";15162808;"D"
76807;"2015-06-15 16:43:14.375067+03";15162808;"D"
76806;"2015-06-15 16:43:14.374362+03";15162808;"D"
......
76612;"2015-06-15 16:43:12.410701+03";15162808;"I"
76611;"2015-06-15 16:43:12.284678+03";15162808;"I"
76610;"2015-06-15 16:43:12.188659+03";15162808;"I"


-- т.е. быть то он может
т.е. суслик, битым словом, есть.
уже интересно.

осталось повторить в железе, удалив всё ненужное.

у меня правда таблица партицирована. триггера партицирования -- BEFORE.
...
Рейтинг: 0 / 0
15.06.2015, 17:02
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38984122
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
а может дело и не в триггерах
...
Рейтинг: 0 / 0
15.06.2015, 17:08
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38984124
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Misha Tyurin,

ага, удалось:

 
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
CREATE schema tmp;
create extension hstore;

create table tmp.test_trg_0(
    id serial primary key,
    tag text
  );

create table tmp.test_trg(
	LIKE  tmp.test_trg_0 INCLUDING ALl
  )
INHERITS  (tmp.test_trg_0);
  
create table tmp.test_trg_log(  
    ev_id serial primary key,
    txid bigint default txid_current(),    
    xdata text
  );

create or replace function tmp.test_trg_func() returns trigger language 'plpgsql' as
$$
begin    
  insert into tmp.test_trg_log ( xdata ) select TG_OP || ' ' || hstore( case when TG_OP = 'DELETE' then OLD else NEW end );
  return null;
end;
$$;


create trigger test_trg after insert or update or delete on tmp.test_trg for row execute procedure tmp.test_trg_func();

create or replace function tmp.test_trg2_func() returns trigger language 'plpgsql' as
$$
begin    
  insert into tmp.test_trg SELECT NEW.*;
  return null;
end;
$$;
create trigger test2_trg BEFORE insert on tmp.test_trg_0 for EACH row execute procedure tmp.test_trg2_func();


TRUNCATE  tmp.test_trg_log;

  with
    del as ( delete from tmp.test_trg_0 t where t.id between 315 and 615 returning t.* )
  insert into tmp.test_trg_0
    select * from del
    ;
select * from tmp.test_trg_log order by ev_id DESC;

...
Рейтинг: 0 / 0
15.06.2015, 17:12
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38984154
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
не смотрел пока.

дело точно не в asc/desc?

у меня

select * from tmp.test_trg_log order by ev_id

у вас

select * from tmp.test_trg_log order by ev_id DESC;
...
Рейтинг: 0 / 0
15.06.2015, 17:45
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38984158
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Misha Tyurin,

дело в эмуляции партицирования. И запросе к "голове" а не к "партиции".

т.е. сухой остаток -- "они такие бывают", а как их сгенерировать -- дело техники.


т.е. основополагающая интуиция велосипедов бывает неверна.
...
Рейтинг: 0 / 0
15.06.2015, 17:52
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38984525
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Лузанов
Участник
qwwq,

Здесь вот какое дело.
Триггер test_trg, который регистрирует события, объявлен как AFTER FOR EACH ROW.
Как известно, такие триггера срабатывают в конце работы всего оператора (в данном случае DELETE ... INSERT),
уже после того, как все строки будут обработаны.
Строки, действительно, обрабатываются в правильном порядке: сначала DELETE, затем INSERT.
Но гарантии, что after row триггера будут срабатывать именно в таком же порядке документация вообще-то не дает.

Если заменить этот триггер на before for each row, то события будут регистрироваться в правильном порядке.
 

drop schema tmp cascade;
CREATE schema tmp;

create table tmp.test_trg_0(
id serial primary key,
tag text
);

create table tmp.test_trg(
LIKE tmp.test_trg_0 INCLUDING ALl
)
INHERITS (tmp.test_trg_0);

create table tmp.test_trg_log(
ev_id serial primary key,
txid bigint default txid_current(),
xdata text
);

/*
create or replace function tmp.test_trg_func() returns trigger language 'plpgsql' as
$$
begin
insert into tmp.test_trg_log ( xdata ) values ( TG_OP );
return null;
end;
$$;
create trigger test_trg after insert or update or delete on tmp.test_trg for row execute procedure tmp.test_trg_func();
*/

create or replace function tmp.test_trg2_func() returns trigger language 'plpgsql' as
$$
begin
insert into tmp.test_trg SELECT NEW.*;
return null;
end;
$$;
create trigger test2_trg BEFORE insert on tmp.test_trg_0 for EACH row execute procedure tmp.test_trg2_func();

create or replace function tmp.test_trg3_func() returns trigger language 'plpgsql' as
$$
begin
insert into tmp.test_trg_log ( xdata ) values ( TG_OP );
if TG_OP IN ('INSERT', 'UPDATE')
then
return NEW;
elsif TG_OP = 'DELETE'
then
return OLD;
end if;
end;
$$;
create trigger test_trg3 before insert or update or delete on tmp.test_trg for row execute procedure tmp.test_trg3_func();

insert into tmp.test_trg_0 values (1, '1');
TRUNCATE tmp.test_trg_log;

with
del as ( delete from tmp.test_trg_0 t where t.id = 1 returning t.* )
insert into tmp.test_trg_0
select * from del
;
select * from tmp.test_trg_log order by ev_id DESC;
...
Рейтинг: 0 / 0
16.06.2015, 11:15
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38984585
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Павел Лузанов, это хорошо, про костылик.

но "тут вот какое дело" : в небезысвестном лондайсте триггера записи событий по умолчанию ставятся именно на афтырь:
Код: sql
1.
2.
3.
4.
5.
CREATE TRIGGER _londiste_queue_name
  AFTER INSERT OR UPDATE OR DELETE
ON tablename
FOR EACH ROW
  EXECUTE PROCEDURE pgq.logutriga('queue_name');


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

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


то, что существуют местные костылики, что-то частично правящие в конкретных случаях -- слабое утешение. ибо велосипедики позиционируются как относительно универсальные.
...
Рейтинг: 0 / 0
16.06.2015, 11:54
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38984601
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Лузанов
Участник
qwwq,

Я так и думал, что after row триггер создает лондайст, с которым мне не доводилось иметь дело.
Пока это выглядит как баг именно в лондайсте.

А вообще пример очень интересный, отдельное спасибо за тест кейс.
...
Рейтинг: 0 / 0
16.06.2015, 12:05
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38984605
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
qwwq<>

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

явный образчик шизофазии.


авторданным стулом матер гамбс забил костыль в крышку гроба этого <далее по тексту>
...
Рейтинг: 0 / 0
16.06.2015, 12:08
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38984621
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Павел Лузановqwwq,

Я так и думал, что after row триггер создает лондайст, с которым мне не доводилось иметь дело.
Пока это выглядит как баг именно в лондайсте.

А вообще пример очень интересный, отдельное спасибо за тест кейс.я не думаю, что это лондайст--специфично. К тому же триггера на бефоре имеют полное право налететь на проблему как того же (никто ничего не гарантирует)
, так и другого характера. -- а именно перехватить "данные" так по факту и не попавшие никуда (событие, отмененное позже).

Я этим кое--где пользуюсь , т.к. лондайст позволяет повесить и триггера before, можно "реплицировать" виртуальную вставку.


И да, я лепил нечто своё, по мотивам -- и налетел. Т.е. проблема не в лондайсте, проблема в интуиции.

А на лондайсте я этот вычурный случай и не проверял. Может быть там таки есть какое волшебное слово от сглаза.
...
Рейтинг: 0 / 0
16.06.2015, 12:18
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38984638
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Лузанов
Участник
qwwq,
триггера на бефоре имеют полное право налететь на проблему как того же (никто ничего не гарантирует)

Ну не знаю. Про before row документировано, что:
Row-level BEFORE triggers fire immediately before a particular row is operated on...

так и другого характера. -- а именно перехватить "данные" так по факту и не попавшие никуда (событие, отмененное позже).

Но если транзакция будет прервана, то произойдет откат всех изменений, в том числе и сделанных триггером.
...
Рейтинг: 0 / 0
16.06.2015, 12:34
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38984646
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Павел Лузановqwwq,
<>так и другого характера. -- а именно перехватить "данные" так по факту и не попавшие никуда (событие, отмененное позже).

Но если транзакция будет прервана, то произойдет откат всех изменений, в том числе и сделанных триггером.
"вы не поняли"(сс)
-- транзакция не будет откачена. просто найдётся ещё один триггер с винтом, делающий [иногда] return null; и именуемый в алфавитной сортировке более отложенным именем.

Что я в принципе и упоминал выше, как репликацию виртуальной вставки.

или примитивно меняющий поля триггер, но позже "фиксирующего события".
...
Рейтинг: 0 / 0
16.06.2015, 12:41
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38984651
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Лузанов
Участник
qwwq,

Убедительно, согласен.
...
Рейтинг: 0 / 0
16.06.2015, 12:44
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38985085
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
бррррр ... во херота) надо еще смотреть
...
Рейтинг: 0 / 0
16.06.2015, 17:34
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38986363
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
[GENERAL] writable cte triggers reverse order

написал в рассылку
...
Рейтинг: 0 / 0
18.06.2015, 00:20
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38986575
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Misha Tyurin,

в спортлото написали ?

тут павел прав -- это не проблема постгреса, а проблема использования негодной интуиции, как минимум -- в порядко--зависимой after логике. Видимо (если понимать цитату павла в буквальном смысле) -- для before логики это проблемы нет, и это даже, вероятно, строго доказуемо. (нужны детали о принципах реализации [чтобы умозаключать об "интегралах движения"] -- т.ч. не буду утверждать)

т.е. писать надо тем, кто использует неверную логическую посылку. (а я пока не выяснял дотошно -- есть ли достоверно такие, кроме меня).
...
Рейтинг: 0 / 0
18.06.2015, 10:29
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38986984
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Лузанов
Участник
qwwq,

Кстати, ты правильно отмечал, что здесь замешано partitioning.

До тех пор, пока была обычная таблица, after row триггера для with delete ... insert работали в ожидаемом порядке (Мишин пример).
Как только таблица стала секционированной - ситуация поменялась.
А что изменилось.
Изменилось, что delete добирается до искомой таблицы через наследование, а insert через триггер, разруливающий вставку в нужные секции.
Вот где-то в этом месте порядок и сломался.
Но, как я и писал ранее, его никто и не гарантировал.
...
Рейтинг: 0 / 0
18.06.2015, 14:40
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38987870
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Лузанов
Участник
Том Лэйн всё http://www.postgresql.org/message-id/3443.1434636106@sss.pgh.pa.us]расставил по местам.

Я, пока в теме, нарисовал картинку как всё происходит и добавил пару слов.
Чисто, чтобы потом не вспоминать.
...
Рейтинг: 0 / 0
19.06.2015, 13:11
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38988345
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Павел ЛузановТом Лэйн всё http://www.postgresql.org/message-id/3443.1434636106@sss.pgh.pa.us]расставил по местам.он объяснил, почему "она утонула".

но не то -- действительно ли такое поведение ("она тонет") - "правильно".

т.е. это не "расставил по местам".
это "описал причину текущего поведения".
это немного не тот ответ.

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

на сём -- соль ответа: -- можно пользоваться вашими диаграммами, для предсказания порядка срабатывания афтер--обработчиков при наличии "instead" триггеров [и приравненых]. А к системам триггерной репликации впредь подходить осторожно, а не как к гарантированным универсалиям. И работать с ними только разрешенными методами.
...
Рейтинг: 0 / 0
19.06.2015, 16:53
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38988547
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
я там посмотрел внутрь кода вызова триггеров, есть конечно замечания.
например! : меня щас интересует, почему я не могу на delete триггере old подменять.

они игнорят "ретурн" old
http://doxygen.postgresql.org/trigger_8c.html#acbfcf94c1d188020ff1fcfc9280b0600
сравните с update
http://doxygen.postgresql.org/trigger_8c.html#a4daa91dfefe19f48d2c7b947f9ca83ef
и как они new прокидывают там.

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

вот была идея -- но хрен пока.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
create or replace function tmp.test_trg_inh_func() returns trigger language 'plpgsql' as
$$
declare
  _new tmp.test_trg;
  _old tmp.test_trg;
begin 

  if ( TG_OP = 'INSERT' ) then
    insert into tmp.test_trg select NEW.*;
    _new.id := NEW.id;                                                       -- храним в родителе только id             
    return _new;                             
  elsif ( TG_OP = 'DELETE' ) then  
    delete from tmp.test_trg t where t.id = OLD.id returning t.* into _old;  -- делит возвращаем из ребенка
    raise notice '(%) (%)', _old, OLD;
    return _old;
  else
    raise '-';
  end if;

end;
$$;


буду еще писать.
...
Рейтинг: 0 / 0
19.06.2015, 20:06
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38988922
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Павел ЛузановТом Лэйн всё http://www.postgresql.org/message-id/3443.1434636106@sss.pgh.pa.us]расставил по местам.
ещё раз прочитал нагрёбнутые в кучку аглицкие словеса -- в общем херню он пишет.
"спросите тома, и ваши уши покроются толстым слоем лапши".

он оперирует неопределенным понятием "завершение стейтмента" -- что это такое - никто не знает. предположу, что завершение [в т. ч. обработчиков, если есть] события before последнего row в стейтменте.
тогда прямой вывод -- данная херня есть быть происходить оттого, что разрабцы поленились сообразить, что cte не стейтмент, а мультистейтмент. вернитесь к абстракции стейтмент мультистейтмента -- и всё вернётся на место -- сначала "завершится" (!хехе) последний before sub-DELETE cte -- потом -- пойдут все события after его же - потом before инсерта, внутри которых after для рядков в триггере, потом ... ну, вы поняли. ага. Т.е. какая-то минимальная стройность восстановится. (но есть и там проблемы, кажется, ну да хер с ними).
...
Рейтинг: 0 / 0
20.06.2015, 16:11
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38988930
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
нда, надо разбираться с cte
...
Рейтинг: 0 / 0
20.06.2015, 16:38
| Ответить | Цитировать | Написать  
пятничный псто о порядке "событий" записей стейтмента
    #38989396
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
Это от того что никто не предполагал в те времена хаков с удалением в cte.
...
Рейтинг: 0 / 0
22.06.2015, 09:58
| Ответить | Цитировать | Написать  
31 сообщений из 31, показаны все 2 страниц
  все  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / пятничный псто о порядке "событий" записей стейтмента
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=53&tid=1997921]:
 0ms
get settings:
 5ms
get forum list:
 19ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 163ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 65ms
get tp. blocked users:
 1ms
others: 207ms
total:  478ms
созд. / загр.: 478ms
x
x
Закрыть


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