Re: [HACKERS] Weired FK problem

Поиск
Список
Период
Сортировка
От wieck@debis.com (Jan Wieck)
Тема Re: [HACKERS] Weired FK problem
Дата
Msg-id m11wAo3-0003kGC@orion.SAPserv.Hamburg.dsh.de
обсуждение исходный текст
Ответ на Weired FK problem  (wieck@debis.com (Jan Wieck))
Ответы Re: [HACKERS] Weired FK problem  (Bruce Momjian <pgman@candle.pha.pa.us>)
RE: [HACKERS] Weired FK problem  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Список pgsql-hackers
>     Why  are  the  visibilities  different  between  INSERTED and
>     DELETED tuples?

    There's something weired going on.  As far as I read the code
    in tqual.c, all changes done  by  transactions  that  started
    before  and  committed  after  my  own  transaction should be
    invisible.

    In the case that works now (PK deleted while FK is inserted),
    HeapTupleSatisfiesSnapshot()  tells,  that  the  PK  tuple is
    still alive.  But then it should be locked (for update),  the
    process  blocks,  and  when  the  deleter  commits it somehow
    magically doesn't make it into the SPI return set.

    Anyway,  this  visibility  mechanism  can  never  work   with
    referential integrity constraints.

    At  least the RI trigger procedures need some way to override
    this snapshot qualification temporary, so  the  check's  will
    see  what's  committed,  regardless  who  did  it  and when -
    committed is committed, basta.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #

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

Предыдущее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Weired FK problem
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Weired FK problem