Re: [HACKERS] please?

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] please?
Дата
Msg-id 199905311743.NAA23066@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] please?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] please?  (Pablo Funes <pablo@cs.brandeis.edu>)
Список pgsql-hackers
> A possible approach is for your clients to maintain more than one
> backend connection, and use one of the backends to do the stuff 
> that might block while using another one to do the stuff that won't.
> This would take a little more bookkeeping in the client but it seems
> like a logically cleaner way to think about it.

Or you could do it outside of the database using a Unix filesystem lock
file.  There are symantics for no-blocking lock stuff in flock():
          #define LOCK_SH 0x01    /* shared file lock */          #define LOCK_EX 0x02    /* exclusive file lock */
    #define LOCK_NB 0x04    /* don't block when locking */          #define LOCK_UN 0x08    /* unlock file */
 

I don't know of any SQL databases that allow non-blocking lock requests.


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] please?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Open 6.5 items