Thread: Re: [HACKERS] please?

Re: [HACKERS] please?

From
Bruce Momjian
Date:
> Bruce Momjian wrote:
> > Sharing file systems.  Good point.  You could have a table you use to
> > lock.  Lock the table, view the value, possibly modify, and unlock.
> > This does not handle the case where someone died and did not remove
> > their entry from the lock table.
> 
> You can always write the modification time to the table as well and if 
> it's "too old", then try to override it.
> 

Assuming you can set a reasonable "too old" time. 

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


Re: [HACKERS] please?

From
Pablo Funes
Date:
>
> > Bruce Momjian wrote:
> > > Sharing file systems.  Good point.  You could have a table you use to
> > > lock.  Lock the table, view the value, possibly modify, and unlock.
> > > This does not handle the case where someone died and did not remove
> > > their entry from the lock table.
> >
> > You can always write the modification time to the table as well and if
> > it's "too old", then try to override it.
> >
>
> Assuming you can set a reasonable "too old" time.
>

There may be many partial workarounds, depending on the
application, but there seems to be no robust way to have
a failed lock right now. Perhaps in a future version will
PQrequestCancel be able to terminate a waiting-for-lock
state?

Pablo

Re: [HACKERS] please?

From
Tom Lane
Date:
Pablo Funes <pablo@cs.brandeis.edu> writes:
> Perhaps in a future version will PQrequestCancel be able to terminate
> a waiting-for-lock state?

Seems like a reasonable suggestion.  It's too late to consider this for
6.5 (we were supposed to freeze the feature list quite a while back)
but I support putting it on the TODO list for a future release.
        regards, tom lane


Re: [HACKERS] please?

From
Bruce Momjian
Date:
> Pablo Funes <pablo@cs.brandeis.edu> writes:
> > Perhaps in a future version will PQrequestCancel be able to terminate
> > a waiting-for-lock state?
> 
> Seems like a reasonable suggestion.  It's too late to consider this for
> 6.5 (we were supposed to freeze the feature list quite a while back)
> but I support putting it on the TODO list for a future release.
> 
>             regards, tom lane
> 

Added:
* Allow PQrequestCancel() to terminate when in waiting-for-lock state

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


Re: [HACKERS] please?

From
Pablo Funes
Date:
Cool! :-)

>
> > Pablo Funes <pablo@cs.brandeis.edu> writes:
> > > Perhaps in a future version will PQrequestCancel be able to terminate
> > > a waiting-for-lock state?
> >
> > Seems like a reasonable suggestion.  It's too late to consider this for
> > 6.5 (we were supposed to freeze the feature list quite a while back)
> > but I support putting it on the TODO list for a future release.
> >
> >             regards, tom lane
> >
>
> Added:
>
>     * Allow PQrequestCancel() to terminate when in waiting-for-lock state
>

Re: [HACKERS] please?

From
Bruce Momjian
Date:
Added to TODO:
* PQrequestCancel() be able to terminate backend waiting for lock

> Pablo Funes <pablo@cs.brandeis.edu> writes:
> > Perhaps in a future version will PQrequestCancel be able to terminate
> > a waiting-for-lock state?
> 
> Seems like a reasonable suggestion.  It's too late to consider this for
> 6.5 (we were supposed to freeze the feature list quite a while back)
> but I support putting it on the TODO list for a future release.
> 
>             regards, tom lane
> 


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