--
me at github: https://github.com/radiospiel
me at linked.in: https://www.linkedin.com/in/radiospiel
You probably considered this but the queuing mechanism I use
doesn't hold
locks on records during processing. Workers claim tasks by locking
them,
setting a claimed flag of some sort, th
On Fri, Mar 16, 2018 at 8:00 AM, Enrico Thierbach wrote:
> Hi Melvin, Stephen, hi list,
>
> *FWIW, I really don't understand your need to identify the actual rows that
> are locked. Once you have identified the query that is causing a block
> (which is usually due to "Idle in Transaction"), AFAIK
Thanks Steven,
Evidently my second email got lost somewhere along the way- what
you're
looking for is an extension called 'pgrowlocks':
https://www.postgresql.org/docs/10/static/pgrowlocks.html
My prior email on that subject is here:
https://www.postgresql.org/message-id/20180315220512.GV241
Enrico,
* Enrico Thierbach (e...@open-lab.org) wrote:
> >*FWIW, I really don't understand your need to identify the actual rows
> >that
> >are locked. Once you have identified the query that is causing a block
> >(which is usually due to "Idle in Transaction"), AFAIK the only way to
> >remedy the
Hi Melvin, Stephen, hi list,
*FWIW, I really don't understand your need to identify the actual rows
that
are locked. Once you have identified the query that is causing a block
(which is usually due to "Idle in Transaction"), AFAIK the only way to
remedy the problem is to kill the offending quer
Greetings,
Please don't top-post.
* Melvin Davidson (melvin6...@gmail.com) wrote:
> this whole discussion started because Enrico did not originally specify the
> PostgreSQL version he was working with. So after he did advise it was for
> 9.6, I felt it necessary to explain to him why a certain se
Tom,
this whole discussion started because Enrico did not originally specify the
PostgreSQL version he was working with. So after he did advise it was for
9.6, I felt it necessary to explain to him why a certain section of my
query was commented out and that it would also work for 10. I have
previo
Melvin Davidson writes:
> Yes, Stephen, I certainly understand making changes to system catalogs
> _when necessary_. That being said, the first change was the renaming of
> pid to procpid in pg_stat_activity. However, I contend that was more
> because someone felt that it was more to make the co
Greetings Melvin,
* Melvin Davidson (melvin6...@gmail.com) wrote:
> On Thu, Mar 15, 2018 at 10:14 PM, Stephen Frost wrote:
> > Changes will continue to be made between major versions of PostgreSQL
> > when they're deemed necessary; I'd suggest those applications be
> > prepared to adjust on a per
On Thu, Mar 15, 2018 at 10:14 PM, Stephen Frost wrote:
> Greetings Melvin,
>
> * Melvin Davidson (melvin6...@gmail.com) wrote:
> > >I guess with your query I can figure out which connection holds a lock,
> > but it seems I cannot correlate those locks to the rows which actually
> are
> > locked,
Greetings Melvin,
* Melvin Davidson (melvin6...@gmail.com) wrote:
> >I guess with your query I can figure out which connection holds a lock,
> but it seems I cannot correlate those locks to the rows which actually are
> locked, since pg_locks seems not to reference this in any way.
>
> *FWIW, I r
>I guess with your query I can figure out which connection holds a lock,
but it seems I cannot correlate those locks to the rows which actually are
locked, since pg_locks seems not to reference this in any way.
*Enrico,*
*FWIW, I really don't understand your need to identify the actual rows t
Greetnigs,
* Enrico Thierbach (e...@open-lab.org) wrote:
> I guess with your query I can figure out which connection holds a lock, but
> it seems I cannot correlate those locks to the rows which actually are
> locked, since `pg_locks` seems not to reference this in any way.
What I gave you would
Hi Melvin, hi everyone else,
thank you for your support, and for your query example. And oh yes, I
forgot to mention the postgres version, which is 9.6; but if I find a
solution which works in Version 10 then I could probably update.
I guess with your query I can figure out which connection h
On Thu, Mar 15, 2018 at 4:48 PM, Stephen Frost wrote:
> Greetings,
>
> * Enrico Thierbach (e...@open-lab.org) wrote:
> > I am using `SELECT * FROM queue ... FOR UPDATE SKIP LOCKED` to implement
> a
> > queueing system.
> >
> > Now I wonder if it is possible, given the id of one of the locked rows
Greetings,
* Enrico Thierbach (e...@open-lab.org) wrote:
> I am using `SELECT * FROM queue ... FOR UPDATE SKIP LOCKED` to implement a
> queueing system.
>
> Now I wonder if it is possible, given the id of one of the locked rows in
> the queue table, to find out which connection/which transaction
On Thu, Mar 15, 2018 at 1:30 PM, Enrico Thierbach wrote:
> Now I wonder if it is possible, given the id of one of the locked rows in
> the queue table, to find out which connection/which transaction owns the
> lock
>
I'd start here:
https://www.postgresql.org/docs/10/static/view-pg-locks.html
Check out here: https://wiki.postgresql.org/wiki/Lock_Monitoring
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
Hello,
I am using `SELECT * FROM queue ... FOR UPDATE SKIP LOCKED` to implement
a queueing system.
Now I wonder if it is possible, given the id of one of the locked rows
in the queue table, to find out which connection/which transaction owns
the lock.
Any help is greatly appreciated.
Than
19 matches
Mail list logo
