Eric Kerin wrote:
On Sun, 2004-08-15 at 16:22, Gaetano Mendola wrote:
Eric Kerin wrote:
On Sat, 2004-08-14 at 01:11, Tom Lane wrote:
Eric Kerin <[EMAIL PROTECTED]> writes:
The issues I've seen are:
1. Knowing when the master has finished the file transfer transfer to
the backup.
The "standard" so
On Sun, 2004-08-15 at 16:22, Gaetano Mendola wrote:
> Eric Kerin wrote:
> > On Sat, 2004-08-14 at 01:11, Tom Lane wrote:
> >
> >>Eric Kerin <[EMAIL PROTECTED]> writes:
> >>
> >>>The issues I've seen are:
> >>>1. Knowing when the master has finished the file transfer transfer to
> >>>the backup.
>
Eric Kerin wrote:
On Sat, 2004-08-14 at 01:11, Tom Lane wrote:
Eric Kerin <[EMAIL PROTECTED]> writes:
The issues I've seen are:
1. Knowing when the master has finished the file transfer transfer to
the backup.
The "standard" solution to this is you write to a temporary file name
(generated off your
On Sat, 2004-08-14 at 01:11, Tom Lane wrote:
> Eric Kerin <[EMAIL PROTECTED]> writes:
> > The issues I've seen are:
> > 1. Knowing when the master has finished the file transfer transfer to
> > the backup.
>
> The "standard" solution to this is you write to a temporary file name
> (generated off y
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>> Right, also an area that needs thought. Some other people opined that
>> they want the switchover to occur only on manual command. I'd go with
>> that too if you have anything close to 24x7 availability of admins.
>> If you *mu
> Tom Lane
> Eric Kerin <[EMAIL PROTECTED]> writes:
> > The issues I've seen are:
> > 1. Knowing when the master has finished the file transfer transfer to
> > the backup.
>
> The "standard" solution to this is you write to a temporary file name
> (generated off your process PID, or some other conv
Eric Kerin wrote:
On Wed, 2004-08-11 at 16:43, Tom Lane wrote:
Gaetano Mendola <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
It should work; dunno if anyone has tried it yet.
I was thinking about it but I soon realized that actually is
impossible to do, postgres replay the log only if during the
sta
Eric Kerin <[EMAIL PROTECTED]> writes:
> The issues I've seen are:
> 1. Knowing when the master has finished the file transfer transfer to
> the backup.
The "standard" solution to this is you write to a temporary file name
(generated off your process PID, or some other convenient reasonably-
uniqu
On Wed, 2004-08-11 at 16:43, Tom Lane wrote:
> Gaetano Mendola <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> It should work; dunno if anyone has tried it yet.
>
> > I was thinking about it but I soon realized that actually is
> > impossible to do, postgres replay the log only if during the
Brian Hirt <[EMAIL PROTECTED]> writes:
> I wonder if there will be assumptions in the startup code concerning
> time. What if the startup takes 18 months, would there be some sort
> of problem with this approach you think?
I don't know of any such assumptions, but this sort of question is why
I wonder if there will be assumptions in the startup code concerning
time. What if the startup takes 18 months, would there be some sort
of problem with this approach you think?
On Aug 11, 2004, at 6:14 PM, Gaetano Mendola wrote:
Tom Lane wrote:
Somebody should hack this together and try it d
Tom Lane wrote:
Somebody should hack this together and try it during beta. I don't
have time myself.
Will see, if I have spare time I will try.
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unreg
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It should work; dunno if anyone has tried it yet.
> I was thinking about it but I soon realized that actually is
> impossible to do, postgres replay the log only if during the
> start the file recover.conf is present in $DATA directo
Tom Lane wrote:
Hannu Krosing <[EMAIL PROTECTED]> writes:
will PITR in 8.0 be usable for "hot spare"/"log shipping" type of
replication or is it just for Point In Time RECOVERY ?
It should work; dunno if anyone has tried it yet.
I was thinking about it but I soon realized that actually is
impossib
Hannu Krosing <[EMAIL PROTECTED]> writes:
> will PITR in 8.0 be usable for "hot spare"/"log shipping" type of
> replication or is it just for Point In Time RECOVERY ?
It should work; dunno if anyone has tried it yet.
regards, tom lane
---(end of br
15 matches
Mail list logo
