On Wed, Jan 12, 2011 at 03:03, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander mag...@hagander.net wrote:
No, do this at top
if (walsnd-state == state)
return;
Keep spinlocks when actually setting it.
I think this is safe...
Aha. Thanks for the
On Thu, Jan 13, 2011 at 11:08 AM, Magnus Hagander mag...@hagander.net wrote:
On Wed, Jan 12, 2011 at 03:03, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander mag...@hagander.net wrote:
No, do this at top
if (walsnd-state == state)
return;
Keep
On Thu, Jan 13, 2011 at 18:43, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 13, 2011 at 11:08 AM, Magnus Hagander mag...@hagander.net wrote:
On Wed, Jan 12, 2011 at 03:03, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander mag...@hagander.net
On Tue, Jan 11, 2011 at 02:24, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jan 10, 2011 at 10:41 AM, Simon Riggs si...@2ndquadrant.com wrote:
I think we need a status enum. ('BACKUP', 'CATCHUP', 'STREAM') for the 3
phases of replication.
That seems reasonable. But if we keep BACKUP
On Tue, Jan 11, 2011 at 5:28 AM, Magnus Hagander mag...@hagander.net wrote:
Does this seem correct?
It looks reasonable, except that I the way you've chosen to capitalize
the wal sender states makes me want to shoot myself.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
On Tue, 2011-01-11 at 11:28 +0100, Magnus Hagander wrote:
(You'd need a 4th mode for WAITING or so, to indicate it's waiting for
a command)
That's something different.
The 3 phases are more concrete.
BACKUP -- CATCHUP--- STREAM
When you connect you either do
On Tue, Jan 11, 2011 at 12:17, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 11, 2011 at 5:28 AM, Magnus Hagander mag...@hagander.net wrote:
Does this seem correct?
It looks reasonable, except that I the way you've chosen to capitalize
the wal sender states makes me want to shoot
On Tue, Jan 11, 2011 at 12:23, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2011-01-11 at 11:28 +0100, Magnus Hagander wrote:
(You'd need a 4th mode for WAITING or so, to indicate it's waiting for
a command)
That's something different.
The 3 phases are more concrete.
On Tue, 2011-01-11 at 12:41 +0100, Magnus Hagander wrote:
Just to be clear, you're objecting to the *name* of the state, right,
not how/where it's set?
Yes
In particular, how the catchup/streaming
things are set?
You've set it in the right places.
I would personally constrain the state
On Tue, Jan 11, 2011 at 12:58, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2011-01-11 at 12:41 +0100, Magnus Hagander wrote:
Just to be clear, you're objecting to the *name* of the state, right,
not how/where it's set?
Yes
In particular, how the catchup/streaming
things are set?
On Tue, 2011-01-11 at 13:04 +0100, Magnus Hagander wrote:
On Tue, Jan 11, 2011 at 12:58, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2011-01-11 at 12:41 +0100, Magnus Hagander wrote:
Just to be clear, you're objecting to the *name* of the state, right,
not how/where it's set?
Yes
On Tue, Jan 11, 2011 at 13:18, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2011-01-11 at 13:04 +0100, Magnus Hagander wrote:
On Tue, Jan 11, 2011 at 12:58, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2011-01-11 at 12:41 +0100, Magnus Hagander wrote:
Just to be clear, you're
On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander mag...@hagander.net wrote:
No, do this at top
if (walsnd-state == state)
return;
Keep spinlocks when actually setting it.
I think this is safe...
Aha. Thanks for the pointers, pfa a new version.
...but I think you also need to take the
On Tue, 11 Jan 2011 13:24:33 +0100
Magnus Hagander mag...@hagander.net wrote:
Aha. Thanks for the pointers, pfa a new version.
Changing pg_stat replication view would require to fix regression test
rule. Please find attached patch.
Regards,
--
Shigeru Hanada
rule_test.patch
Description:
On 01/11/2011 10:24 PM, Shigeru HANADA wrote:
On Tue, 11 Jan 2011 13:24:33 +0100
Magnus Hagandermag...@hagander.net wrote:
Aha. Thanks for the pointers, pfa a new version.
Changing pg_stat replication view would require to fix regression test
rule. Please find attached patch.
I have
On Sun, Jan 9, 2011 at 15:53, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, 2011-01-09 at 12:52 +0100, Magnus Hagander wrote:
One thing I noticed is that it gives an interesting property to my
patch for streaming base backups - they now show up in
pg_stat_replication, with a streaming
On Mon, 2011-01-10 at 15:20 +0100, Magnus Hagander wrote:
On Sun, Jan 9, 2011 at 15:53, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, 2011-01-09 at 12:52 +0100, Magnus Hagander wrote:
One thing I noticed is that it gives an interesting property to my
patch for streaming base backups -
On 10.01.2011 16:49, Simon Riggs wrote:
On Mon, 2011-01-10 at 15:20 +0100, Magnus Hagander wrote:
On Sun, Jan 9, 2011 at 15:53, Simon Riggssi...@2ndquadrant.com wrote:
On Sun, 2011-01-09 at 12:52 +0100, Magnus Hagander wrote:
One thing I noticed is that it gives an interesting property to
On Mon, 2011-01-10 at 17:05 +0200, Heikki Linnakangas wrote:
On 10.01.2011 16:49, Simon Riggs wrote:
On Mon, 2011-01-10 at 15:20 +0100, Magnus Hagander wrote:
On Sun, Jan 9, 2011 at 15:53, Simon Riggssi...@2ndquadrant.com wrote:
On Sun, 2011-01-09 at 12:52 +0100, Magnus Hagander wrote:
Em 10-01-2011 12:05, Heikki Linnakangas escreveu:
So how does a walsender that's waiting for a command from the client
show up? Surely it's not in catchup mode yet?
It is kind of initializing catchup. I think it is not worth representing
those short lifespan states (in normal scenarios).
--
On Mon, Jan 10, 2011 at 16:41, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2011-01-10 at 17:05 +0200, Heikki Linnakangas wrote:
On 10.01.2011 16:49, Simon Riggs wrote:
On Mon, 2011-01-10 at 15:20 +0100, Magnus Hagander wrote:
On Sun, Jan 9, 2011 at 15:53, Simon
On Mon, Jan 10, 2011 at 16:48, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Em 10-01-2011 12:05, Heikki Linnakangas escreveu:
So how does a walsender that's waiting for a command from the client
show up? Surely it's not in catchup mode yet?
It is kind of initializing catchup. I think
On Mon, Jan 10, 2011 at 10:41 AM, Simon Riggs si...@2ndquadrant.com wrote:
I think we need a status enum. ('BACKUP', 'CATCHUP', 'STREAM') for the 3
phases of replication.
That seems reasonable. But if we keep BACKUP in there, should we
really have it called pg_stat_replication? (yeah, I
On Fri, Jan 7, 2011 at 22:21, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 7, 2011 at 1:46 PM, Josh Berkus j...@agliodbs.com wrote:
To my way of thinking, pg_stat_walsender and pg_stat_walreceiver would
be more clear than pg_stat_replication_master and
pg_stat_replication_slave.
On Sun, 2011-01-09 at 12:52 +0100, Magnus Hagander wrote:
One thing I noticed is that it gives an interesting property to my
patch for streaming base backups - they now show up in
pg_stat_replication, with a streaming location of 0/0.
If the view is named pg_stat_replication, we probably
On Fri, 2011-01-07 at 12:13 +0900, Itagaki Takahiro wrote:
pg_stat_replication seems to be the most understandable name.
I would very much appreciate it if one of you could complete something
here and commit in the next few days. That would then allow me to extend
the view with sync rep
On Fri, Jan 7, 2011 at 19:20, Simon Riggs si...@2ndquadrant.com wrote:
pg_stat_replication seems to be the most understandable name.
Please go with whatever you think best for now. I'm sure people will ask
for different names later anyway. Let's get this committed soon, to
reduce later patch
On Fri, Jan 7, 2011 at 12:42, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Fri, Jan 7, 2011 at 19:20, Simon Riggs si...@2ndquadrant.com wrote:
pg_stat_replication seems to be the most understandable name.
Please go with whatever you think best for now. I'm sure people will ask
for
On Fri, Jan 7, 2011 at 21:48, Magnus Hagander mag...@hagander.net wrote:
* pg_stat_replication
* pg_stat_standby (not yet)
Just to keep the bikeshedding up, should it in this case not be
pg_stat_replication_master and pg_stat_replication_standby or such?
Replication applies to both master
On Fri, Jan 7, 2011 at 8:09 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Fri, Jan 7, 2011 at 21:48, Magnus Hagander mag...@hagander.net wrote:
* pg_stat_replication
* pg_stat_standby (not yet)
Just to keep the bikeshedding up, should it in this case not be
To my way of thinking, pg_stat_walsender and pg_stat_walreceiver would
be more clear than pg_stat_replication_master and
pg_stat_replication_slave.
Let's commit it so that some of us can get a look at the data it
contains, and then we can fix the name during beta.
--
On Fri, Jan 7, 2011 at 19:46, Josh Berkus j...@agliodbs.com wrote:
To my way of thinking, pg_stat_walsender and pg_stat_walreceiver would
be more clear than pg_stat_replication_master and
pg_stat_replication_slave.
Let's commit it so that some of us can get a look at the data it
contains,
On Fri, 2011-01-07 at 19:48 +0100, Magnus Hagander wrote:
On Fri, Jan 7, 2011 at 19:46, Josh Berkus j...@agliodbs.com wrote:
To my way of thinking, pg_stat_walsender and pg_stat_walreceiver would
be more clear than pg_stat_replication_master and
pg_stat_replication_slave.
Let's commit
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2011-01-07 at 19:48 +0100, Magnus Hagander wrote:
We try to avoid inidb-requiring changes (like renaming a system
object...) during beta.
Why?
So that beta testers won't be forced to do a dump and reload.
When and if pg_upgrade is actually
On Fri, Jan 7, 2011 at 20:51, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2011-01-07 at 19:48 +0100, Magnus Hagander wrote:
We try to avoid inidb-requiring changes (like renaming a system
object...) during beta.
Why?
So that beta testers won't be
On Fri, 2011-01-07 at 14:51 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2011-01-07 at 19:48 +0100, Magnus Hagander wrote:
We try to avoid inidb-requiring changes (like renaming a system
object...) during beta.
Why?
So that beta testers won't be forced to
On Fri, Jan 7, 2011 at 1:46 PM, Josh Berkus j...@agliodbs.com wrote:
To my way of thinking, pg_stat_walsender and pg_stat_walreceiver would
be more clear than pg_stat_replication_master and
pg_stat_replication_slave.
Let's commit it so that some of us can get a look at the data it
contains,
On Wed, Jan 5, 2011 at 02:48, Simon Riggs si...@2ndquadrant.com wrote:
The way I coded it was a new SRF that joins to the existing
pg_stat_activity. So no initdb required, and this can also easily be
included as an external module for 9.0.
Please notice also that my coding of the new SRF does
On Wed, Jan 5, 2011 at 02:32, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Wed, Jan 5, 2011 at 04:56, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I think pg_stat_replication is better than pg_stat_standby, but I'm
still not convinced we shouldn't go with the obvious
On Tue, 2011-01-04 at 15:51 +0900, Itagaki Takahiro wrote:
On Tue, Dec 28, 2010 at 22:17, Magnus Hagander mag...@hagander.net wrote:
We definitely need the very basic level for 9.1, and we can always
improve on it later :-)
pg_stat_walsender. It would then only need the columns for
On Tue, Jan 4, 2011 at 12:48 PM, Simon Riggs si...@2ndquadrant.com wrote:
The sent pointer is needed whether or not we have sync rep. We should
also include application name, since the user may set that in the
standby for all the same reasons it is set elsewhere.
Small point: please lets not
Eh... I may be showing my status as a non-normal human, but I know
exactly what pg_stat_walsender is (it's the view that shows you the
status of the WAL senders you've allowed by configuring
max_wal_senders0) but I have no idea what pg_stat_replication_sent
and pg_stat_replication_received
On Tue, 2011-01-04 at 10:50 -0800, Josh Berkus wrote:
Eh... I may be showing my status as a non-normal human, but I know
exactly what pg_stat_walsender is (it's the view that shows you the
status of the WAL senders you've allowed by configuring
max_wal_senders0) but I have no idea what
hmmm I think pg_stat_standby might be more relevant but I definitely
agree something more newbie appropriate is in order.
I'd be fine with that name, too.
--
-- Josh Berkus
PostgreSQL Experts Inc.
On Tue, Jan 4, 2011 at 20:28, Josh Berkus j...@agliodbs.com wrote:
hmmm I think pg_stat_standby might be more relevant but I definitely
agree something more newbie appropriate is in order.
I'd be fine with that name, too.
That seems kind of backwards though - given that the view only
On Tue, Jan 4, 2011 at 2:31 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Jan 4, 2011 at 20:28, Josh Berkus j...@agliodbs.com wrote:
hmmm I think pg_stat_standby might be more relevant but I definitely
agree something more newbie appropriate is in order.
I'd be fine with that name,
On 04.01.2011 21:43, Robert Haas wrote:
On Tue, Jan 4, 2011 at 2:31 PM, Magnus Hagandermag...@hagander.net wrote:
On Tue, Jan 4, 2011 at 20:28, Josh Berkusj...@agliodbs.com wrote:
hmmm I think pg_stat_standby might be more relevant but I definitely
agree something more newbie appropriate
On Tue, Jan 04, 2011 at 10:50:12AM -0800, Josh Berkus wrote:
Eh... I may be showing my status as a non-normal human, but I know
exactly what pg_stat_walsender is (it's the view that shows you the
status of the WAL senders you've allowed by configuring
max_wal_senders0) but I have no idea
On Wed, Jan 5, 2011 at 04:56, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I think pg_stat_replication is better than pg_stat_standby, but I'm
still not convinced we shouldn't go with the obvious
pg_stat_walsenders.
How about pg_stat_replication_activity? If I understood
On Tue, Dec 28, 2010 at 22:17, Magnus Hagander mag...@hagander.net wrote:
We definitely need the very basic level for 9.1, and we can always
improve on it later :-)
pg_stat_walsender. It would then only need the columns for procpid,
usesysid, usename, client_addr, client_port, and the
On Tue, Jun 22, 2010 at 06:18, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Magnus Hagander mag...@hagander.net wrote:
The downside is that version 1 will require an initdb, and not version
2, right?
Unfortunately, 2 also requires initdb because pg_stat_activity will
use LEFT
On Tue, Dec 28, 2010 at 21:46, Magnus Hagander mag...@hagander.net wrote:
Unfortunately, 2 also requires initdb because pg_stat_activity will
use LEFT JOIN instead of normal JOIN not to hide rows with databaseid = 0.
All of them are items for 9.1.
Did this one end up on the floor?
We
On Tue, Dec 28, 2010 at 14:14, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Tue, Dec 28, 2010 at 21:46, Magnus Hagander mag...@hagander.net wrote:
Unfortunately, 2 also requires initdb because pg_stat_activity will
use LEFT JOIN instead of normal JOIN not to hide rows with databaseid =
Le 22/06/2010 06:40, Takahiro Itagaki a écrit :
[...]
Tom Lane t...@sss.pgh.pa.us wrote:
I'm of the opinion that this is a 9.1 problem. It needs more thought
than we can put into it now --- one obvious question is what about
monitoring on the slave side? Another is who should be able to
On Tue, 2010-06-22 at 09:54 +0200, Guillaume Lelarge wrote:
I added support for Hot Standby /
Streaming Replication in pgAdmin (that was a really small patch, there
was not a lot to do)
Well done.
Does this mean that pgAdmin has a read only mode now?
What are the details of that support? I
Le 22/06/2010 12:42, Simon Riggs a écrit :
On Tue, 2010-06-22 at 12:19 +0200, Guillaume Lelarge wrote:
Shamely simple : I only added some informations on the server's
properties. See
http://www.pgadmin.org/images/visualtour12/visualtour08.jpg. We only
display the fact that the server is (or
Le 22/06/2010 11:41, Simon Riggs a écrit :
On Tue, 2010-06-22 at 09:54 +0200, Guillaume Lelarge wrote:
I added support for Hot Standby /
Streaming Replication in pgAdmin (that was a really small patch, there
was not a lot to do)
Well done.
Does this mean that pgAdmin has a read only mode
On Tue, 2010-06-22 at 12:19 +0200, Guillaume Lelarge wrote:
Shamely simple : I only added some informations on the server's
properties. See
http://www.pgadmin.org/images/visualtour12/visualtour08.jpg. We only
display the fact that the server is (or isn't) in recovery, and the
result of the
Tom Lane t...@sss.pgh.pa.us wrote:
I'm of the opinion that this is a 9.1 problem. It needs more thought
than we can put into it now --- one obvious question is what about
monitoring on the slave side? Another is who should be able to see the
data?
Sure. We should research user's demands
On Fri, Jun 18, 2010 at 04:33, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Hi,
We don't have any statistic views for walsenders in SR's master server
in 9.0, but such views would be useful to monitor and manage standby
servers from the master server. I have two ideas for the
On Fri, 2010-06-18 at 11:33 +0900, Takahiro Itagaki wrote:
1. Add another system view for walsenders, ex. pg_stat_replication.
It would show pid, remote host, and sent location for each walsender.
I prefer this option. I consider it an omission that we should correct.
Not sure I understand
On 18/06/10 13:41, Simon Riggs wrote:
On Fri, 2010-06-18 at 11:33 +0900, Takahiro Itagaki wrote:
1. Add another system view for walsenders, ex. pg_stat_replication.
It would show pid, remote host, and sent location for each walsender.
I prefer this option. I consider it an omission that
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Let's discuss what the best possible user interface for the information
would be first, and then decide if we need/want to force an initdb for
that. We have pg_upgrade now, that makes initdb less painful, and if
it's just a new
63 matches
Mail list logo
