RE: Bug in FOREIGN KEY

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: Bug in FOREIGN KEY
Дата
Msg-id EKEJJICOHDIEMGPNIFIJOEBMDHAA.Inoue@tpf.co.jp
обсуждение исходный текст
Ответ на Re: Bug in FOREIGN KEY  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Bug in FOREIGN KEY  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > ISTM commands/trigger.c is broken.
> > The behabior seems to be changed by recent changes made by Tom.
> 
> Hm.  I changed the code to not log an AFTER event unless there is
> actually a trigger of the relevant type, thus suppressing what I
> considered a very serious memory leak in the non-deferred-trigger case.
> Are there cases where we must log an event anyway, and if so what are
> they?  It didn't look to me like the deferred event executor would do
> anything with a logged event that has no triggers ...
> 

Because I don't know details about trigger stuff, I may be
misunderstanding.  As far as I see,  KEY_CHANGED stuff
requires to log every event about logged tuples.

However I'm suspicious if KEY_CHANGED check is necessary.
Removing KEY_CHANGED stuff seems to solve the TODO  FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change
violation"
though it may introduce other bugs. 

Regards,
Hiroshi Inoue


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: PQprint
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Hardwired MAXBACKENDS limit could be history