Обсуждение: External functions/languages and transactions

Поиск
Список
Период
Сортировка

External functions/languages and transactions

От
Philip Warner
Дата:
Dear All,

I've been working (a little) on external functions and laguages recently, and was wondering how PG handles updates to
librariesand/or stored procedures in the context of transactions. This is probably most relevant to Perl, but really
appliesto any external function.
 

If:

1. user A starts a TX, and calls a user defined function in userlib.so, 
2. user B changes, recompiles, and reloads the shared library
3. user A calls the same function within the same TX.

Does PG prevent the 'load' command by user B (via locking)?
Does user A get a different result?
Does user A's backend not load the new module until after a commit?

In the extreme case this is obvoiusly totally outside the control of PostgreSQL, but in the case of Perl, which
includesall sorts of external files, should the implementor of PL/Perl be careful to NOT update already loaded module?
Orto update them ASAP?
 

This is probably too unlikely to worry about, but I am (academically) interested...


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: +61-03-5367 7422            |                 _________  \
Fax: +61-03-5367 7430            |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


Re: [HACKERS] External functions/languages and transactions

От
wieck@debis.com (Jan Wieck)
Дата:
Philip Warner wrote:

>
> Dear All,
>
> I've been working (a little) on external functions and laguages recently, and was wondering how PG handles updates to
librariesand/or stored procedures in the context of transactions. This is probably most relevant to Perl, but really
appliesto any external function. 
>
> If:
>
> 1. user A starts a TX, and calls a user defined function in userlib.so,
> 2. user B changes, recompiles, and reloads the shared library
> 3. user A calls the same function within the same TX.
>
> Does PG prevent the 'load' command by user B (via locking)?
> Does user A get a different result?
> Does user A's backend not load the new module until after a commit?
>
> In the extreme case this is obvoiusly totally outside the control of PostgreSQL, but in the case of Perl, which
includesall sorts of external files, should the implementor of PL/Perl be careful to NOT update already loaded module?
Orto update them ASAP? 
>
> This is probably too unlikely to worry about, but I am (academically) interested...


    It's  mostly  OS dependant. PostgreSQL itself load's a shared
    object only the first time it is  required  PER  BACKEND.  It
    remembers  which objects have been loaded by path. So for the
    entire lifetime of a connection, PostgreSQL will never reload
    a  once  dynamically linked library. So the new functionality
    will only show up if you reconnect.

    If the OS supports writing into shared objects  that  are  in
    use,  and what would happen if it is done - dunno! Some might
    allow it but the backend potentially dumps core - some  might
    deny write access - some might whatever.

    Under  every  UNIX  operating system, there's a clean way you
    can protect the backend from any danger. Install  the  shared
    objects in a common place (like PGLIB) and inside the install
    target, first remove an eventually existing old version. That
    would cause that the real deletion of the old version will be
    delayed by the  OS  until  the  last  backend  using  it  has
    terminated,  but  the  directory  is ready to receive the new
    version.


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) #