Thread: Re: initdb fails - postgresql does not support leap seconds

Have now also tried:

downloading 8.2.2 and compiling it - no luck when running initdb (same
error)

rerunning configure with and without --with-includes=/mingw/include --
with-libraries=/mingw/lib (always running --without-zlib) - same error

I have been searching newsgroups, archives, etc. in hope someone has
seen this.  No luck there and no responses yet so I am including
hackers, I hope this is ok but am close to throwing in the towel (have
been throught the windows FAQ too).

I am a newcomer to PG development and wondering if there is light not
too far in the distance or if I can expect to wade through a lot more
of these problems before writing a line of code.  I was also hoping to
use MSVC++ but first things first, I would settle for a build under
msys/mingw that I can launch.

Windows does seem like the ugly stepchild for PG, would I be
significantly better off under Mac OS X (have it)?  Other Unix (would
have to buy it)?

Thanks again for any help...

Sorry, here's the first post, just now included hackers (more info in
previous post)...

The following error occurred when issuing a vanilla initdb command on
my Windows system.

FATAL:  could not select a suitable default timezone
DETAIL:  It appears that your GMT time zone uses leap seconds.
PostgreSQL does not support leap seconds.

I built this from 8.1.8 source (mingw/msys/gcc).  Configure, make and
make install were fine.

I previously ran just fine on version 8.1.5 (which I did not compile)
on the same system, no problems.

Didn't select anything unusual in configure either.

Thanks!

A little more info that might help: I had to put a hack into two .h
files (libpq.h, libpq-int.h) and add

typedef int ssize_t

to get things to compile.  I did notice that libpq-int.h had this
typedef inside an #ifdef WIN32_ONLY_COMPILER which apparently wasn't
triggered.

Can't remember if it was  in this forum, but a few people asked why I
was downloading source and not binary.  The reason is that I am
experimenting with a different indexing (multi-dimensional) method.

I looked hard at GiST, but it doesn't look like GiST supports multi-
dimensional indexing methods unless all the dimensions are in a single
column  (i.e. some type of composite UDT).  I need to see each column
in the index before making a decision about search paths to take,
branches to follow, etc.  GiST appears to support one column at a time
- i.e. if my index is lastname, firstname, then take a look at
lastname, and if that's a tie, then look at firstname.  But it won't
let you look at lastname and firstname at the same time, then make
decisions about what to do (if I am interpreting correctly).  I need
to evaluate each column in the index and compare it to all other index
entries in a given page.  But I would sure like to take advantage of
the general integration of GiST indexing into postgres, including
concurrency and recovery (as opposed to building this from scratch or
adapting the existing GiST code to do what I need).  Also, I don't
have the luxury of knowing the contents of my indexes in advance, so
putting together UDT's is out of the question for me.  If I missed
something here, let me know.

I'm a newcomer to postgres, and have scoured the normal docs at
www.postgresql.org as well as newsgroup/mailing lists going back
years.  I was hoping to find some development oriented docs too, if
anyone is aware of more resources.  I am reluctant to pepper a very
experienced community with dumb questions.

Help is much appreciated.