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 or in
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
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 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 method of
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:
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 restarted, i.e.
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
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
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 the current
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
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 base
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
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
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.
And
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
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
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 down
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
19 matches
Mail list logo
