On Jun 16, 2011, at 9:31 AM, Greg Smith wrote:
-A case could be made for making some of these state fields null, instead
true or false, in situations where the session is not visible. If you don't
have rights to see the connection activity, setting idle, idle_transaction,
and active all to
On 06/15/2011 04:13 AM, Rainer Pruy wrote:
I much prefer reading an IDLE in transaction on a quick glance
over having to search a column and recognize a t from an f
to find out whether there is a transaction pending or not.
This is a fair observation. If we provide a second view here
Since the CF is upon us and discussion is settling, let's see if I can
wrap this bikeshedding up into a more concrete proposal that someone can
return to later. The ideas floating around have gelled into:
-Add a new pg_stat_sessions function that is implemented similarly to
pg_stat_activity.
On 06/15/2011 12:41 PM, Robert Haas wrote:
But I will note that we had better be darn sure to make all the changes we
want to make in one go, because I dowanna have to create pg_sessions2
(or pg_tessions?) in a year or three.
I just added a new section to the TODO to start collecting up
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Or perhaps pg_connections. Yes, +1 to making things fully backwards
compatible by keeping pg_stat_activity around but making a better
designed and better named table (view/SRF/whatever).
I thought about that too when reading the thread the
Greg Smith g...@2ndquadrant.com writes:
The only other item related to this view on the TODO was Have
pg_stat_activity display query strings in the correct client encoding.
That might be worthwhile to bundle into this rework, but it doesn't seem
something that impacts the UI such that it
--On 16. Juni 2011 15:33:35 + Greg Sabino Mullane g...@turnstep.com wrote:
No, this is clearly connections, not sessions. At least based on the items
in the postgresql.conf file, especially max_connections (probably one of the
items most closely associated with pg_stat_activity)
Well,
Tom Lane t...@sss.pgh.pa.us wrote:
The point is that another backend's entry could be in a different
*server* encoding, and what do you do if there's no equivalent
character in your encoding?
My first thought was that it was just a matter of picking a
character to represent the unprintable
Excerpts from Greg Sabino Mullane's message of jue jun 16 15:33:35 UTC 2011:
Hash: RIPEMD160
Or perhaps pg_connections. Yes, +1 to making things fully backwards
compatible by keeping pg_stat_activity around but making a better
designed and better named table (view/SRF/whatever).
I
Greg Smith wrote:
-It is still useful to set current_query to descriptive text in the
cases where the transaction is IDLE etc. That text is not ambiguous
with a real query, it is useful for a human-readable view, and it
improves the potential for pg_stat_sessions to fully replace a
On 06/16/2011 05:27 PM, Bruce Momjian wrote:
Greg Smith wrote:
-It is still useful to set current_query to descriptive text in the
cases where the transaction isIDLE etc.
Uh, if we are going to do that, why not just add the boolean columns to
the existing view? Clearly renaming
On Fri, Jun 17, 2011 at 06:39, Greg Smith g...@2ndquadrant.com wrote:
On 06/16/2011 05:27 PM, Bruce Momjian wrote:
Greg Smith wrote:
-It is still useful to set current_query to descriptive text in the
cases where the transaction isIDLE etc.
Uh, if we are going to do that, why not just
Here's the sort of thing every person who writes a monitoring tool
involving pg_stat_activity goes through:
1) Hurray! I know how to see what the database is doing now! Let me
try counting all the connections so I can finally figure out what to set
[max_connections | work_mem | other] to.
Following this whole conversation rises the impression the topic is
going to get lost in
nirvana of personal preferences.
Most suggestions on change for itself are likely to not cross the border of
not justifying a compatibility break.
I wonder, whether the actual point really is towards
On Wed, Jun 15, 2011 at 3:34 AM, Greg Smith g...@2ndquadrant.com wrote:
The whole thing is enormously frustrating, and it's an advocacy problem--it
contributes to people just starting to become serious about using PostgreSQL
lowering their opinion of its suitability for their business. If this
On Tue, Jun 14, 2011 at 9:50 PM, Bruce Momjian br...@momjian.us wrote:
Greg Smith wrote:
On 06/14/2011 06:00 PM, Tom Lane wrote:
As far as Greg's proposal is concerned, I don't see how a proposed
addition of two columns would justify renaming an existing column.
Additions should not
On Wed, Jun 15, 2011 at 8:47 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 15, 2011 at 3:34 AM, Greg Smith g...@2ndquadrant.com wrote:
The whole thing is enormously frustrating, and it's an advocacy
problem--it
contributes to people just starting to become serious about using
On 06/14/2011 08:04 PM, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
For me, the litmus test is whether the change provides enough
improvement that it outweighs the disruption when the user runs into
it.
For the procpid that started all of this, the clear
On Wed, Jun 15, 2011 at 9:44 AM, Gurjeet Singh singh.gurj...@gmail.com wrote:
Why not expose this new information as functions instead of a new view, like
we do for pg_is_in_replication(). People can use whatever alias they want in
the queries they write.
SELECT get_current_query(pid),
On Wed, Jun 15, 2011 at 10:31 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 15, 2011 at 9:44 AM, Gurjeet Singh singh.gurj...@gmail.com
wrote:
Why not expose this new information as functions instead of a new view,
like
we do for pg_is_in_replication(). People can use whatever
Gurjeet Singh singh.gurj...@gmail.com writes:
On Wed, Jun 15, 2011 at 10:31 AM, Robert Haas robertmh...@gmail.com wrote:
Well, that would probably be a lot slower, and wouldn't necessarily
deliver as consistent a snapshot of system activity. It's better to
have one set-returning function that
Excerpts from Robert Haas's message of mié jun 15 08:47:58 -0400 2011:
On Wed, Jun 15, 2011 at 3:34 AM, Greg Smith g...@2ndquadrant.com wrote:
Putting on my stability hat instead of my make it right one, maybe this
really makes sense to expose as a view with a whole new name. Make this new
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of mié jun 15 08:47:58 -0400 2011:
Now, that's a suggestion I could very possibly get behind. Though the
fact that it would leave us with pg_activity / pg_stat_replication
seems less than ideal. Maybe
On Wed, Jun 15, 2011 at 12:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of mié jun 15 08:47:58 -0400 2011:
Now, that's a suggestion I could very possibly get behind. Though the
fact that it would leave us with
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
At any rate, I like sessions. That's what it is, after all. But I
will note that we had better be darn sure to make all the changes we
want to make in one go, because I dowanna have to create pg_sessions2
(or pg_tessions?) in a year or
--On 15. Juni 2011 16:47:55 + Greg Sabino Mullane g...@turnstep.com wrote:
Or perhaps pg_connections. Yes, +1 to making things fully backwards
compatible by keeping pg_stat_activity around but making a better
designed and better named table (view/SRF/whatever).
I thought about that too
On Jun 13, 2011, at 10:56 AM, Simon Riggs wrote:
If we were going to make changes like this, I'd suggest we save them
up in a big bag for when we change major version number. Everybody in
the world thinks that PostgreSQL v8 is compatible across all versions
(8.0, 8.1, 8.2, 8.3, 8.4), and it
Jim Nasby wrote:
On Jun 13, 2011, at 10:56 AM, Simon Riggs wrote:
If we were going to make changes like this, I'd suggest we save them
up in a big bag for when we change major version number. Everybody in
the world thinks that PostgreSQL v8 is compatible across all versions
(8.0, 8.1,
On 06/14/2011 11:44 AM, Jim Nasby wrote:
Wouldn't it be better still to have both the new and old columns
available for a while? That would produce the minimum amount of
disruption to tools, etc.
Doing this presumes the existence of a large number of tools where the
author is unlikely to be
On Tue, Jun 14, 2011 at 12:25 PM, Greg Smith g...@2ndquadrant.com wrote:
Anyway, I want a larger change to pg_stat_activity than this one
Well, Simon recomended to have a big bag of changes that justify break
tools... and you have presented a good one item for that bag...
Maybe we should start
On Tue, Jun 14, 2011 at 1:43 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Tue, Jun 14, 2011 at 12:25 PM, Greg Smith g...@2ndquadrant.com wrote:
Anyway, I want a larger change to pg_stat_activity than this one
Well, Simon recomended to have a big bag of changes that justify break
Greg Smith g...@2ndquadrant.com wrote:
Doing this presumes the existence of a large number of tools where
the author is unlikely to be keeping up with PostgreSQL
development. I don't believe that theorized set of users actually
exists.
There could be a number of queries used for
On 06/14/2011 02:20 PM, Kevin Grittner wrote:
Just on our Wiki pages we have some queries available for copy/paste
which would need multiple
versions while both column names were in supported versions of the
software:
http://wiki.postgresql.org/wiki/Lock_dependency_information
Excerpts from Bruce Momjian's message of mar jun 14 12:59:15 -0400 2011:
Well, someone doing SELECT *, which is probably 90% of the users, are
going to be pretty confused by duplicate columns, asking, What is the
difference? For those people this would make things worse than they
are now.
On tis, 2011-06-14 at 13:50 -0400, Robert Haas wrote:
There are real problems with the idea of having one release where we
break everything that we want to break - mostly from a process
standpoint. We aren't always good at being organized and disciplined,
and coming up with a multi-year plan
Peter Eisentraut wrote:
On tis, 2011-06-14 at 13:50 -0400, Robert Haas wrote:
There are real problems with the idea of having one release where we
break everything that we want to break - mostly from a process
standpoint. We aren't always good at being organized and disciplined,
and
Peter Eisentraut pete...@gmx.net writes:
On tis, 2011-06-14 at 13:50 -0400, Robert Haas wrote:
There are real problems with the idea of having one release where we
break everything that we want to break - mostly from a process
standpoint. We aren't always good at being organized and
On 06/14/2011 06:00 PM, Tom Lane wrote:
As far as Greg's proposal is concerned, I don't see how a proposed
addition of two columns would justify renaming an existing column.
Additions should not break any sanely-implemented application, but
renamings certainly will.
It's not so much
Greg Smith wrote:
On 06/14/2011 06:00 PM, Tom Lane wrote:
As far as Greg's proposal is concerned, I don't see how a proposed
addition of two columns would justify renaming an existing column.
Additions should not break any sanely-implemented application, but
renamings certainly will.
On Wed, Jun 15, 2011 at 2:50 AM, Bruce Momjian br...@momjian.us wrote:
Agreed on moving 'IDLE' and 'IDLE in transaction' into separate
fields. If I had thought of it I would have done it that way years ago.
(At least I think it was me.) Using angle brackets to put magic values
in that field
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
For me, the litmus test is whether the change provides enough
improvement that it outweighs the disruption when the user runs into
it.
For the procpid that started all of this, the clear answer is no. I'm
surprised people seriously
On Tue, Jun 14, 2011 at 11:04 PM, Greg Sabino Mullane g...@turnstep.com wrote:
For me, the litmus test is whether the change provides enough
improvement that it outweighs the disruption when the user runs into
it.
For the procpid that started all of this, the clear answer is no. I'm
On Jun 11, 2011, at 9:36 PM, Robert Haas wrote:
This is at least a use-case for something^Wfeature like 'create
synonym', allowing smooth end-user's application upgrade on schema
update. I am not claiming that we need that, it just seems a good
usecase for column alias/synonym.
I had the
On Mon, Jun 13, 2011 at 11:20 AM, Jim Nasby j...@nasby.net wrote:
On Jun 11, 2011, at 9:36 PM, Robert Haas wrote:
This is at least a use-case for something^Wfeature like 'create
synonym', allowing smooth end-user's application upgrade on schema
update. I am not claiming that we need that, it
On Jun 13, 2011, at 10:22 AM, Robert Haas wrote:
A synonym feature would definitely be useful for cases like this. We have a
poorly named database at work; it's been that way for years and the only
reason it's never been cleaned up is because it would require simultaneously
changing config
On Sun, Jun 12, 2011 at 2:23 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake j...@commandprompt.com
wrote:
On 6/11/2011 1:23 PM, Bruce Momjian wrote:
There is a difference between a project name and something that directly
affects usability. +1
On Mon, Jun 13, 2011 at 11:56 AM, Simon Riggs si...@2ndquadrant.com wrote:
+1
If we were going to make changes like this, I'd suggest we save them
up in a big bag for when we change major version number. Everybody in
the world thinks that PostgreSQL v8 is compatible across all versions
(8.0,
Simon Riggs wrote:
On Sun, Jun 12, 2011 at 2:23 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake j...@commandprompt.com
wrote:
On 6/11/2011 1:23 PM, Bruce Momjian wrote:
There is a difference between a project name and something that
On lör, 2011-06-11 at 16:23 -0400, Bruce Momjian wrote:
Uh, I am the first one I remember complaining about this so I don't
see why we should break compatibility for such a low-level problem.
I complain about it every day to the wall. :)
--
Sent via pgsql-hackers mailing list
Peter Eisentraut pete...@gmx.net writes:
On lör, 2011-06-11 at 16:23 -0400, Bruce Momjian wrote:
Uh, I am the first one I remember complaining about this so I don't
see why we should break compatibility for such a low-level problem.
I complain about it every day to the wall. :)
+1 !
--
On Sat, Jun 11, 2011 at 12:02 AM, Jim Nasby j...@nasby.net wrote:
It's damn annoying... enough so that I'd personally be in favor of creating a
pid column that has the same data so we can deprecate
procpid and eventually remove it...
well, if we will start changing bad picked names we will
On 6/11/2011 1:02 AM, Jaime Casanova wrote:
On Sat, Jun 11, 2011 at 12:02 AM, Jim Nasbyj...@nasby.net wrote:
It's damn annoying... enough so that I'd personally be in favor of creating a
pid column that has the same data so we can deprecate
procpid and eventually remove it...
well, if we
Joshua D. Drake wrote:
On 6/11/2011 1:02 AM, Jaime Casanova wrote:
On Sat, Jun 11, 2011 at 12:02 AM, Jim Nasbyj...@nasby.net wrote:
It's damn annoying... enough so that I'd personally be in favor of
creating a pid column that has the same data so we can deprecate
procpid and eventually
On 6/11/2011 1:23 PM, Bruce Momjian wrote:
There is a difference between a project name and something that directly
affects usability. +1 on fixing this. IMO, we don't create a new pid
column, we just fix the problem. If we do it for 9.2, we have 18 months
to communicate the change.
Uh, I am
On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake j...@commandprompt.com wrote:
On 6/11/2011 1:23 PM, Bruce Momjian wrote:
There is a difference between a project name and something that directly
affects usability. +1 on fixing this. IMO, we don't create a new pid
column, we just fix the
2011/6/12 Robert Haas robertmh...@gmail.com:
On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake j...@commandprompt.com
wrote:
On 6/11/2011 1:23 PM, Bruce Momjian wrote:
There is a difference between a project name and something that directly
affects usability. +1 on fixing this. IMO, we don't
On Sat, Jun 11, 2011 at 9:56 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2011/6/12 Robert Haas robertmh...@gmail.com:
On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake j...@commandprompt.com
wrote:
On 6/11/2011 1:23 PM, Bruce Momjian wrote:
There is a difference between a
On Jun 9, 2011, at 11:29 AM, Robert Haas wrote:
On Thu, Jun 9, 2011 at 11:54 AM, Bruce Momjian br...@momjian.us wrote:
Can someone explain why pg_stat_activity has a column named procpid and
not simply pid? 'pid' is that pg_locks uses, and 'procpid' is redundant
(proc-process-id). A mistake?
Bruce Momjian br...@momjian.us writes:
Can someone explain why pg_stat_activity has a column named procpid and
not simply pid? 'pid' is that pg_locks uses, and 'procpid' is redundant
(proc-process-id). A mistake?
Mistake or not, it's about half a dozen releases too late to change it.
On Thu, Jun 9, 2011 at 11:54 AM, Bruce Momjian br...@momjian.us wrote:
Can someone explain why pg_stat_activity has a column named procpid and
not simply pid? 'pid' is that pg_locks uses, and 'procpid' is redundant
(proc-process-id). A mistake?
Well, we refer to the slots that backends use
Robert Haas wrote:
On Thu, Jun 9, 2011 at 11:54 AM, Bruce Momjian br...@momjian.us wrote:
Can someone explain why pg_stat_activity has a column named procpid and
not simply pid? ?'pid' is that pg_locks uses, and 'procpid' is redundant
(proc-process-id). ?A mistake?
Well, we refer to the
61 matches
Mail list logo
