Re: transaction safety

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: transaction safety
Дата
Msg-id 200102142139.QAA04640@jupiter.jw.home
обсуждение исходный текст
Ответ на Re: transaction safety  (DaVinci <bombadil@wanadoo.es>)
Список pgsql-general
DaVinci wrote:
> On Wed, Feb 14, 2001 at 06:34:01AM -0500, Jan Wieck wrote:
> >     The problem is, that a referential integrity constraint needs
> >     to ensure that from the moment  the  constraint  got  checked
> >     until  your  INSERT got made persistent (COMMIT), nobody else
> >     has a chance to kick out the referenced key.
> >
> >     Due to the lack of the ability to put a shared row lock  with
> >     a  SELECT,  we currently use FOR UPDATE, placing an exclusive
> >     lock onto the referenced key.
>
>  I understand this but, why then other changes on "aviso" get locked?. My
>  first impression is that only referenced keys should be, but not a table
>  that references them.

    You're right, at the time two FK rows referencing the same PK
    get inserted, there is no need to block one  of  them.  Thus,
    PostgreSQL *shouldn't* block.

    But at the time beeing, the foreign key triggers issue a

        SELECT oid FROM <pktable> WHERE <key> = <referenced-value>
        FOR UPDATE;

    Since  both  INSERT  operations  on  the  FK table do it, the
    second one is blocked until COMMIT of  the  first,  releasing
    the lock.

    What we need is something like

        SELECT ...
        WITH LOCK;

    applying  a  shared (read) lock of the PK row. In this state,
    UPDATE/DELETE to the PK row in question  or  SELECT  ...  FOR
    UPDATE  of  that  will  block,  but more SELECT ... WITH LOCK
    would be allowed and pass through without blocking.

    I don't really want that language construct, since  it's  not
    SQL  standard.   Maybe  it's  possible  to  achieve  the same
    behaviour with dirty reads or the  like.  However  it's  done
    finally, it should behave like the above.

>
>  If this works so for now, is any plan to change in future?.
>
> >     In your case it might help to make the constraints  INITIALLY
> >     DEFERRED.  That  causes  that  the  checks  are delayed until
> >     COMMIT, so it shortens the time the lock is present.
>
>  Thanks!. That works fine.

    You're welcome.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Предыдущее
От: Michael Ansley
Дата:
Сообщение: RE: using tables as types in other tables
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Postmaster crashes