FYI, advisory locks of PostgreSQL are working pretty well on production
since one month now.
Thanks again for your help.
Ludovic Gasc (GMLudo)
2018-04-18 7:09 GMT+02:00 Ludovic Gasc :
> Indeed, thanks for the suggestion :-)
> Le mer. 18 avr. 2018 à 01:21, Nathaniel Smith
Indeed, thanks for the suggestion :-)
Le mer. 18 avr. 2018 à 01:21, Nathaniel Smith a écrit :
> Pretty sure you want to add a try/finally around that yield, so you
> release the lock on errors.
> On Tue, Apr 17, 2018, 14:39 Ludovic Gasc wrote:
Pretty sure you want to add a try/finally around that yield, so you release
the lock on errors.
On Tue, Apr 17, 2018, 14:39 Ludovic Gasc wrote:
> 2018-04-17 15:16 GMT+02:00 Antoine Pitrou :
>> You could simply use something like the first 64 bits
2018-04-17 15:16 GMT+02:00 Antoine Pitrou :
> You could simply use something like the first 64 bits of
I have followed your idea, except I used hashtext directly, it's an
internal postgresql function that generates an integer directly.
For now, it
You could simply use something like the first 64 bits of
On Tue, 17 Apr 2018 15:04:37 +0200
Ludovic Gasc wrote:
> Hi Antoine & Chris,
> Thanks a lot for the advisory lock, I didn't know this feature in
> Indeed, it seems to
Thanks for your time and explanations :-)
However, I have the intuition that it will take me more time to implement
your idea compare to the builtin feature of PostgreSQL.
Nevertheless, I keep your idea in mind in case of I have problems with
Have a nice day.
I believe it's relatively straightforward to implement the core
functionality, if you can at first reduce it to:
* allow only one coro to wait on lock at a given time (i.e. one user
per process / event loop)
* decide explicitly if you want other coros to continue (I assume so,
I'm looking for a equivalent of asyncio.Lock (
shared between several processes on the same server, because I'm migrating
a daemon from mono-worker to multi-worker pattern.
For now, the closest solution in term of API