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:
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
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 is
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 it
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:
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.
There
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
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
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
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
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
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
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 :(
That
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 doesn't,
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 from before
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
- checks
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
19 matches
Mail list logo
