Simon Riggs wrote:
On Tue, 2007-06-05 at 18:39 +0200, Marco Colombo wrote:
I'm asking: what _exactly_ can go wrong?
If a checkpoint occurs while taking the backup then the contents of the
files will be overwritten
^
Data files or WAL segments? My archive command prevents WAL segments
f
Greg Smith wrote:
On Tue, 5 Jun 2007, Marco Colombo wrote:
AFAIK, files in pg_xlog are first renamed (and only if and after the
archive_command returned true) and later overwritten to. Never deleted.
No, they get deleted sometimes, too. Not often, but it can happen under
heavy load if more
On Tue, 5 Jun 2007, Marco Colombo wrote:
AFAIK, files in pg_xlog are first renamed (and only if and after the
archive_command returned true) and later overwritten to. Never deleted.
No, they get deleted sometimes, too. Not often, but it can happen under
heavy load if more segments get tempor
On Tue, 2007-06-05 at 18:39 +0200, Marco Colombo wrote:
> I'm asking: what _exactly_ can go wrong?
If a checkpoint occurs while taking the backup then the contents of the
files will be overwritten and you will be unable to rollforward from
before the backup until after the backup. This will give y
Simon Riggs wrote:
> Marco Colombo wrote:
my method
...is dangerous
Ok, but why? Once again, I'm asking: what _exactly_ can go wrong?
> so we don't get loads of new DBAs picking up this idea
but missing the exact point of danger.
I'm one of them. I'm _am_ missing the exact point of danger.
On Mon, 2007-06-04 at 12:55 +0200, Marco Colombo wrote:
> Greg Smith wrote:
> > The way you're grabbing
> > files directly from the xlog directory only works because your commit
> > workload is so trivial that you can get away with it, and because you
> > haven't then tried to apply future archi
Greg Smith wrote:
The way you're grabbing
files directly from the xlog directory only works because your commit
workload is so trivial that you can get away with it, and because you
haven't then tried to apply future archive logs.
Well, it's only because I don't need future logs, just like I
On Fri, 1 Jun 2007, Marco Colombo wrote:
If you need *both* a "full backup" *and* PITR, just add a real cp to the
archive_command above. The important part is to return failure during the
backup process, I think.
You seem to have worked out a way for your application to do a base backup
in a
Greg Smith wrote:
On Thu, 31 May 2007, Marco Colombo wrote:
archive_command = 'test ! -f /var/lib/pgsql/backup_lock Under normal condition (no backup running) this will trick PG into
thinking that segments get archived. If I'm not mistaken, PG should
behave exactly as if no archive_command is
On Wed, 2007-05-30 at 22:41 -0400, Greg Smith wrote:
> -Find something harmless I can execute in a loop that will generate WAL
> activity, run that until the segment gets archived. Haven't really
> thought of something good to use for that purpose yet.
create table xlog_switch as
select '0123
On Thu, 31 May 2007, Marco Colombo wrote:
archive_command = 'test ! -f /var/lib/pgsql/backup_lock Under normal condition (no backup running) this will trick PG into thinking
that segments get archived. If I'm not mistaken, PG should behave exactly as
if no archive_command is configured, and re
Greg Smith wrote:
[...]
-Find something harmless I can execute in a loop that will generate WAL
activity, run that until the segment gets archived. Haven't really
thought of something good to use for that purpose yet.
Some time ago I started a thread about taking on-the-fly backups at file
l
12 matches
Mail list logo
