Re: (A) native Windows port

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