pg_locks column names

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: pg_locks column names
Date: 2005-06-18 20:10:04
Message-ID: 4176.1119125404@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

In a moment of sheer brain fade I wrote:
> Log Message:
> -----------
> Add a time-of-preparation column to the pg_prepared_xacts view, per an
> old suggestion by Oliver Jowett. Also, add a transaction column to the
> pg_locks view to show the xid of each transaction holding or awaiting
> locks; this allows prepared transactions to be properly associated with
> the locks they own. There was already a column named 'transaction',
> and I chose to rename it to 'transactionid' --- since this column is
> new in the current devel cycle there should be no backwards compatibility
> issue to worry about.

But of course the transaction column of pg_locks is *not* new; I was
momentarily confusing it with the ones that did get added recently.
So this needs reconsideration.

We need a column to identify the transaction holding/awaiting the lock,
as well as one for the identity of a lock taken on a transaction ID.

In a green field, I think the names I used in the patch would be good
("transaction" and "transactionid" respectively). The best backward-
compatible names I can think of are "xid" and "transaction", which
aren't very attractive. Any better ideas? How important do you think
it is to preserve the column name of this pg_locks column?

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2005-06-18 20:51:31 pgsql: When using C-string lookup keys in a dynahash.c hash table, use
Previous Message Tom Lane 2005-06-18 19:33:43 pgsql: Add a time-of-preparation column to the pg_prepared_xacts view,

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-06-18 20:38:29 Re: Checkpointing problem with new buffer mgr.
Previous Message Greg Stark 2005-06-18 19:44:12 Re: Utility database (Was: RE: Autovacuum in the backend)