Re: pg_dumplo, thanks :) (fwd)

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dumplo, thanks :) (fwd)
Date: 2000-04-06 17:33:11
Message-ID: 3.0.1.32.20000406103311.013fcec0@mail.pacifier.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Don Baccus 2000-04-06 17:45:40 RE: pg_dumplo, thanks :) (fwd)
Previous Message Don Baccus 2000-04-06 17:11:54 Re: Book and TEMP vs. TEMPORARY

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2000-04-06 18:05:55 Re: pg_dumplo, thanks :) (fwd)
Previous Message Karel Zak 2000-04-06 16:17:49 Re: pg_dumplo, thanks :) (fwd)