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: