Lists: | pgsql-hackers |
---|
From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parameter oddness; was HS/SR Assert server crash |
Date: | 2010-05-14 21:12:09 |
Message-ID: | 201005142112.o4ELC9t18223@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
bruce wrote:
> > and my slave recovery.conf was:
> >
> > restore_command = 'cp /u/pg/archive/%f %p' # e.g. 'cp /mnt/server/archivedir/%f %p'
> > standby_mode = 'on'
> > primary_conninfo = 'host=localhost port=5432' # e.g. 'host=localhost port=5432'
> >
> > Let me know what additional information I can supply.
>
> I saw Simon's commit fixing this bug. Another good reason we didn't
> bundle 9.0 beta2 yesterday.
I can now confirm that Simon's patch fixes the bug. (Unfortunately I
had a web cast yesterday about this feature and the bug prevented me
from completing the demonstration.)
FYI, my presentation shows all the steps necessary to setup HS/SR:
http://momjian.us/main/presentations/technical.html#hot_streaming
One odd thing is we have two paramters that mention hot_standby --- on
the master we have to do in postgresql.conf:
wal_level = hot_standby
and on the slave we do in postgresql.conf:
hot_standby = on
That is a little confusing.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Bruce Momjian" <bruce(at)momjian(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parameter oddness; was HS/SR Assert server crash |
Date: | 2010-05-14 21:19:03 |
Message-ID: | 4BED77F702000025000317C6@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> One odd thing is we have two paramters that mention hot_standby
> --- on the master we have to do in postgresql.conf:
>
> wal_level = hot_standby
>
> and on the slave we do in postgresql.conf:
>
> hot_standby = on
>
> That is a little confusing.
Why? I read that as saying that the master is writing sufficient
data into the WAL for it to be usable for hot standby purposes, and
that that the slave machine is going to be used as a hot standby.
You'd better do the former if you're going to do the latter, but
there were good reasons not to try to infer one setting from the
other.
-Kevin
From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parameter oddness; was HS/SR Assert server crash |
Date: | 2010-05-14 22:34:40 |
Message-ID: | 201005142234.o4EMYec13038@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Kevin Grittner wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> > One odd thing is we have two paramters that mention hot_standby
> > --- on the master we have to do in postgresql.conf:
> >
> > wal_level = hot_standby
> >
> > and on the slave we do in postgresql.conf:
> >
> > hot_standby = on
> >
> > That is a little confusing.
>
> Why? I read that as saying that the master is writing sufficient
> data into the WAL for it to be usable for hot standby purposes, and
> that that the slave machine is going to be used as a hot standby.
> You'd better do the former if you're going to do the latter, but
> there were good reasons not to try to infer one setting from the
> other.
My point was that the string 'hot_standby' is both a variable and a
setting.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com