g executed so it should be possible
to tell what's wrong.
--
Ragnar Kjørstad
system is operational
though. I once heard that one of the major db-companies (Oracle?) were
going to start doing this on the default configuration because it would
eliminate all the problems with clueless users that "found" a free
partition and started using it for something else :)
--
Ragnar Kjørstad
Big Storage
implementation is new, acknowledged to be incomplete, and
> so far as I can tell requires additional work on startup
>
> Indeed re-loading a pg_dump will take lots more time, but that's why I
> want my DB backups to be done both as a ready-to-roll set of file images
> as
space - it doesn't say that
you need to manually UNDO them. It doesn't say specificly that you
_don't_, but it's the only thing that makes sense; primarely because
it's impossible to do manual UNDO. (what if a transaction updated an
index but didn't get around to update the table, or the other way around
- how do you fix that manually?)
--
Ragnar Kjørstad
Big Storage
ould be
faster. But postgresql doesn't do many of those.
Syncrounous data-updates (write/append): no - because postgresql
already do the writes to a log so there are no seeks involved in the
sync writes. (the writes to the actual files happens asyncrounous).
So there is a theoretical improvement, but it's not likely to show up on
a typical SQL-benchmark...
--
Ragnar Kjørstad
Big Storage
e on an arbitrary platform.
Yes; unfortenately this is not even possible with pg_dump. (it is better
than a filesystem backup in this regard, but there are still
version-incompabilities that have to be fixed manually)
--
Ragnar Kjørstad
Big Storage
e inode-metadata on fsync(), but they do not update the
> >directory.
>
> The Unix Fast File System is not a log/journaling filesystem. However
> it does not suffer the problems you're worried about.
That depends on what UFS-variation you're refering to, but it may very
well be true for some. (e.g. UFS in solaris8 does optional logging)
> Wasn't this question originally about FreeBSD anyway?
I suppose it was.
--
Ragnar Kjørstad
Big Storage
une 19, 2002 at 23:53:14 (+0200), Ragnar Kjørstad wrote: ]
> > Subject: Re: Backing up PostgreSQL?
> >
> > By this definition postgresql is consistant at all times
>
> That's simply not possible to be true. PostgreSQL uses multiple files
> in the filesystem namespa
an atomic dump of all databases,
so if you have a weird frontend that uses multiple databases and
expect them to be consistant)
* No additional CPU-load on the database-server
The space-problem with pg_dump is not a fundamental pg_dump problem BTW.
If someone wrote a amanda plugin to backup
On Fri, Jun 14, 2002 at 09:15:15PM -0400, Greg A. Woods wrote:
> [ On Saturday, June 15, 2002 at 00:45:12 (+0200), Ragnar Kjørstad wrote: ]
> > Subject: Re: Backing up PostgreSQL?
> >
> > snapshots (LVM snapshots) are not "supposedly nearly instantaneous", but
sistent.
If they hadn't been, you would not be able to recover from a crash /
powerfailure.
--
Ragnar Kjørstad
Big Storage
erhead to
other processes?
Of course, if the database is mostly read-only this is just a minor
problem, but that's true for snapshot-backups as well.
--
Ragnar Kjørstad
Big Storage
On Thu, Jun 13, 2002 at 04:57:16PM -0500, Kirk Strauser wrote:
>
> At 2002-06-13T21:26:22Z, Ragnar Kjørstad <[EMAIL PROTECTED]> writes:
>
> > The easiest way to snapshot the filesystem is to use a logical volume
> > manager (LVM or EVMS on linux) and then do:
> &g
u can
snapshot your filesystem and then use regular backup.
The easiest way to snapshot the filesystem is to use a logical volume
manager (LVM or EVMS on linux) and then do:
1. take database offline
2. take snapshot
3. take database online
4. backup from snapshot
5. remove snapshot
--
Ragnar Kjørstad
Big Storage
On Tue, Aug 14, 2001 at 10:34:58AM -0400, Rivera, Edwin wrote:
> i've been trying to get amanda to backup one of my DEC boxes for the past
> couple of days, but i can't seem to get it going on the 5.1 flavor. works
> fine on my 4.0f and 4.0d boxes. am i doing something weird?.. i've tried
> all
On Tue, Aug 14, 2001 at 09:05:25AM -0500, Katrinka Dall wrote:
> FAILED AND STRANGE DUMP DETAILS:
>
> /-- xx.p /dev/sdb1 lev 0 FAILED ["data write: File too large"]
Does it fail after backing up 2 Gigabyte?
It sounds like you don't have Large File Support (LFS).
> sendbackup: start [
16 matches
Mail list logo
