Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire - Mailing list pgsql-hackers

From Christian Kruse
Subject Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire
Date
Msg-id 20140203115352.GB14043@defunct.ch
Whole thread Raw
In response to Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
Hi Simon,

On 03/02/14 10:43, Simon Riggs wrote:
> > Singular:
> > "The following process is holding the lock: A. The request queue
> > consists of: B."
> >
> > Plural:
> > "Following processes are holding the lock: A, B. The request queue
> > consists of: C."
>
> Seems too complex. How about this...
>
> "Lock holder(s): A. Lock waiter(s) B"
> "Lock holder(s): A, B. Lock waiter(s) C"

This is basically the same as before, it is even shorter. The
complaint was that I don't use a whole sentence in this error
detail. Won't the change fulfill the same complaint?

To be honest, I'd like to stick with your earlier proposal:

Singular:
Process holding the lock: A. Request queue: B

Plural:
Processes holding the lock: A, B. Request queue: C, D

This seems to be a good trade-off between project guidelines,
readability and parsability.

Best regards,

-- Christian Kruse               http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Christian Kruse
Date:
Subject: Re: Patch: show xid and xmin in pg_stat_activity and pg_stat_replication
Next
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Include planning time in EXPLAIN ANALYZE output.