On Thu, Jan 19, 2012 at 15:42, Fujii Masao wrote:
> On Thu, Jan 19, 2012 at 10:31 PM, Magnus Hagander wrote:
>> Applied with fairly extensive modifications. I moved things around,
>> switched to using enum instead of int+#define and a few things like
>> that. Also changed most of the markup in th
On Thu, Jan 19, 2012 at 10:31 PM, Magnus Hagander wrote:
> Applied with fairly extensive modifications. I moved things around,
> switched to using enum instead of int+#define and a few things like
> that. Also changed most of the markup in the docs - I may well have
> broken some previously good l
On Wed, Jan 18, 2012 at 16:35, Scott Mead wrote:
>
> On Wed, Jan 18, 2012 at 8:27 AM, Magnus Hagander
> wrote:
>>
>> On Tue, Jan 17, 2012 at 01:43, Scott Mead wrote:
>> >
>> >
>> > On Mon, Jan 16, 2012 at 6:10 PM, Scott Mead wrote:
>> >>
>> >>
>> >> On Sun, Jan 15, 2012 at 4:28 AM, Greg Smith
On Wed, Jan 18, 2012 at 8:27 AM, Magnus Hagander wrote:
> On Tue, Jan 17, 2012 at 01:43, Scott Mead wrote:
> >
> >
> > On Mon, Jan 16, 2012 at 6:10 PM, Scott Mead wrote:
> >>
> >>
> >> On Sun, Jan 15, 2012 at 4:28 AM, Greg Smith
> wrote:
> >>>
> >>> On 01/12/2012 11:57 AM, Scott Mead wrote:
> >
On Tue, Jan 17, 2012 at 01:43, Scott Mead wrote:
>
>
> On Mon, Jan 16, 2012 at 6:10 PM, Scott Mead wrote:
>>
>>
>> On Sun, Jan 15, 2012 at 4:28 AM, Greg Smith wrote:
>>>
>>> On 01/12/2012 11:57 AM, Scott Mead wrote:
Pretty delayed, but please find the attached patch that addresses all
On Sun, Jan 15, 2012 at 4:28 AM, Greg Smith wrote:
> On 01/12/2012 11:57 AM, Scott Mead wrote:
>
>> Pretty delayed, but please find the attached patch that addresses all the
>> issues discussed.
>>
>
> The docs on this v4 look like they suffered a patch order problem here.
> In the v3, you added
On 01/12/2012 11:57 AM, Scott Mead wrote:
Pretty delayed, but please find the attached patch that addresses all
the issues discussed.
The docs on this v4 look like they suffered a patch order problem here.
In the v3, you added a whole table describing the pg_stat_activity
documentation in mo
On Thu, Dec 15, 2011 at 12:10 PM, Magnus Hagander wrote:
> On Thu, Dec 15, 2011 at 13:18, Greg Smith wrote:
> > This patch seems closing in on being done, but it's surely going to take
> at
> > least one more round of review to make sure all the naming and
> documentation
> > is up right. I can
On Thu, Dec 15, 2011 at 13:18, Greg Smith wrote:
> This patch seems closing in on being done, but it's surely going to take at
> least one more round of review to make sure all the naming and documentation
> is up right. I can work on that again whenever Scott gets another version
> necessary, an
This patch seems closing in on being done, but it's surely going to take
at least one more round of review to make sure all the naming and
documentation is up right. I can work on that again whenever Scott gets
another version necessary, and Magnus is already poking around with an
eye toward p
On Wed, Dec 7, 2011 at 17:45, Scott Mead wrote:
>
> On Tue, Dec 6, 2011 at 6:38 AM, Magnus Hagander wrote:
>>
>> On Sat, Nov 19, 2011 at 02:55, Scott Mead wrote:
>> >
>> > On Thu, Nov 17, 2011 at 11:58 AM, Scott Mead wrote:
>> >>
>> >> On Wed, Nov 16, 2011 at 4:09 PM, Scott Mead wrote:
>> >>>
On Tue, Dec 6, 2011 at 6:38 AM, Magnus Hagander wrote:
> On Sat, Nov 19, 2011 at 02:55, Scott Mead wrote:
> >
> > On Thu, Nov 17, 2011 at 11:58 AM, Scott Mead wrote:
> >>
> >> On Wed, Nov 16, 2011 at 4:09 PM, Scott Mead wrote:
> >>>
> >>>
> >>>
> >>> On Tue, Nov 15, 2011 at 1:18 PM, Robert Tre
On Sat, Nov 19, 2011 at 02:55, Scott Mead wrote:
>
> On Thu, Nov 17, 2011 at 11:58 AM, Scott Mead wrote:
>>
>> On Wed, Nov 16, 2011 at 4:09 PM, Scott Mead wrote:
>>>
>>>
>>>
>>> On Tue, Nov 15, 2011 at 1:18 PM, Robert Treat wrote:
On Tue, Nov 15, 2011 at 12:00 PM, Greg Smith
wro
On Wed, Nov 16, 2011 at 4:09 PM, Scott Mead wrote:
>
>
> On Tue, Nov 15, 2011 at 1:18 PM, Robert Treat wrote:
>
>> On Tue, Nov 15, 2011 at 12:00 PM, Greg Smith
>> wrote:
>> > On 11/15/2011 09:44 AM, Scott Mead wrote:
>> >>
>> >> Fell off the map last week, here's v2 that:
>> >> * RUNNING => ac
On Tue, Nov 15, 2011 at 1:18 PM, Robert Treat wrote:
> On Tue, Nov 15, 2011 at 12:00 PM, Greg Smith wrote:
> > On 11/15/2011 09:44 AM, Scott Mead wrote:
> >>
> >> Fell off the map last week, here's v2 that:
> >> * RUNNING => active
> >> * all states from CAPS to lower case
> >>
> >
> > This lo
On Tue, Nov 15, 2011 at 12:00 PM, Greg Smith wrote:
> On 11/15/2011 09:44 AM, Scott Mead wrote:
>>
>> Fell off the map last week, here's v2 that:
>> * RUNNING => active
>> * all states from CAPS to lower case
>>
>
> This looks like what I was hoping someone would add here now. Patch looks
> goo
On 11/15/2011 09:44 AM, Scott Mead wrote:
Fell off the map last week, here's v2 that:
* RUNNING => active
* all states from CAPS to lower case
This looks like what I was hoping someone would add here now. Patch
looks good, only issue I noticed was a spaces instead of a tab goof
where you
On Thu, Nov 10, 2011 at 2:49 PM, Tom Lane wrote:
> Bruce Momjian writes:
> > Well, we could use an optional "details" string for that. If not, we
> > are still using the magic-string approach, which I thought we didn't
> > like.
>
> No, we're not using magic strings, we're using an enum --- may
Bruce Momjian writes:
> Well, we could use an optional "details" string for that. If not, we
> are still using the magic-string approach, which I thought we didn't
> like.
No, we're not using magic strings, we're using an enum --- maybe not an
officially declared enum type, but it's a column wit
Tom Lane wrote:
> Bruce Momjian writes:
> > It might be cleaner to use booleans:
> > active: t/f
> > in transaction: t/f
>
> I don't think so, because that makes some very strict assumptions that
> there are exactly four interesting states (an assumption that isn't
> even true tod
Bruce Momjian writes:
> It might be cleaner to use booleans:
> active: t/f
> in transaction: t/f
I don't think so, because that makes some very strict assumptions that
there are exactly four interesting states (an assumption that isn't
even true today, to judge by the activity
Scott Mead wrote:
> On Wed, Nov 2, 2011 at 4:12 AM, Albe Laurenz wrote:
>
> > Andrew Dunstan wrote:
> > > On 11/01/2011 09:52 AM, Tom Lane wrote:
> > >> I'm for just redefining the query field as "current or last
> > >> query".
> > >
> > > +1
> > >
> > >> I could go either way on whether to rename
On Nov 5, 2011 9:02 AM, "Greg Smith" wrote:
>
> On 11/04/2011 05:01 PM, Tom Lane wrote:
>>
>> Scott Mead writes:
>>
>>>
>>>I leave the waiting flag in place for posterity. With this in mind,
is
>>> the consensus:
>>>RUNNING
>>> or
>>>ACTIVE
>>>
>>
>> Personally, I'd go for lower
On 11/04/2011 05:01 PM, Tom Lane wrote:
Scott Mead writes:
I leave the waiting flag in place for posterity. With this in mind, is
the consensus:
RUNNING
or
ACTIVE
Personally, I'd go for lower case.
I was thinking it would be nice if this state looked like the
On Fri, Nov 4, 2011 at 10:34 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> I guess with the changes that showed different thing like fastpath,
>> that makes sense. But if we just mapped the states that are there
>> today straight off, is there any case where waiting can be true, when
>> we're
On Fri, Nov 4, 2011 at 3:28 PM, Robert Haas wrote:
> On Fri, Nov 4, 2011 at 2:46 PM, Scott Mead wrote:
>> If waiting == true, then state = WAITING
>> else
>> state = appropriate state
>
> No, I think the state and waiting columns should be completely independent.
>
If they aren't I do
On Fri, Nov 4, 2011 at 2:46 PM, Scott Mead wrote:
> If waiting == true, then state = WAITING
> else
> state = appropriate state
No, I think the state and waiting columns should be completely independent.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreS
Scott Mead writes:
>I leave the waiting flag in place for posterity. With this in mind, is
> the consensus:
>RUNNING
> or
>ACTIVE
Personally, I'd go for lower case.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Fri, Nov 4, 2011 at 2:31 PM, Robert Haas wrote:
> On Fri, Nov 4, 2011 at 2:28 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> Maybe there's a better term than "running", like "in progress" or
> >> something of that sort.
> >
> > "active"?
>
> +1.
>
>Letting this one 'poll' a bit more be
On Fri, Nov 4, 2011 at 2:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> Maybe there's a better term than "running", like "in progress" or
>> something of that sort.
>
> "active"?
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql
Robert Haas writes:
> Maybe there's a better term than "running", like "in progress" or
> something of that sort.
"active"?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
On Fri, Nov 4, 2011 at 12:46 PM, Marti Raudsepp wrote:
> On Fri, Nov 4, 2011 at 15:42, Tom Lane wrote:
>> Marti Raudsepp writes:
>>> While we're already breaking everything, we could remove the "waiting"
>>> column and use a state with value 'waiting' instead.
>
>> -1 ... I think it's useful to
On Fri, Nov 4, 2011 at 15:42, Tom Lane wrote:
> Marti Raudsepp writes:
>> While we're already breaking everything, we could remove the "waiting"
>> column and use a state with value 'waiting' instead.
> -1 ... I think it's useful to see the underlying state as well as the
> waiting flag. Also,
On Fri, Nov 4, 2011 at 10:34 AM, Tom Lane wrote:
> Robert's point about sinval catchup is another good one, though
> I don't remember what that does to the pg_stat_activity display.
My thought was that sinval catchup might require acquiring a relation
lock (e.g. on pg_class), and that might block
Magnus Hagander writes:
> I guess with the changes that showed different thing like fastpath,
> that makes sense. But if we just mapped the states that are there
> today straight off, is there any case where waiting can be true, when
> we're either idle or idle in transaction? I think not..
I'm n
On Fri, Nov 4, 2011 at 9:48 AM, Magnus Hagander wrote:
> On Fri, Nov 4, 2011 at 14:42, Tom Lane wrote:
> > Marti Raudsepp writes:
> >> While we're already breaking everything, we could remove the "waiting"
> >> column and use a state with value 'waiting' instead.
> >
> > -1 ... I think it's use
On Fri, Nov 4, 2011 at 9:48 AM, Magnus Hagander wrote:
> On Fri, Nov 4, 2011 at 14:42, Tom Lane wrote:
>> Marti Raudsepp writes:
>>> While we're already breaking everything, we could remove the "waiting"
>>> column and use a state with value 'waiting' instead.
>>
>> -1 ... I think it's useful to
On Fri, Nov 4, 2011 at 14:42, Tom Lane wrote:
> Marti Raudsepp writes:
>> While we're already breaking everything, we could remove the "waiting"
>> column and use a state with value 'waiting' instead.
>
> -1 ... I think it's useful to see the underlying state as well as the
> waiting flag. Also,
Marti Raudsepp writes:
> While we're already breaking everything, we could remove the "waiting"
> column and use a state with value 'waiting' instead.
-1 ... I think it's useful to see the underlying state as well as the
waiting flag. Also, this would represent breakage of part of the API
that d
On Wed, Nov 2, 2011 at 20:18, Scott Mead wrote:
> State will display , , in transaction, etc...
While we're already breaking everything, we could remove the "waiting"
column and use a state with value 'waiting' instead.
Also, returning these as text seems a little lame. Should there be an
en
On Fri, Nov 4, 2011 at 03:27, Fujii Masao wrote:
> On Thu, Nov 3, 2011 at 3:18 AM, Scott Mead wrote:
>> ISTM that we're all for:
>> creating a new column: state
>> renaming current_query => query
>> State will display , , in transaction, etc...
>> query will display the last query th
On Thu, Nov 3, 2011 at 3:18 AM, Scott Mead wrote:
> ISTM that we're all for:
> creating a new column: state
> renaming current_query => query
> State will display , , in transaction, etc...
> query will display the last query that was executed.
The greater/less-than-sign is still req
On Wed, Nov 2, 2011 at 4:12 AM, Albe Laurenz wrote:
> Andrew Dunstan wrote:
> > On 11/01/2011 09:52 AM, Tom Lane wrote:
> >> I'm for just redefining the query field as "current or last
> >> query".
> >
> > +1
> >
> >> I could go either way on whether to rename it.
> >
> > Rename it please. "curren
Andrew Dunstan wrote:
> On 11/01/2011 09:52 AM, Tom Lane wrote:
>> I'm for just redefining the query field as "current or last
>> query".
>
> +1
>
>> I could go either way on whether to rename it.
>
> Rename it please. "current_query" will just be wrong. I'd be inclined
> just to call it "query"
On Tue, Nov 01, 2011 at 10:13:52AM -0400, Andrew Dunstan wrote:
>
>
> On 11/01/2011 09:52 AM, Tom Lane wrote:
> >Simon Riggs writes:
> >>Why not leave it exactly as it is, and add a previous_query column?
> >>That gives you exactly what you need without breaking anything.
> >That would cost twic
On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane wrote:
> >> That would cost twice as much shared memory for query strings, and twice
> >> as much time to update the strings, for what seems pretty marginal
> >> value. I'm for j
On 11/01/2011 09:52 AM, Tom Lane wrote:
Simon Riggs writes:
Why not leave it exactly as it is, and add a previous_query column?
That gives you exactly what you need without breaking anything.
That would cost twice as much shared memory for query strings, and twice
as much time to update the
On Tue, Nov 1, 2011 at 1:20 PM, Magnus Hagander wrote:
> On Tue, Nov 1, 2011 at 18:11, Scott Mead wrote:
>>
>> On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane wrote:
>>>
>>> Robert Haas writes:
>>> > On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane wrote:
>>> >> That would cost twice as much shared memory f
On Tue, Nov 1, 2011 at 18:40, Scott Mead wrote:
>
>
> On Tue, Nov 1, 2011 at 1:20 PM, Magnus Hagander wrote:
>>
>> On Tue, Nov 1, 2011 at 18:11, Scott Mead wrote:
>> >
>> > On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane wrote:
>> >>
>> >> Robert Haas writes:
>> >> > On Tue, Nov 1, 2011 at 9:52 AM,
On Tue, Nov 1, 2011 at 1:20 PM, Magnus Hagander wrote:
> On Tue, Nov 1, 2011 at 18:11, Scott Mead wrote:
> >
> > On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane wrote:
> >>
> >> Robert Haas writes:
> >> > On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane wrote:
> >> >> That would cost twice as much shared m
On Tue, Nov 1, 2011 at 18:11, Scott Mead wrote:
>
> On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane wrote:
>>
>> Robert Haas writes:
>> > On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane wrote:
>> >> That would cost twice as much shared memory for query strings, and
>> >> twice
>> >> as much time to update t
2011/11/1 Marti Raudsepp :
> On Mon, Oct 31, 2011 at 23:37, Scott Mead wrote:
>> So I wrote the attached patch, it just turns in transaction into:
>> " in transaction\n: Previous: ". After seeing
>> how quickly our dev's fixed the issue once they saw prepared statement XYZ,
>
> Solving this
Robert Haas writes:
> On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane wrote:
>> That would cost twice as much shared memory for query strings, and twice
>> as much time to update the strings, for what seems pretty marginal
>> value. I'm for just redefining the query field as "current or last
>> query".
On 2011-11-01 21:13, Andrew Dunstan wrote:
Rename it please. "current_query" will just be wrong. I'd be inclined
just to call it "query" or "query_string" and leave it to the docs to
define the exact semantics.
I think "query" for a query that isn't ongoing would be just as wrong.
How about "
On Mon, Oct 31, 2011 at 23:37, Scott Mead wrote:
> So I wrote the attached patch, it just turns in transaction into:
> " in transaction\n: Previous: ". After seeing
> how quickly our dev's fixed the issue once they saw prepared statement XYZ,
Solving this problem is a good idea, but I don't
On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane wrote:
> Simon Riggs writes:
>> Why not leave it exactly as it is, and add a previous_query column?
>
>> That gives you exactly what you need without breaking anything.
>
> That would cost twice as much shared memory for query strings, and twice
> as much
On Tue, Nov 1, 2011 at 1:52 PM, Tom Lane wrote:
> Simon Riggs writes:
>> Why not leave it exactly as it is, and add a previous_query column?
>
>> That gives you exactly what you need without breaking anything.
>
> That would cost twice as much shared memory for query strings, and twice
> as much
Simon Riggs writes:
> Why not leave it exactly as it is, and add a previous_query column?
> That gives you exactly what you need without breaking anything.
That would cost twice as much shared memory for query strings, and twice
as much time to update the strings, for what seems pretty marginal
On Tue, Nov 1, 2011 at 8:41 AM, Magnus Hagander wrote:
> On Tue, Nov 1, 2011 at 13:19, Simon Riggs wrote:
>> On Mon, Oct 31, 2011 at 10:13 PM, Robert Haas wrote:
>>> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander
>>> wrote:
Actually, for the future, it might be useful to have a "state"
On Tue, Nov 1, 2011 at 12:41 PM, Magnus Hagander wrote:
> On Tue, Nov 1, 2011 at 13:19, Simon Riggs wrote:
>> On Mon, Oct 31, 2011 at 10:13 PM, Robert Haas wrote:
>>> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander
>>> wrote:
Actually, for the future, it might be useful to have a "state"
On Tue, Nov 1, 2011 at 13:19, Simon Riggs wrote:
> On Mon, Oct 31, 2011 at 10:13 PM, Robert Haas wrote:
>> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander wrote:
>>> Actually, for the future, it might be useful to have a "state" column,
>>> that holds the idle/in transaction/running status, ins
On Mon, Oct 31, 2011 at 10:13 PM, Robert Haas wrote:
> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander wrote:
>> Actually, for the future, it might be useful to have a "state" column,
>> that holds the idle/in transaction/running status, instead of the
>> tools having to parse the query text to
On Tue, Nov 1, 2011 at 7:38 AM, Magnus Hagander wrote:
> If we are doing it, it might be useful to just call it "query", so
> that it is dead obvious to people that the definition changed..
Yeah. Otherwise, people who are parsing the hard-coded strings
and are likely to get confused.
--
Robe
On Tue, Nov 1, 2011 at 00:18, Scott Mead wrote:
>
>
> On Mon, Oct 31, 2011 at 6:13 PM, Robert Haas wrote:
>>
>> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander
>> wrote:
>> > Actually, for the future, it might be useful to have a "state" column,
>> > that holds the idle/in transaction/running s
On Mon, Oct 31, 2011 at 7:18 PM, Scott Mead wrote:
>
>
> On Mon, Oct 31, 2011 at 6:13 PM, Robert Haas wrote:
>
>> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander
>> wrote:
>> > Actually, for the future, it might be useful to have a "state" column,
>> > that holds the idle/in transaction/running
On Mon, Oct 31, 2011 at 6:13 PM, Robert Haas wrote:
> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander
> wrote:
> > Actually, for the future, it might be useful to have a "state" column,
> > that holds the idle/in transaction/running status, instead of the
> > tools having to parse the query tex
On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander wrote:
> Actually, for the future, it might be useful to have a "state" column,
> that holds the idle/in transaction/running status, instead of the
> tools having to parse the query text to get that information...
+1 for doing it this way. Splitti
On Mon, Oct 31, 2011 at 4:45 PM, Magnus Hagander wrote:
>
> Actually, for the future, it might be useful to have a "state" column,
> that holds the idle/in transaction/running status, instead of the
> tools having to parse the query text to get that information...
>
if we are going to create the
On Mon, Oct 31, 2011 at 22:37, Scott Mead wrote:
> Hey all,
>
> So, I'm dealing with a a big ol' java app that has multiple roads on the
> way to in transaction. We can reproduce the problem in a test
> environment, but the lead dev always asks "can you just tell me the last
> query that it r
69 matches
Mail list logo
