From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Jan Wieck" <janwieck(at)yahoo(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Bug in FOREIGN KEY |
Date: | 2001-01-27 04:29:30 |
Message-ID: | EKEJJICOHDIEMGPNIFIJOEBMDHAA.Inoue@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-01-27 04:43:00 | Re: Hardwired MAXBACKENDS limit could be history |
Previous Message | Bruce Momjian | 2001-01-27 04:28:01 | Re: PQprint |