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
On Fri, Jun 17, 2011 at 06:39, Greg Smith 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 is etc.
>>>
>>
>> Uh, if we are going to do that, why not just add
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 is etc.
Uh, if we are going to do that, why not just add the boolean columns to
the existing view? Clearly renaming procpid
Greg Smith wrote:
> -It is still useful to set current_query to descriptive text in the
> cases where the transaction is 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
> depre
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/whateve
Tom Lane 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" characters. M
--On 16. Juni 2011 15:33:35 + Greg Sabino Mullane 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, but it doesn't show
Greg Smith 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 must be consider
-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 thre
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 som
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 04:13 AM, Rainer Pruy wrote:
I much prefer reading an " 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 th
--On 15. Juni 2011 16:47:55 + Greg Sabino Mullane 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 when reading the t
-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
On Wed, Jun 15, 2011 at 12:13 PM, Tom Lane wrote:
> Alvaro Herrera 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
>>
Alvaro Herrera 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 pg_activity isn't the be
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 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
> > one pg_act
Gurjeet Singh writes:
> On Wed, Jun 15, 2011 at 10:31 AM, Robert Haas 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 dumps out all the data in a
>> single
On Wed, Jun 15, 2011 at 10:31 AM, Robert Haas wrote:
> On Wed, Jun 15, 2011 at 9:44 AM, Gurjeet Singh
> 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 the
On Wed, Jun 15, 2011 at 9:44 AM, Gurjeet Singh 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), is_idle(pid), is_idle_in_
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 ans
On Wed, Jun 15, 2011 at 8:47 AM, Robert Haas wrote:
> On Wed, Jun 15, 2011 at 3:34 AM, Greg Smith 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
On Tue, Jun 14, 2011 at 9:50 PM, Bruce Momjian 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 break
On Wed, Jun 15, 2011 at 3:34 AM, Greg Smith 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 is
> what's inclu
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 compati
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.
2)
On Tue, Jun 14, 2011 at 11:04 PM, Greg Sabino Mullane 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
> surprised people
-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 con
On Wed, Jun 15, 2011 at 2:50 AM, Bruce Momjian wrote:
> Agreed on moving '' and ' 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 was clearly wrong.
I
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 wi
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 justifi
Peter Eisentraut 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 disciplined,
>> an
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,
> >
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 pl
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 no
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
http://wiki.postg
Greg Smith 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 monitoring or
administrati
On Tue, Jun 14, 2011 at 1:43 PM, Jaime Casanova wrote:
> On Tue, Jun 14, 2011 at 12:25 PM, Greg Smith 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 o
On Tue, Jun 14, 2011 at 12:25 PM, Greg Smith 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 a wiki page for thi
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 k
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,
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
Simon Riggs wrote:
> On Sun, Jun 12, 2011 at 2:23 AM, Robert Haas wrote:
> > On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake
> > 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.
On Mon, Jun 13, 2011 at 11:56 AM, Simon Riggs 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, 8.1, 8.2, 8.3,
On Sun, Jun 12, 2011 at 2:23 AM, Robert Haas wrote:
> On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake
> 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 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
On Mon, Jun 13, 2011 at 11:20 AM, Jim Nasby 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 just s
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 h
Peter Eisentraut 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 !
--
Dimitri Font
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 (pgsql-hacker
On Sat, Jun 11, 2011 at 9:56 PM, Cédric Villemain
wrote:
> 2011/6/12 Robert Haas :
>> On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake
>> wrote:
>>> On 6/11/2011 1:23 PM, Bruce Momjian wrote:
> There is a difference between a project name and something that directly
> affects usabil
2011/6/12 Robert Haas :
> On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake
> 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
On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake 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 problem. If we d
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 t
Joshua D. Drake wrote:
> On 6/11/2011 1:02 AM, Jaime Casanova wrote:
> > On Sat, Jun 11, 2011 at 12:02 AM, Jim Nasby 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 rem
On 6/11/2011 1:02 AM, Jaime Casanova wrote:
On Sat, Jun 11, 2011 at 12:02 AM, Jim Nasby 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 changin
On Sat, Jun 11, 2011 at 12:02 AM, Jim Nasby 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 have a *lot*
On Jun 9, 2011, at 11:29 AM, Robert Haas wrote:
> On Thu, Jun 9, 2011 at 11:54 AM, Bruce Momjian 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
Robert Haas wrote:
> On Thu, Jun 9, 2011 at 11:54 AM, Bruce Momjian 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 th
On Thu, Jun 9, 2011 at 11:54 AM, Bruce Momjian 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 as "procs" (rea
Bruce Momjian 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.
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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It'
62 matches
Mail list logo
