Hi Robert,
On 25/02/14 12:37, Robert Haas wrote:
> Committed, after fixing the regression test outputs. I also changed
> the new fields to be NULL rather than 0 when they are invalid, because
> that way applying age() to that column does something useful instead
> of something lame.
Hm, thought
On Mon, Feb 24, 2014 at 2:49 PM, Christian Kruse
wrote:
> attached you will find a fixed version.
Committed, after fixing the regression test outputs. I also changed
the new fields to be NULL rather than 0 when they are invalid, because
that way applying age() to that column does something usefu
Hi,
On 2014-02-21 14:15:09 +0100, Christian Kruse wrote:
> +/* --
> + * pgstat_fetch_stat_local_beentry() -
> + *
> + * Like pgstat_fetch_stat_beentry() but with local addtions (like xid and
> + * xmin values of the backend)
s/local addtions/locally computed addititions/
> +/*
On 2014-02-21 13:40:59 +0100, Christian Kruse wrote:
> diff --git a/src/backend/utils/adt/pgstatfuncs.c
> b/src/backend/utils/adt/pgstatfuncs.c
> index a4f31cf..e65b079 100644
> --- a/src/backend/utils/adt/pgstatfuncs.c
> +++ b/src/backend/utils/adt/pgstatfuncs.c
> @@ -536,7 +536,7 @@ pg_stat_get_
Hi,
On 18.02.2014 22:02, Andres Freund wrote:
> Not really sure which way is better.
One dev against it, one dev not sure. Enough for me to change it :)
Will post a new patch this evening.
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development, 24x
On 2014-02-17 10:44:41 +0100, Christian Kruse wrote:
> This is true for now. But one of the purposes of using
> LocalPgBackendStatus instead of PgBackendStatus was to be able to add
> more fields like this in future. And thus we might need to change this
> in future, so why not do it now?
I don't
Hi Robert,
Am 15.02.14 05:03, schrieb Robert Haas:
> Well, this version of the patch reveals a mighty interesting point: a
> lot of the people who are calling pgstat_fetch_stat_beentry() don't
> need this additional information and might prefer not to pay the cost
> of fetching it.
Well, the cost
On 2014-02-14 23:03:43 -0500, Robert Haas wrote:
> On Wed, Feb 12, 2014 at 8:00 AM, Christian Kruse
> wrote:
> > On Wednesday 12 February 2014 11:14:56 Andres Freund wrote:
> >> But they do take up shared memory without really needing to. I
> >> personally don't find that too bad, it's not much me
On Wed, Feb 12, 2014 at 8:00 AM, Christian Kruse
wrote:
> On Wednesday 12 February 2014 11:14:56 Andres Freund wrote:
>> But they do take up shared memory without really needing to. I
>> personally don't find that too bad, it's not much memory. If we want to
>> avoid it we could have a LocalPgBack
On 2014-02-11 09:15:45 -0500, Robert Haas wrote:
> If I understand correctly, modifying PgBackendStatus adds additional
> fields to the shared memory data structure that are never used and
> will be returned by functions like pgstat_fetch_stat_beentry()
> unitialized. That seems both inefficient a
On Fri, Feb 7, 2014 at 4:34 AM, Christian Kruse
wrote:
> attached you will find a new version with the following issues
> resolved:
>
> - use backend ID once again for getting the xid and xmin
> - use instead of in documentation
> - rename fields to backend_xid and backend_xmin
This looks mostl
On 2014-02-05 13:26:15 -0500, Robert Haas wrote:
> On Wed, Feb 5, 2014 at 1:21 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> It feels weird to me that the new columns are called transactionid and
> >> xmin. Why not xid and xmin?
> >
> > Actually the part of that that bothers me is "xmin", whi
Robert Haas writes:
> On Wed, Feb 5, 2014 at 1:21 PM, Tom Lane wrote:
>> Actually the part of that that bothers me is "xmin", which conflicts
>> with a reserved system column name. While you can legally pick such
>> conflicting names for view columns, it's not going to be so much fun
>> when you
On Wed, Feb 5, 2014 at 1:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> It feels weird to me that the new columns are called transactionid and
>> xmin. Why not xid and xmin?
>
> Actually the part of that that bothers me is "xmin", which conflicts
> with a reserved system column name. While you
Robert Haas writes:
> It feels weird to me that the new columns are called transactionid and
> xmin. Why not xid and xmin?
Actually the part of that that bothers me is "xmin", which conflicts
with a reserved system column name. While you can legally pick such
conflicting names for view columns,
On Mon, Feb 3, 2014 at 6:47 AM, Christian Kruse
wrote:
> [ new patch ]
Is there some compelling reason not to write the documentation link as
rather than using ?
It feels weird to me that the new columns are called transactionid and
xmin. Why not xid and xmin?
If I understand correctly, modif
Him
On 2014-02-01 17:03:46 +0100, Christian Kruse wrote:
> diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
> index a37e6b6..bef5912 100644
> --- a/doc/src/sgml/monitoring.sgml
> +++ b/doc/src/sgml/monitoring.sgml
> @@ -629,6 +629,16 @@ postgres: user database
> host
Hi,
On 31/01/14 11:24, Robert Haas wrote:
> > what do you think about the approach the attached patch implements?
> > I'm not really sure if this is what you had in mind, especially if
> > this is the right lock.
>
> The attached patch seems not to be attached, […]
*sighs*
I'm at FOSDEM right no
On Fri, Jan 31, 2014 at 8:02 AM, Christian Kruse
wrote:
> what do you think about the approach the attached patch implements?
> I'm not really sure if this is what you had in mind, especially if
> this is the right lock.
The attached patch seems not to be attached, but the right lock to use
would
On Fri, Jan 31, 2014 at 4:40 AM, Andres Freund wrote:
> On 2014-01-30 12:27:43 -0500, Robert Haas wrote:
>> Nope, but I think this patch is broken. It looks to me like it's
>> conflating the process offset in the BackendStatus array with its
>> backendId, which does not seem like a good idea even
Hi,
> I suspect we should have a new accessor function that takes a backend
> ID and copies the xid and xmin to pointers provided by the client
> while holding the lock.
what do you think about the approach the attached patch implements?
I'm not really sure if this is what you had in mind, especi
On 2014-01-30 12:27:43 -0500, Robert Haas wrote:
> Nope, but I think this patch is broken. It looks to me like it's
> conflating the process offset in the BackendStatus array with its
> backendId, which does not seem like a good idea even if it happens to
> work at present.
Hm. I don't see how th
On 30 January 2014 17:27, Robert Haas wrote:
> On Wed, Jan 29, 2014 at 3:11 PM, Simon Riggs wrote:
>> On 14 January 2014 08:38, Christian Kruse wrote:
>>> Hi,
>>> On 13/01/14 20:06, Heikki Linnakangas wrote:
On 12/17/2013 04:58 PM, Christian Kruse wrote:
>attached you will find a patch
On Wed, Jan 29, 2014 at 3:11 PM, Simon Riggs wrote:
> On 14 January 2014 08:38, Christian Kruse wrote:
>> Hi,
>> On 13/01/14 20:06, Heikki Linnakangas wrote:
>>> On 12/17/2013 04:58 PM, Christian Kruse wrote:
>>> >attached you will find a patch for showing the current transaction id
>>> >(xid) an
On 14 January 2014 08:38, Christian Kruse wrote:
> Hi,
>
> On 13/01/14 20:06, Heikki Linnakangas wrote:
>> On 12/17/2013 04:58 PM, Christian Kruse wrote:
>> >attached you will find a patch for showing the current transaction id
>> >(xid) and the xmin of a backend in pg_stat_activty and the xmin in
On 12/17/2013 04:58 PM, Christian Kruse wrote:
attached you will find a patch for showing the current transaction id
(xid) and the xmin of a backend in pg_stat_activty and the xmin in
pg_stat_replication.
Docs.
When an admin is looking for a long-running transaction that's blocking
vacuum, he
Hi,
On 17/12/13 12:08, Robert Haas wrote:
> Please add your patch here so we don't lose track of it:
>
> https://commitfest.postgresql.org/action/commitfest_view/open
Thanks. I nearly forgot that.
Regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development,
On Tue, Dec 17, 2013 at 9:58 AM, Christian Kruse
wrote:
> Hi,
>
> attached you will find a patch for showing the current transaction id
> (xid) and the xmin of a backend in pg_stat_activty and the xmin in
> pg_stat_replication.
>
> This may be helpful when looking for the cause of bloat.
>
> I add
28 matches
Mail list logo
