| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Shreeyansh Dba <shreeyansh2014(at)gmail(dot)com> |
| Cc: | Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)com>, 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 15:12:18 |
| Message-ID: | 201901291512.n532mfd7od4x@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-performance |
On 2019-Jan-29, Shreeyansh Dba wrote:
> 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.
A little more specific than that: it's used when some process (such as
CREATE INDEX CONCURRENTLY) needs to wait even on sessions that might be
read-only. Such transactions don't have transaction-ids that write
transactions have, which is why the only way is to wait on the virtual
transaction-id.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shreeyansh Dba | 2019-01-29 15:30:46 | Re: import tablespaces from oracle to postgres |
| Previous Message | Pepe TD Vo | 2019-01-29 14:44:05 | Re: import tablespaces from oracle to postgres |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2019-01-29 15:42:12 | Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"? |
| Previous Message | Andrew Gierth | 2019-01-29 13:07:03 | Re: Interpreting shared_buffers setting |