From: | Shreeyansh Dba <shreeyansh2014(at)gmail(dot)com> |
---|---|
To: | Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)com> |
Cc: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>, PostgreSQL mailing lists <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: pg_locks - what is a virtualxid locktype |
Date: | 2019-01-29 09:33:17 |
Message-ID: | CAGDYbUP6O3uhe=X2m5VPVj-Z3a5_Dh+WtZPJYTMud0h+NKW72A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-performance |
The virtualxid lock is special. It’s a exclusive lock on the transaction’s
own virtual transaction ID that every transaction always holds. No other
transaction can ever acquire it while the transaction is running.
The purpose of this is to allow one transaction to wait until another
transaction commits or rolls back using PostgreSQL’s locking mechanism, and
it’s used internally.
Thanks & Regards,
*Shreeyansh DBA Team*
www.shreeyansh.com
On Tue, Jan 29, 2019 at 2:27 PM Mariel Cherkassky <
mariel(dot)cherkassky(at)gmail(dot)com> wrote:
> Hey,
> I noticed that pg_locks has an addition row for every transaction that is
> created with a locktype "virtualxid". Tried to search it online but I didnt
> find an explanation for this behavior. Does anyone can explain why it
> happens ?
>
From | Date | Subject | |
---|---|---|---|
Next Message | Shreeyansh Dba | 2019-01-29 09:35:17 | Re: : : How to mask column: : |
Previous Message | Mariel Cherkassky | 2019-01-29 08:57:11 | pg_locks - what is a virtualxid locktype |
From | Date | Subject | |
---|---|---|---|
Next Message | Fabio Isabettini | 2019-01-29 11:32:47 | Re: dsa_allocate() faliure |
Previous Message | Nicolas Charles | 2019-01-29 09:14:13 | Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"? |