Thread: updated lock listing patch
This patch is an updated version of the lock listing patch. I've made
the following changes:
- write documentation
- wrap the SRF in a view called 'pg_locks': all user-level
access should be done through this view
- re-diff against latest CVS
One thing I chose not to do is adapt the SRF to use the anonymous
composite type code from Joe Conway. I'll probably do that eventually,
but I'm not really convinced it's a significantly cleaner way to
bootstrap SRF builtins than the method this patch uses (of course, it
has other uses...)
In any case, I'd view that as a janitorial issue that can be resolved
after this patch is in CVS.
Unless anyone has any objections, please apply.
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
Attachment
Neil Conway <nconway@klamath.dyndns.org> writes: > This patch is an updated version of the lock listing patch. Woops, that patch was half-baked -- the changes to the regression tests were only partially included (thanks to Alvaro Herrera for pointing that out). I've attached an updated patch. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Attachment
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Neil Conway wrote:
> Neil Conway <nconway@klamath.dyndns.org> writes:
> > This patch is an updated version of the lock listing patch.
>
> Woops, that patch was half-baked -- the changes to the regression
> tests were only partially included (thanks to Alvaro Herrera for
> pointing that out). I've attached an updated patch.
>
> Cheers,
>
> Neil
>
> --
> Neil Conway <neilconway@rogers.com>
> PGP Key ID: DB3C29FC
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Patch applied. Thanks. --------------------------------------------------------------------------- Neil Conway wrote: > Neil Conway <nconway@klamath.dyndns.org> writes: > > This patch is an updated version of the lock listing patch. > > Woops, that patch was half-baked -- the changes to the regression > tests were only partially included (thanks to Alvaro Herrera for > pointing that out). I've attached an updated patch. > > Cheers, > > Neil > > -- > Neil Conway <neilconway@rogers.com> > PGP Key ID: DB3C29FC [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
I am confused by pg_locks_result. I see it in \dS, but it doesn't
appear to display anything useful, based on the view definition. Is
this the cleanup you were talking about, Neil?
---------------------------------------------------------------------------
test=> \d+ pg_locks
View "pg_catalog.pg_locks"
Column | Type | Modifiers | Description
------------+---------+-----------+-------------
relation | oid | |
database | oid | |
backendpid | integer | |
mode | text | |
isgranted | boolean | |
View definition: SELECT pg_lock_status.relation,
pg_lock_status."database", pg_lock_status.backendpid,
pg_lock_status."mode", pg_lock_status.isgranted FROM pg_lock_status();
test=> \d+ pg_locks_result
View "pg_catalog.pg_locks_result"
Column | Type | Modifiers | Description
------------+---------+-----------+-------------
relation | oid | |
database | oid | |
backendpid | integer | |
mode | text | |
isgranted | boolean | |
View definition: SELECT 0::oid AS relation, 0::oid AS "database", 0 AS
backendpid, ''::text AS "mode", NULL::boolean AS isgranted;
---------------------------------------------------------------------------
Bruce Momjian wrote:
>
> Patch applied. Thanks.
>
> ---------------------------------------------------------------------------
>
>
> Neil Conway wrote:
> > Neil Conway <nconway@klamath.dyndns.org> writes:
> > > This patch is an updated version of the lock listing patch.
> >
> > Woops, that patch was half-baked -- the changes to the regression
> > tests were only partially included (thanks to Alvaro Herrera for
> > pointing that out). I've attached an updated patch.
> >
> > Cheers,
> >
> > Neil
> >
> > --
> > Neil Conway <neilconway@rogers.com>
> > PGP Key ID: DB3C29FC
>
> [ Attachment, skipping... ]
>
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes: > I am confused by pg_locks_result. I see it in \dS, but it doesn't > appear to display anything useful, based on the view definition. Is > this the cleanup you were talking about, Neil? Yes, it is. Hopefully I'll get to that before the beta (if I don't, it's something that could go in during a beta cycle, IMHO). The code is fully functional, it's just that the additional view can be done away with. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Neil Conway <nconway@klamath.dyndns.org> writes:
> Yes, it is. Hopefully I'll get to that before the beta (if I don't,
> it's something that could go in during a beta cycle, IMHO).
> The code is fully functional, it's just that the additional view can
> be done away with.
Please get it done before beta. Removing the view presumably means an
initdb, and we prefer to avoid those after start of beta. (Sometimes
they're unavoidable, but this one isn't.)
regards, tom lane
Tom Lane wrote: > Neil Conway <nconway@klamath.dyndns.org> writes: > > Yes, it is. Hopefully I'll get to that before the beta (if I don't, > > it's something that could go in during a beta cycle, IMHO). > > The code is fully functional, it's just that the additional view can > > be done away with. > > Please get it done before beta. Removing the view presumably means an > initdb, and we prefer to avoid those after start of beta. (Sometimes > they're unavoidable, but this one isn't.) Yes, unless we had another reason to initdb during beta, it would just stay in there for 7.3 and be removed in 7.4. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073