Bruce Momjian wrote:
Dave Page wrote:
On Sun, May 18, 2008 at 1:38 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
I don't know how you tested,
Copy a large file across a relatively slow network, and check the size
on the destination drive before it finishes.
but could yo
Dave Page wrote:
> On Sun, May 18, 2008 at 1:38 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> >
> > I don't know how you tested,
>
> Copy a large file across a relatively slow network, and check the size
> on the destination drive before it finishes.
>
> > but could you please repeat the test w
Andrew Dunstan wrote:
>
> I have just been working on setting up a continuous recovery failover
> system, and noticed some odd log lines, shown below. (Using 8.3).
>
> First note that our parsing of recovery.conf in xlog.c is pretty bad,
> and at least we need to document the quirks if it's not
On Sun, May 18, 2008 at 1:38 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> I don't know how you tested,
Copy a large file across a relatively slow network, and check the size
on the destination drive before it finishes.
> but could you please repeat the test with
> GnuWin32's cp.exe? If it do
Dave Page wrote:
On Tue, May 13, 2008 at 5:11 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
Andrew Dunstan wrote:
> I would be very surprised if xcopy did not exhibit the same
> preallocating behaviour as copy.
I, on the other hand, would not say anything until someone tried it, and
t
On Tue, May 13, 2008 at 5:11 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Andrew Dunstan wrote:
>
> > I would be very surprised if xcopy did not exhibit the same
> > preallocating behaviour as copy.
>
> I, on the other hand, would not say anything until someone tried it, and
> then wouldn't
Andrew Dunstan wrote:
> I would be very surprised if xcopy did not exhibit the same
> preallocating behaviour as copy.
I, on the other hand, would not say anything until someone tried it, and
then wouldn't be surprised if it behaved either way :-)
--
Alvaro Herrera
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Another and probably simpler thing to try would be the GnuWin32 version
of cp. If we can verify that it behaves itself, we should probably
recommend it for use in archive_command instead of the native Windows
copy.
Perhaps use xcopy, w
Andrew Dunstan wrote:
> Another and probably simpler thing to try would be the GnuWin32 version
> of cp. If we can verify that it behaves itself, we should probably
> recommend it for use in archive_command instead of the native Windows
> copy.
Perhaps use xcopy, which should be more ubiquit
I wrote:
However, we should probably make the behaviour switchable. If the
archive_command populating the archive_directory were rsync, for
example, this problem should not occur, because it copies to a temp
file, and then renames it, so we should never see an incomplete file
even though rs
Simon Riggs wrote:
On Tue, 2008-05-13 at 08:42 +0100, Dave Page wrote:
On Tue, May 13, 2008 at 2:38 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Simon Riggs wrote:
>> Well, the patch was rejected long ago, not sure why its in t
On Tue, 2008-05-13 at 08:42 +0100, Dave Page wrote:
> On Tue, May 13, 2008 at 2:38 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >
> > > Simon Riggs wrote:
> > >> Well, the patch was rejected long ago, not sure why its in this
> > >> commitfest. But its
On Tue, May 13, 2008 at 2:38 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>
> > Simon Riggs wrote:
> >> Well, the patch was rejected long ago, not sure why its in this
> >> commitfest. But its an open issue on the Windows port.
>
> > Surely the right fix i
On Mon, 2008-05-12 at 22:40 -0400, Andrew Dunstan wrote:
>
> Robert Treat wrote:
> > On Monday 12 May 2008 18:58:37 Andrew Dunstan wrote:
> >
> >> Simon Riggs wrote:
> >>
> Lastly, not quite related to this output, but in the same general area,
> should we have an option on pg_st
On Mon, 2008-05-12 at 23:03 -0400, Andrew Dunstan wrote:
> Tom Lane wrote:
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >> Simon Riggs wrote:
> >>
> >>> Well, the patch was rejected long ago, not sure why its in this
> >>> commitfest. But its an open issue on the Windows port.
> >>>
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Simon Riggs wrote:
Well, the patch was rejected long ago, not sure why its in this
commitfest. But its an open issue on the Windows port.
Surely the right fix is to use the recently implemented
pgwin32_safestat()
Robert Treat wrote:
On Monday 12 May 2008 18:58:37 Andrew Dunstan wrote:
Simon Riggs wrote:
Lastly, not quite related to this output, but in the same general area,
should we have an option on pg_standby to allow removing the archive
file after it has been restored?
There alr
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> Well, the patch was rejected long ago, not sure why its in this
>> commitfest. But its an open issue on the Windows port.
> Surely the right fix is to use the recently implemented
> pgwin32_safestat() (if we aren't already - I sus
Simon Riggs wrote:
On Mon, 2008-05-12 at 18:58 -0400, Andrew Dunstan wrote:
No, it had to do with pg_standby waiting for a WAL file that had already
gone, somehow. I will try to reproduce it when I get a spare moment.
Sounds like the bug I just fixed.
Yes, so I see. I didn't
On Monday 12 May 2008 18:58:37 Andrew Dunstan wrote:
> Simon Riggs wrote:
> >> Lastly, not quite related to this output, but in the same general area,
> >> should we have an option on pg_standby to allow removing the archive
> >> file after it has been restored?
> >
> > There already is one, but it
On Mon, 2008-05-12 at 18:58 -0400, Andrew Dunstan wrote:
> No, it had to do with pg_standby waiting for a WAL file that had already
> gone, somehow. I will try to reproduce it when I get a spare moment.
Sounds like the bug I just fixed.
> > There is an outstanding Windows issue with pg_stan
Simon Riggs wrote:
What is more, I apparently managed to get the recovery
server to lose a WAL file and hang totally by having a bad
recovery.conf. Triple ick.
Sounds like a bug you should report in the normal way. Correctness is
paramount. Or are you confusing the message in the l
On Mon, 2008-05-12 at 16:57 -0400, Andrew Dunstan wrote:
> I have just been working on setting up a continuous recovery failover
> system, and noticed some odd log lines, shown below. (Using 8.3).
Hmmm, well, the first time you use something complex, there are some
surprising features, I guess.
I have just been working on setting up a continuous recovery failover
system, and noticed some odd log lines, shown below. (Using 8.3).
First note that our parsing of recovery.conf in xlog.c is pretty bad,
and at least we need to document the quirks if it's not going to be
fixed. log_restart
24 matches
Mail list logo
