On Wed, 2002-07-10 at 01:09, Lamar Owen wrote:
> On Tuesday 09 July 2002 04:17 pm, Hannu Krosing wrote:
> > On Tue, 2002-07-09 at 22:10, Lamar Owen wrote:
> > > The pre-upgrade script is run in an environment that isn't robust enough
> > > to handle that. What if you run out of disk space during the dump?
>
> > You can either check beforehand or abort and delete the offending
> > dumpfile.
>
...
> > That's what I propose - dump all databases in pre-upgrade (if you are
> > concerned about disk usage, run it twice, first to | wc and then to a
> > file) and try to load in post-upgrade.
>
> The wc utility isn't in the path in an OS install situation. The df utility
> isn't in the path, either. You can use python, though. :-) Not that that
> would be a good thing in this context, however.
Why not ?
The following is wc in python
#!/usr/bin/python
import sys, string
bytes,words,lines = 0,0,0
while 1:
s = sys.stdin.readline()
if not s: break
bytes = bytes + len(s)
words = words + len(string.split(s))
lines = lines + 1
sys.stdout.write('%7d %7d %7d\n' % (lines,words,bytes))
And I have written custom postgres table dumpers in python without too
much effort (except reverse-engineering the page structure ;) for both
6.x and 7.x database tables, so we could actually use python here too.
The basic user_data extractor part is done in about 50 lines - I did not
need much else as I wrote custom datatype converters for the specific
table I needed.
The generic part ( conversions and determining if tuples are live)
should also not bee too difficult.
The only part I can see right away as hard to re-implement in python is
TOAST.
Still I guess that the basic db_dump.py app will be somewhere between
500 and 5000 lines long, with possibly the toast compression module done
as c-language module modtoast.so
The only problem with this approach is that it needs maintaining
separately from postgres proper. OTOH, this may also be a good thing, as
a separate reimplementation is only known working guarantee that we
actually know what our page format is ;) as the docs have always been
wrong about this.
> Again I say -- would such a data dumper not be useful in cases of system
> catalog corruption that prevents a postmaster from starting? I'm talking
> about a multipurpose utility here, not just something to make my life as RPM
> maintainer easy.
>
> The pg_fsck program is a good beginning to such a program.
Where can I fing pg_fsck ?
It is not in recent CVS snapshots.
-------------
Hannu
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
