| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | arun chirappurath <arunsnmimt(at)gmail(dot)com> |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pg_locks-exclusivelock for select queries |
| Date: | 2024-03-22 14:18:50 |
| Message-ID: | 899843.1711117130@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
arun chirappurath <arunsnmimt(at)gmail(dot)com> writes:
> I am running below query on a database. why is it creating a exclusive lock
> on a virtualxid? I am running some SELECT queries and its creating an
> ExclusiveLock in virtualxid? is this normal?
Yes. That lock has nothing to do with any table, only with the
transaction's own existence. It can't conflict when acquired,
because the virtual XID is unique (at least across existing sessions).
It exists so that other sessions can wait for this one if needful, by
trying to take share lock on the virtualxid.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2024-03-22 14:47:39 | Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs |
| Previous Message | Nick Renders | 2024-03-22 14:01:04 | Re: could not open file "global/pg_filenode.map": Operation not permitted |