Re: (A) native Windows port - Mailing list pgsql-hackers
| From | Hannu Krosing |
|---|---|
| Subject | Re: (A) native Windows port |
| Date | |
| Msg-id | 1026306694.11767.40.camel@taru.tm.ee Whole thread Raw |
| In response to | Re: (A) native Windows port (Lamar Owen <lamar.owen@wgcr.org>) |
| Responses |
Re: (A) native Windows port
|
| List | pgsql-hackers |
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
pgsql-hackers by date: