On Tue, Feb 07, 2006 at 04:11:07PM +0100, Csaba Nagy wrote:
> pg_wal (
> name text,
> walrecords blob,
> iscurrent boolean
> )
ISTM that a current_wal_file() function would be better than a boolean
on the view...
> So, all this said, I'm not too familiar with either C programming or the
>
I have updated the 8.1.X documentation to remove the word "only", which
is confusing.
---
Jim C. Nasby wrote:
> On Thu, Feb 09, 2006 at 10:37:34AM +0100, Csaba Nagy wrote:
> > option can only be set at server start o
On 2/9/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> What happens right now when you want to bring the standby up? Do you
> have to kill it out of recovery mode and re-start, forcing it to replay
> WAL again anyway?
touch $LOGDIR/STOP ...
--
marko
---(end of broadcast)--
On Thu, Feb 09, 2006 at 04:44:20PM +0200, Marko Kreen wrote:
> On 2/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Andrew Rawnsley <[EMAIL PROTECTED]> writes:
> > > IMHO the #1 priority in the current PITR/WAL shipping system is to make
> > > the
> > > standby able to tolerate being shut down and r
On Thu, Feb 09, 2006 at 10:37:34AM +0100, Csaba Nagy wrote:
> option can only be set at server start or in the postgresql.conf
Yeah, this is something that was actually discussed on -docs recently. I
believe -HEAD was changed so that every parameter that used to have that
text now says: op
On 2/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Rawnsley <[EMAIL PROTECTED]> writes:
> > IMHO the #1 priority in the current PITR/WAL shipping system is to make the
> > standby able to tolerate being shut down and restarted, i.e. actually having
> > a true standby mode and not the current m
OK, this is news to me, I recall that last looking at the configuration
docs it was start-up time, but I might be wrong.
[looking up the docs]
OK, citing the 8.1 online docs:
17.5.3. Archiving
archive_command (string)
The shell command to execute to archive a completed segment
On Wed, 2006-02-08 at 11:10 +0100, Csaba Nagy wrote:
> Another issue is that unless you got the archive_command right in the
> master server from the beginning, you will have to restart the server
> once you decide to build your standby... the archive_command is a
> start-up time parameter
Much of
On 2/7/06 1:19 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Andrew Rawnsley <[EMAIL PROTECTED]> writes:
>> IMHO the #1 priority in the current PITR/WAL shipping system is to make the
>> standby able to tolerate being shut down and restarted, i.e. actually having
>> a true standby mode and not th
> What do you find difficult about the current method? That's got to be
> the first discussion point.
The main problem I have is the complexity of setup.
It involves a lot of additional scripting which you have to get it right
to be actually reliable. The documentation is giving a rough idea on h
On Tue, 2006-02-07 at 16:11 +0100, Csaba Nagy wrote:
> I decided to start implementing a streamlined WAL shipping based standby
> building procedure. My aim is fairly simple: to be able to build a
> standby as automated as possible.
What do you find difficult about the current method? That's got
Andrew Rawnsley <[EMAIL PROTECTED]> writes:
> IMHO the #1 priority in the current PITR/WAL shipping system is to make the
> standby able to tolerate being shut down and restarted, i.e. actually having
> a true standby mode and not the current method of doing it only on startup.
How is shutting dow
On Tue, 2006-02-07 at 16:58, Andrew Rawnsley wrote:
> IMHO the #1 priority in the current PITR/WAL shipping system is to make the
> standby able to tolerate being shut down and restarted, i.e. actually having
> a true standby mode and not the current method of doing it only on startup.
This fits n
IMHO the #1 priority in the current PITR/WAL shipping system is to make the
standby able to tolerate being shut down and restarted, i.e. actually having
a true standby mode and not the current method of doing it only on startup.
While it is a trivial thing to fool postgres into staying in startup
On Tue, 2006-02-07 at 16:45, Tom Lane wrote:
> Csaba Nagy <[EMAIL PROTECTED]> writes:
> > You obviously did not read further down :-)
> > I was proposing a subscription system, where the slave can specify the
> > oldest WAL file it is interested in, and keep that up to date as it
> > processes them
Csaba Nagy <[EMAIL PROTECTED]> writes:
> You obviously did not read further down :-)
> I was proposing a subscription system, where the slave can specify the
> oldest WAL file it is interested in, and keep that up to date as it
> processes them.
And how is that "system view" going to handle subscr
You obviously did not read further down :-)
I was proposing a subscription system, where the slave can specify the
oldest WAL file it is interested in, and keep that up to date as it
processes them.
That could cause of course trouble if a slave dies and it won't update
the subscription, but that'
Csaba Nagy <[EMAIL PROTECTED]> writes:
> The procedure should be something similar to the one available today if
> you do it manually. The main difference would be that the standby
> postmaster should connect to the primary server, and get all table data
> and WAL record stream through normal data
Hi all,
I decided to start implementing a streamlined WAL shipping based standby
building procedure. My aim is fairly simple: to be able to build a
standby as automated as possible.
The ultimate simplicity would be for me:
- install postgres on the standby machine;
- create a directory for th
19 matches
Mail list logo
