On Thu, Jan 13, 2011 at 18:43, Robert Haas wrote:
> On Thu, Jan 13, 2011 at 11:08 AM, Magnus Hagander wrote:
>> On Wed, Jan 12, 2011 at 03:03, Robert Haas wrote:
>>> On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander
>>> wrote:
> No, do this at top
>
> if (walsnd->state == state)
>>>
On Thu, Jan 13, 2011 at 11:08 AM, Magnus Hagander wrote:
> On Wed, Jan 12, 2011 at 03:03, Robert Haas wrote:
>> On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander wrote:
No, do this at top
if (walsnd->state == state)
return;
Keep spinlocks when actually setting it.
>
On Wed, Jan 12, 2011 at 03:03, Robert Haas wrote:
> On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander 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
On 01/11/2011 10:24 PM, Shigeru HANADA wrote:
On Tue, 11 Jan 2011 13:24:33 +0100
Magnus Hagander 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 just committed a fix
On Tue, 11 Jan 2011 13:24:33 +0100
Magnus Hagander 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: Binary data
--
Sent
On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander 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 spinlock
On Tue, Jan 11, 2011 at 13:18, Simon Riggs wrote:
> On Tue, 2011-01-11 at 13:04 +0100, Magnus Hagander wrote:
>> On Tue, Jan 11, 2011 at 12:58, Simon Riggs 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 stat
On Tue, 2011-01-11 at 13:04 +0100, Magnus Hagander wrote:
> On Tue, Jan 11, 2011 at 12:58, Simon Riggs 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 12:58, Simon Riggs 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?
>
> You've se
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 stat
On Tue, Jan 11, 2011 at 12:23, Simon Riggs 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
On Tue, Jan 11, 2011 at 12:17, Robert Haas wrote:
> On Tue, Jan 11, 2011 at 5:28 AM, Magnus Hagander 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.
Hah, I was waiting for that. I
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<--->
On Tue, Jan 11, 2011 at 5:28 AM, Magnus Hagander 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 Enterprise PostgreSQL Compan
On Tue, Jan 11, 2011 at 02:24, Robert Haas wrote:
> On Mon, Jan 10, 2011 at 10:41 AM, Simon Riggs 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
>
On Mon, Jan 10, 2011 at 10:41 AM, Simon Riggs 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 Mon, Jan 10, 2011 at 16:48, Euler Taveira de Oliveira
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
On Mon, Jan 10, 2011 at 16:41, Simon Riggs 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 Riggs wrote:
>> >>> On Sun, 2011-01-
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, 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 Riggs wrote:
> >>> On Sun, 2011-01-09 at 12:52 +0100, Magnus Hagander wrote:
> >>>
> On
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 Riggs 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
On Mon, 2011-01-10 at 15:20 +0100, Magnus Hagander wrote:
> On Sun, Jan 9, 2011 at 15:53, Simon Riggs 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 sh
On Sun, Jan 9, 2011 at 15:53, Simon Riggs 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 location of 0/0.
>
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 probabl
On Fri, Jan 7, 2011 at 22:21, Robert Haas wrote:
> On Fri, Jan 7, 2011 at 1:46 PM, Josh Berkus 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 so
On Fri, Jan 7, 2011 at 1:46 PM, Josh Berkus 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, and the
On Fri, 2011-01-07 at 14:51 -0500, Tom Lane wrote:
> Simon Riggs 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 dum
On Fri, Jan 7, 2011 at 20:51, Tom Lane wrote:
> Simon Riggs 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 relo
Simon Riggs 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 100% trustworthy,
On Fri, 2011-01-07 at 19:48 +0100, Magnus Hagander wrote:
> On Fri, Jan 7, 2011 at 19:46, Josh Berkus 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 i
On Fri, Jan 7, 2011 at 19:46, Josh Berkus 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, and then
> 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 8:09 AM, Itagaki Takahiro
wrote:
> On Fri, Jan 7, 2011 at 21:48, Magnus Hagander 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_st
On Fri, Jan 7, 2011 at 21:48, Magnus Hagander 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 and slave...
On Fri, Jan 7, 2011 at 12:42, Itagaki Takahiro
wrote:
> On Fri, Jan 7, 2011 at 19:20, Simon Riggs 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 ge
On Fri, Jan 7, 2011 at 19:20, Simon Riggs 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 conflicts. Tha
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
On Wed, Jan 5, 2011 at 02:48, Simon Riggs 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 not have the O^2
On Wed, Jan 5, 2011 at 02:32, Itagaki Takahiro
wrote:
> On Wed, Jan 5, 2011 at 04:56, Heikki Linnakangas
> 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_replic
On Wed, Jan 5, 2011 at 04:56, Heikki Linnakangas
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 correctly, the view
> is similar
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_senders>0) but I hav
On 04.01.2011 21:43, Robert Haas wrote:
On Tue, Jan 4, 2011 at 2:31 PM, Magnus Hagander wrote:
On Tue, Jan 4, 2011 at 20:28, Josh Berkus 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
On Tue, Jan 4, 2011 at 2:31 PM, Magnus Hagander wrote:
> On Tue, Jan 4, 2011 at 20:28, Josh Berkus 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 ki
On Tue, Jan 4, 2011 at 20:28, Josh Berkus 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
contains data on
> 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, 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_senders>0) but I have no idea
> 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_senders>0) but I have no idea what pg_stat_replication_sent
> and pg_stat_replication_recei
On Tue, Jan 4, 2011 at 12:48 PM, Simon Riggs 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 call this pg_stat
On Tue, 2011-01-04 at 15:51 +0900, Itagaki Takahiro wrote:
> On Tue, Dec 28, 2010 at 22:17, Magnus Hagander 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,
>
On Tue, Dec 28, 2010 at 22:17, Magnus Hagander 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 WALsender
>>>
On Tue, Dec 28, 2010 at 14:14, Itagaki Takahiro
wrote:
> On Tue, Dec 28, 2010 at 21:46, Magnus Hagander 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.
On Tue, Dec 28, 2010 at 21:46, Magnus Hagander 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 definitely need
On Tue, Jun 22, 2010 at 06:18, Takahiro Itagaki
wrote:
>
> Magnus Hagander 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 JOIN instead of normal JOIN not to hide row
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 th
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
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
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 06:40, Takahiro Itagaki a écrit :
> [...]
> Tom Lane 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
>>
Tom Lane 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 for monitoring a
Heikki Linnakangas 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 view it might be possible to jus
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
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 underst
On Fri, Jun 18, 2010 at 04:33, Takahiro Itagaki
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 solution -
> adding a new system
63 matches
Mail list logo
