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 I
On Mon, Feb 24, 2014 at 2:49 PM, Christian Kruse
christ...@2ndquadrant.com 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
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 @@
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,
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 is
On 2014-02-14 23:03:43 -0500, Robert Haas wrote:
On Wed, Feb 12, 2014 at 8:00 AM, Christian Kruse
christ...@2ndquadrant.com 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,
On Wed, Feb 12, 2014 at 8:00 AM, Christian Kruse
christ...@2ndquadrant.com 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
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 and
On Fri, Feb 7, 2014 at 4:34 AM, Christian Kruse
christ...@2ndquadrant.com 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 xref instead of link in documentation
- rename fields to backend_xid and
On 2014-02-05 13:26:15 -0500, Robert Haas wrote:
On Wed, Feb 5, 2014 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Mon, Feb 3, 2014 at 6:47 AM, Christian Kruse
christ...@2ndquadrant.com wrote:
[ new patch ]
Is there some compelling reason not to write the documentation link as
xref linkend=guc-hot-standby-feedback rather than using link?
It feels weird to me that the new columns are called transactionid
Robert Haas robertmh...@gmail.com 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
On Wed, Feb 5, 2014 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 5, 2014 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us 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
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 now, I
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: replaceableuser/
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
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,
On Fri, Jan 31, 2014 at 4:40 AM, Andres Freund and...@2ndquadrant.com 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
On Fri, Jan 31, 2014 at 8:02 AM, Christian Kruse
christ...@2ndquadrant.com 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
On Wed, Jan 29, 2014 at 3:11 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 14 January 2014 08:38, Christian Kruse christ...@2ndquadrant.com 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
On 30 January 2014 17:27, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jan 29, 2014 at 3:11 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 14 January 2014 08:38, Christian Kruse christ...@2ndquadrant.com wrote:
Hi,
On 13/01/14 20:06, Heikki Linnakangas wrote:
On 12/17/2013 04:58 PM,
On 14 January 2014 08:38, Christian Kruse christ...@2ndquadrant.com 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
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,
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
christ...@2ndquadrant.com 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
28 matches
Mail list logo
