Re: pg_dumplo, thanks :) (fwd) - Mailing list pgsql-hackers

From Don Baccus
Subject Re: pg_dumplo, thanks :) (fwd)
Date
Msg-id 3.0.1.32.20000406103311.013fcec0@mail.pacifier.com
Whole thread Raw
In response to Re: pg_dumplo, thanks :) (fwd)  (Karel Zak <zakkr@zf.jcu.cz>)
Responses Re: pg_dumplo, thanks :) (fwd)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: pg_dumplo, thanks :) (fwd)  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
At 06:17 PM 4/6/00 +0200, Karel Zak wrote:
>
>On Thu, 6 Apr 2000, Don Baccus wrote:
>
>> If it runs as a separate utility, there's no way for it to guarantee
>> a dump consistent with the previous run of pg_dump, right?
>
> If you dump your tables via pg_dump and promptly you dump LO via
>pg_dumplo, IMHO you not have problem with DB consistency.

Folks who have popular web sites with a world-wide audience don't have
the traditional early-morning "quiet periods", etc that local databases
tend to enjoy.  Since my group of folks are distributing a web toolkit
for general use, I tend to think in very general terms and any solution
we distribute wants to be very general, as well.

In the vast majority of cases, you're right that the odds would be low
of a problem cropping up in reality, but the odds aren't zero unless
you knock out all other db uses while dumping.

For our toolkit, I don't really care because we have our own BLOB-ish
hack for storing photos, word documents, etc using some SQL and AOLserver
driver magic I wrote, and these are pg_dumpable.

My main reason for bringing up the point was:

>> So wouldn't it be better to fold pg_dumplo into pg_dump?

and you seem to agree:

>Yes. If I good remember, anyone plan rewrite pg_dump. Or not? If not, I can
>rewrite it, because I very need good backup tools (I have important large 
>databases (with LO too)). 

So I think we're on the same wavelength.

Since you've conveniently made a post that reached my mailbox right after
a query from someone working on our toolkit port from Oracle to PG, did you 
know that in Oracle to_char formatting chars don't have to be upper case?

In other words something like "to_char(sysdate, 'yyyy-mm-dd')" formats
sysdate rather than ignore the formatting characters.  Turns out the
toolkit we're porting from Oracle almost always uses upper case, but
not always and one of our gang just ran into this earlier this morning
while porting over one of the toolkit module...

BTW, I can't begin to tell you how much easier our porting job is due
to the existence of to_char...





- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Vacuuming temporary tables
Next
From: Don Baccus
Date:
Subject: Re: Book and TEMP vs. TEMPORARY