Brian Modra wrote:
The documentation about WAL says that you can start a live backup, as
long as you use WAL backup also.
I'm concerned about the integrity of the tar file. Can someone help me
with that?
If you are using point in time recovery:
http://www.postgresql.org/docs/8.2/static/contin
Sorry to be hammering this point, but I want to be totally sure its OK,
rather than 5 months down the line attempt to recover, and it fails...
Are you absolutely certain that the tar backup of the file that changed, is
OK? (And that even if that file is huge, tar has managed to save the file as
it
Hello,
On Mon, 14 Jan 2008 17:39:34 +0100 Sebastian Reitenbach wrote:
> Thomas Karcher <[EMAIL PROTECTED]> wrote:
> >
> > > this one is still open when I run pg_stop_backup(), so I want to trigger
> > > the archive_command to be sure that I don't miss anything.
> >
> > I guess what you want
You can be absolutely certain that the tar backup of a file that's changed is a
complete waste of time. Because it changed while you were copying it.
Steve.
On Wed, 16 Jan 2008 10:24:00 +0200
"Brian Modra" <[EMAIL PROTECTED]> wrote:
> Sorry to be hammering this point, but I want to be totally s
Hi,
Andreas 'ads' Scherbaum <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> On Mon, 14 Jan 2008 17:39:34 +0100 Sebastian Reitenbach wrote:
>
> > Thomas Karcher <[EMAIL PROTECTED]> wrote:
> > >
> > > > this one is still open when I run pg_stop_backup(), so I want to
trigger
> > > > the archive_com
Brian Modra wrote:
Sorry to be hammering this point, but I want to be totally sure its OK,
rather than 5 months down the line attempt to recover, and it fails...
Are you absolutely certain that the tar backup of the file that changed,
is OK?
Have you considered testing it?
Sincerely,
Josh
Steve Holdoway <[EMAIL PROTECTED]> writes:
> You can be absolutely certain that the tar backup of a file that's changed is
> a complete waste of time. Because it changed while you were copying it.
That is, no doubt, the reasoning that prompted the gnu tar people to
make it do what it does, but i
Am Mittwoch, 16. Januar 2008 schrieb Tom Lane:
> (Thinks for a bit...) Actually I guess there's one extra assumption in
> there, which is that tar must issue its reads in multiples of our page
> size. But that doesn't seem like much of a stretch.
There is something about that here:
http://www.gn
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 16. Januar 2008 schrieb Tom Lane:
>> (Thinks for a bit...) Actually I guess there's one extra assumption in
>> there, which is that tar must issue its reads in multiples of our page
>> size. But that doesn't seem like much of a stretch.
Brian Modra wrote:
Sorry to be hammering this point, but I want to be totally sure its
OK, rather than 5 months down the line attempt to recover, and it fails...
Are you absolutely certain that the tar backup of the file that
changed, is OK? (And that even if that file is huge, tar has manage
Hi, Brian
We have been doing PITR backups since the feature first became available
in postgresql. We first used tar, then, due to the dreadful warning
being emitted by tar (which made us doubt that it was actually archiving
that particular file) we decided to try CPIO, which actually emits mu
On Wed, 16 Jan 2008 10:19:12 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> Steve Holdoway <[EMAIL PROTECTED]> writes:
> > You can be absolutely certain that the tar backup of a file that's changed
> > is a complete waste of time. Because it changed while you were copying it.
>
> That is, no doubt
I am encountering a very strange client encoding issue.
>From the logs on the server, I am getting the following:
canopy02# tail postgresql-2008-01-16_00.log
2008-01-16 15:20:03 ESTERROR: conversion between latin9 and LATIN1 is
not supported
2008-01-16 15:20:03 ESTSTATEMENT: set client_enco
The encoding of the client can not be convertet to the encoding of the server.
In the manual in chapter 21.2 you can find the list of supported encodings and
possible conversions between them.
The conversion between latin1 and latin9 is not supported.
For a latin9 database you can use the client e
Ivo, thank you for responding.
I know what the error message is saying.
The database encoding is Latin1.
I do not know where the Latin9 encoding is coming from, since I do not
have anywhere any settings calling for a Latin9.
The database is accessed both by a php script on box as well as a remote
O
On 17/01/2008, at 4:42 AM, Tom Arthurs wrote:
The important thing is to start archiving the WAL files *prior* to
the first OS backup, or you will end up with an unusable data base.
Why does the recovery need WAL files from before the backup?
Tom
---(end of broadcast)
"Benjamin Krajmalnik" <[EMAIL PROTECTED]> writes:
> From the frequency of the requests, I am inclined to believe tht it is
> the emote connection. Unlike 8.1, 8.2 is not tagging the log message
> with the IP address of the client connection, so I cannot even ascertain
> the source of the error :(
Tom Davies <[EMAIL PROTECTED]> writes:
> On 17/01/2008, at 4:42 AM, Tom Arthurs wrote:
>> The important thing is to start archiving the WAL files *prior* to
>> the first OS backup, or you will end up with an unusable data base.
> Why does the recovery need WAL files from before the backup?
It d
On Jan 16, 2008 4:56 PM, Tom Davies <[EMAIL PROTECTED]> wrote:
>
> On 17/01/2008, at 4:42 AM, Tom Arthurs wrote:
> > The important thing is to start archiving the WAL files *prior* to
> > the first OS backup, or you will end up with an unusable data base.
>
> Why does the recovery need WAL files fr
If you don't start archiving log files, your first backup won't be valid
-- well I suppose you could do it the hard way and start the backup and
the log archiving at exactly the same time (can't picture how to time
that), but the point is you need the current log when you kick off the
backup.
[EMAIL PROTECTED] (Mischa Sandberg) writes:
>Unfortunately, with multiple jails running PG servers and (due to app
>limitations) all servers having same PGPORT, you get the situation that
>when jail#2 (,jail#3,...) server comes up, it:
>- detects that there is a shm seg with ipc key 5432001
>- che
"Benjamin Krajmalnik" <[EMAIL PROTECTED]> writes:
> The error is most definitely being generated by the ODBC connection.
> What can be causing the ODBC driver to set the client encoding to Latin9
> implicitly?
Dunno, but the folks who would know that hang out in the pgsql-odbc
list.
Additional info:
Thanks to Tom Lane, who pointed me in the right direction concerning the
logging to identify the connection creating the problem.
The error is most definitely being generated by the ODBC connection.
What can be causing the ODBC driver to set the client encoding to Latin9
implicit
23 matches
Mail list logo
