Re: pgwin32_open returning EINVAL - Mailing list pgsql-hackers

From Jaime Casanova
Subject Re: pgwin32_open returning EINVAL
Date
Msg-id c2d9e70e0712201759v35f667abq23b23d23f95a9ed9@mail.gmail.com
Whole thread Raw
In response to Re: pgwin32_open returning EINVAL  (Magnus Hagander <magnus@hagander.net>)
Responses Re: pgwin32_open returning EINVAL  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: pgwin32_open returning EINVAL  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Dec 20, 2007 3:29 PM, Magnus Hagander <magnus@hagander.net> wrote:
> Magnus Hagander wrote:
> > On Thu, Dec 20, 2007 at 10:26:46AM -0500, Tom Lane wrote:
> >> Magnus Hagander <magnus@hagander.net> writes:
> >>> On Wed, Dec 19, 2007 at 07:50:29PM -0500, Tom Lane wrote:
> >>>> 2. Do we really want this to be WARNING?  LOG seems a better idea,
> >>>> since it's not warning about anything the client app did wrong.
> >>> I put it as warning because I wanted to be sure the admin notices. If your
> >>> database is hanging 5+ seconds to open a file, you have a *big* problem,
> >>> and you need to fix it. Just putting it as LOG will probably make it much
> >>> more likely it's missed.
> >> This reasoning is faulty.  For logging purposes, LOG is *more* severe
> >> (higher priority) than WARNING.  I think it's fairly common to set
> >> log_min_messages = ERROR, which would mean that warnings disappear.
> >> On the client side, unless you're issuing queries by hand with psql,
> >> it's entirely likely that all non-error messages go into the bit bucket.
> >> You can't count on anyone ever noticing them in a production app.
> >>
> >> Use LOG.  That's what it's there for.  (If you want a more formal
> >> definition, I'd say it's for messages that a DBA would be interested in
> >> but are not directly relevant to a client app.)
> >
> > Ah, wasn't aware of that at all. Then LOG certainly makes a lot more sense,
> > yes. Thanks for clearifying.
>
> I've applied a patch for this to head, to get some proper buildfarming
> on it. If it passes the tests that Alvaro's contact will be running
> (since they had a reasonably repeatable case), I think we should
> backpatch it. But not until then...
>

it doesn't compile on current head on mingw 5.1 and msys 1.0.10; of
course, it doesn't compile on 8.2 neither in order to Alvaro's contact
to test it


gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
-DFRONTEND -I. -I../../../src/include -I./src/include/port/win32
-DEXEC_BACKEND  "-I../../../src/include/port/win32"
-I../../../src/port  -c -o pthread-win32.o pthread-win32.c
dllwrap  -o libpq.dll --dllname libpq.dll  --def libpqdll.def
fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o
fe-protocol2.o fe-protocol3.o pqexpbuffer.o pqsignal.o fe-secure.o
md5.o ip.o wchar.o encnames.o noblock.o pgstrcasecmp.o thread.o
crypt.o inet_aton.o strlcpy.o getaddrinfo.o open.o win32error.o
snprintf.o win32.o libpqrc.o pthread-win32.o  -L../../../src/port
-lshfolder -lwsock32 -lws2_32 -lsecur32
open.o:open.c:(.text+0x144): undefined reference to `pg_usleep'
collect2: ld returned 1 exit status
d:\mingw\bin\dllwrap.exe: d:\mingw\bin\gcc exited with status 1
make[3]: *** [libpq.a] Error 1
make[3]: Leaving directory
`/home/General/PG_RELEASES/pgsql-8.3/src/interfaces/libpq'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/General/PG_RELEASES/pgsql-8.3/src/interfaces'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/General/PG_RELEASES/pgsql-8.3/src'
make: *** [all] Error 2




-- 
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."                                      Richard Cook


pgsql-hackers by date:

Previous
From: Mark Mielke
Date:
Subject: Re: Sorting Improvements for 8.4
Next
From: Alvaro Herrera
Date:
Subject: Re: pgwin32_open returning EINVAL