Windows on SuSE? 7.4

That line is certainly strange:

#0 0x40099ac5 in dllname () from /usr/lib/libwsock32.so

When you run configure, it says you are on Linux, right?

My guess is that gdb is getting confused because there is no dllopen
call in StreamServerPort().

---------------------------------------------------------------------------

elein wrote:

SuSE 7.3, PostgreSQL cvshead (7.4)

This is as far as I've gotten with 7.4.
It is built and configured like my 7.3 installation
on the same machine. I have built from CVS previously.
And the production sources always builds very nice and clean.

Nothing runs. gbd output is below. It is balking
on loading a suspect library.

I ordinarily would suspect some minor permission
or configuration issue, but I cannot see one.

Joe Conway suggested it might be a problem with the
the windows configuration changes.

My machine has WINE on it (windows) although
I never use it. There really should be no
reason for anything to be trying to link
in a windows socket library.

I don't have time to follow it further right now.
But if someone else has a similar configuration
and/or wine installed, it would be very helpful
to compare 7.4 installations. I can provide
config arguments and log if someone would find
them useful.

gdb bin/postmaster

GNU gdb 20010316
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-suse-linux"...
(gdb) run -i -D /local/pghead/data
Starting program: /local/pghead/bin/postmaster -i -D /local/pghead/data

Program received signal SIGSEGV, Segmentation fault.
0x40099ac5 in dllname () from /usr/lib/libwsock32.so
(gdb) bt
#0 0x40099ac5 in dllname () from /usr/lib/libwsock32.so
#1 0x08121821 in StreamServerPort ()
#2 0x08150996 in PostmasterMain ()
#3 0x08123353 in main ()
#4 0x4010e7ee in __libc_start_main () from /lib/libc.so.6

elein@varlena.com

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

elein <elein@norcov.com> writes:

This is as far as I've gotten with 7.4.

Would you rebuild with --enable-debug (perhaps also --enable-cassert)
so that the gdb backtrace is more informative?

Also, it seems likely that the issue is in or around the recently-added
IPv6 support, so I'd suggest using CVS tip or last night's snapshot
rather than the beta1 tarball. We've already made some portability
fixes there since beta1.

regards, tom lane

cassert was on. Now debug is on, too.
I updated from cvs-head just now.

configure knows it is a linux box.
Should it be trying to link to libwsock32.so
or not? If this is a legitimate link, then
the problem is different than if it is trying
to link it in erroneously.

--elein

The is the top of the config.log
---------------------
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by PostgreSQL configure 7.4beta1, which was
generated by GNU Autoconf 2.53. Invocation command line was

$ ./configure --prefix=/local/pghead --with-perl --with-python --enable-depend --enable-cassert --enable-d
ebug

## --------- ##
## Platform. ##
## --------- ##

hostname = cookie
uname -m = i686
uname -r = 2.4.16-4GB
uname -s = Linux
uname -v = #1 Mon Apr 15 08:57:26 GMT 2002
---------------------

$ gdb postmaster
GNU gdb 20010316
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-suse-linux"...
(gdb) run -i -D /local/pghead/data
Starting program: /local/pghead/bin/postmaster -i -D /local/pghead/data

Program received signal SIGSEGV, Segmentation fault.
0x40099ac5 in dllname () from /usr/lib/libwsock32.so
(gdb) bt
#0 0x40099ac5 in dllname () from /usr/lib/libwsock32.so
#1 0x081218b1 in StreamServerPort (family=0, hostName=0x0, portNumber=5432, unixSocketName=0x82d6e68 "",
ListenSocket=0x829b420, MaxListen=10) at pqcomm.c:279
#2 0x08150a26 in PostmasterMain (argc=4, argv=0x82cfae8) at postmaster.c:765
#3 0x081233e3 in main (argc=4, argv=0xbffff414) at main.c:215
#4 0x4010e7ee in __libc_start_main () from /lib/libc.so.6

elein <elein@norcov.com> writes:

configure knows it is a linux box.
Should it be trying to link to libwsock32.so
or not? If this is a legitimate link, then
the problem is different than if it is trying
to link it in erroneously.

configure is unconditionally including libwsock32 if it can find one.
AFAICT from the CVS logs, this was only expected to happen on win32
(Bruce, that was your commit, configure.in v1.250; please confirm).
So it would probably make sense to not look for libwsock32 unless
PORTNAME is "win32".

I take it you actually have a libwsock32? What's it supposed to do?

regards, tom lane

Yes, I actually have a libwsock32 because my
system has wine on it. Wine is a windows
emulator.

So the assumption that any system with that
file is a windows system will break on
systems with windows emulators.

It sounds like Joe's guess on this was right.

--elein

I blame SuSE.

Thank you for the fix and confirmation of the problem.

elein

elein <elein@norcov.com> writes:

Yes, I actually have a libwsock32 because my
system has wine on it. Wine is a windows
emulator.

And they drop windows-only libraries into /usr/lib? Yech.

Anyway, I can't see a need to include libwsock32 on non-win32 platforms.
Will modify configure.

regards, tom lane

elein <elein@norcov.com> writes:

It sounds like Joe's guess on this was right.

I've committed this fix in configure.in:

***************
*** 631,637 ****
  AC_CHECK_LIB(gen,      main)
  AC_CHECK_LIB(PW,       main)
  AC_CHECK_LIB(resolv,   main)
- AC_CHECK_LIB(wsock32,   main)
  AC_SEARCH_LIBS(getopt_long, [getopt gnugetopt])
  # QNX:
  AC_CHECK_LIB(unix, main)
--- 636,641 ----
***************
*** 645,650 ****
--- 649,659 ----
  AC_SEARCH_LIBS(fdatasync, [rt posix4])
  # Cygwin:
  AC_CHECK_LIB(cygipc, shmget)
+ # WIN32:
+ if test "$PORTNAME" = "win32"
+ then
+ 	AC_CHECK_LIB(wsock32, main)
+ fi

if test "$with_readline" = yes; then
PGAC_CHECK_READLINE

regards, tom lane

On Mon, 2003-08-11 at 13:44, elein wrote:

Yes, I actually have a libwsock32 because my
system has wine on it. Wine is a windows
emulator.

Wine Is Not an Emulator :-)

Robert Treat
--
PostgreSQL :: The Enterprise Open Source Database

Yes, this is the right fix. I never suspected wsock32 would exist on a
non-MS WIn machine.

---------------------------------------------------------------------------

Tom Lane wrote:

elein <elein@norcov.com> writes:

It sounds like Joe's guess on this was right.

I've committed this fix in configure.in:

***************
*** 631,637 ****
AC_CHECK_LIB(gen,      main)
AC_CHECK_LIB(PW,       main)
AC_CHECK_LIB(resolv,   main)
- AC_CHECK_LIB(wsock32,   main)
AC_SEARCH_LIBS(getopt_long, [getopt gnugetopt])
# QNX:
AC_CHECK_LIB(unix, main)
--- 636,641 ----
***************
*** 645,650 ****
--- 649,659 ----
AC_SEARCH_LIBS(fdatasync, [rt posix4])
# Cygwin:
AC_CHECK_LIB(cygipc, shmget)
+ # WIN32:
+ if test "$PORTNAME" = "win32"
+ then
+ 	AC_CHECK_LIB(wsock32, main)
+ fi

if test "$with_readline" = yes; then
PGAC_CHECK_READLINE

regards, tom lane

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian commented:

"Uh, the ext2 developers say it isn't 100% reliable" ... "I mentioned
it while I was visiting Red Hat, and they didn't refute it."

1. Nobody has gone through any formal proofs, and there are few
systems _anywhere_ that are 100% reliable. NASA has occasionally lost
spacecraft to software bugs, so nobody will be making such rash claims
about ext2.

2. Several projects have taken on the task of introducing journalled
filesystems, most notably ext3 (sponsored by RHAT via Stephen Tweedy)
and ReiserFS (oft sponsored by SuSE). (I leave off JFS/XFS since they
existed long before they had any relationship with Linux.)

Participants in such projects certainly have interest in presenting
the notion that they provide improved reliability over ext2.

3. There is no "apologist" for ext2 that will either (stupidly and
futilely) claim it to be flawless. Nor is there substantial interest
in improving it; the sort people that would be interested in that sort
of thing are working on the other FSes.

This also means that there's no one interested in going into the
guaranteed-to-be-unsung effort involved in trying to prove ext2 to be
"formally reliable."

4. It would be silly to minimize the impact of commercial interest.
RHAT has been paying for the development of a would-be ext2 successor.
For them to refute your comments wouldn't be in their interests.

Note that these are "warm and fuzzy" comments, the whole lot. The
80-some thousand lines of code involved in ext2, ext3, reiserfs, and
jfs are no more amenable to absolute mathematical proof of reliability
than the corresponding BSD FFS code.

6. Such efforts would be futile, anyways. Disks are mechanical
devices, and, as such, suffer from substantial reliability issues
irrespective of the reliability of the software. I have lost sleep on
too many occasions due to failures of:
a) Disk drives,
b) Disk controllers [the worst Oracle failure I encountered resulted
from this], and
c) OS memory management.

I used ReiserFS back in its "bleeding edge" days, and find myself a
lot more worried about losing data to flakey disk controllers.

It frankly seems insulting to focus on ext2 in this way when:

a) There aren't _hard_ conclusions to point to, just soft ones;

b) The reasons for you hearing vaguely negative things about ext2
are much more likely political than they are technical.

I wish there were more "hard and fast" conclusions to draw, to be able
to conclusively say that one or another Linux filesystem was
unambiguously preferable for use with PostgreSQL. There are not
conclusive metrics, either in terms of speed or of some notion of
"reliability." I'd expect ReiserFS to be the poorest choice, and for
XFS to be the best, but I only have fuzzy reasons, as opposed to
metrics.

The absence of measurable metrics of the sort is _NOT_ a proof that
(say) FreeBSD is conclusively preferable, whatever your own
preferences (I'll try to avoid characterizing it as "prejudices," as
that would be unkind) may be. That would represent a quite separate
debate, and one that doesn't belong here, certainly not on a thread
where the underlying question was "Which Linux FS is preferred?"

If the OSDB TPC-like benchmarks can get "packaged" up well enough to
easily run and rerun them, there's hope of getting better answers,
perhaps even including performance metrics for *BSD. That, not
Linux-baiting, is the answer...
--
select 'cbbrowne' || '@' || 'acm.org';
http://www.ntlug.org/~cbbrowne/sap.html
(eq? 'truth 'beauty) ; to avoid unassigned-var error, since compiled code
; will pick up previous value to var set!-ed,
; the unassigned object.
-- from BBN-CL's cl-parser.scm

As I remember, there were clear cases that ext2 would fail to recover,
and it was known to be a limitation of the file system implementation.
Some of the ext2 developers were in the room at Red Hat when I said
that, so if it was incorrect, they would hopefully have spoken up. I
addressed the comments directly to them.

To be recoverasble, you have to be careful how you sync metadata to
disk. All the journalling file systems, and the BSD UFS do that. I am
told ext2 does not. I don't know much more than that.

As I remember years ago, ext2 was faster than UFS, but it was true
because ext2 didn't guarantee failure recovery. Now, with UFS soft
updates, the have similar performance characteristics, but UFS is still
crash-safe.

However, I just tried google and couldn't find any documented evidence
that ext2 isn't crash-safe, so maybe I am wrong.

---------------------------------------------------------------------------

Christopher Browne wrote:

Bruce Momjian commented:

"Uh, the ext2 developers say it isn't 100% reliable" ... "I mentioned
it while I was visiting Red Hat, and they didn't refute it."

1. Nobody has gone through any formal proofs, and there are few
systems _anywhere_ that are 100% reliable. NASA has occasionally lost
spacecraft to software bugs, so nobody will be making such rash claims
about ext2.

2. Several projects have taken on the task of introducing journalled
filesystems, most notably ext3 (sponsored by RHAT via Stephen Tweedy)
and ReiserFS (oft sponsored by SuSE). (I leave off JFS/XFS since they
existed long before they had any relationship with Linux.)

Participants in such projects certainly have interest in presenting
the notion that they provide improved reliability over ext2.

3. There is no "apologist" for ext2 that will either (stupidly and
futilely) claim it to be flawless. Nor is there substantial interest
in improving it; the sort people that would be interested in that sort
of thing are working on the other FSes.

This also means that there's no one interested in going into the
guaranteed-to-be-unsung effort involved in trying to prove ext2 to be
"formally reliable."

4. It would be silly to minimize the impact of commercial interest.
RHAT has been paying for the development of a would-be ext2 successor.
For them to refute your comments wouldn't be in their interests.

Note that these are "warm and fuzzy" comments, the whole lot. The
80-some thousand lines of code involved in ext2, ext3, reiserfs, and
jfs are no more amenable to absolute mathematical proof of reliability
than the corresponding BSD FFS code.

6. Such efforts would be futile, anyways. Disks are mechanical
devices, and, as such, suffer from substantial reliability issues
irrespective of the reliability of the software. I have lost sleep on
too many occasions due to failures of:
a) Disk drives,
b) Disk controllers [the worst Oracle failure I encountered resulted
from this], and
c) OS memory management.

I used ReiserFS back in its "bleeding edge" days, and find myself a
lot more worried about losing data to flakey disk controllers.

It frankly seems insulting to focus on ext2 in this way when:

a) There aren't _hard_ conclusions to point to, just soft ones;

b) The reasons for you hearing vaguely negative things about ext2
are much more likely political than they are technical.

I wish there were more "hard and fast" conclusions to draw, to be able
to conclusively say that one or another Linux filesystem was
unambiguously preferable for use with PostgreSQL. There are not
conclusive metrics, either in terms of speed or of some notion of
"reliability." I'd expect ReiserFS to be the poorest choice, and for
XFS to be the best, but I only have fuzzy reasons, as opposed to
metrics.

The absence of measurable metrics of the sort is _NOT_ a proof that
(say) FreeBSD is conclusively preferable, whatever your own
preferences (I'll try to avoid characterizing it as "prejudices," as
that would be unkind) may be. That would represent a quite separate
debate, and one that doesn't belong here, certainly not on a thread
where the underlying question was "Which Linux FS is preferred?"

If the OSDB TPC-like benchmarks can get "packaged" up well enough to
easily run and rerun them, there's hope of getting better answers,
perhaps even including performance metrics for *BSD. That, not
Linux-baiting, is the answer...
--
select 'cbbrowne' || '@' || 'acm.org';
http://www.ntlug.org/~cbbrowne/sap.html
(eq? 'truth 'beauty) ; to avoid unassigned-var error, since compiled code
; will pick up previous value to var set!-ed,
; the unassigned object.
-- from BBN-CL's cl-parser.scm

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Mon, Aug 11, 2003 at 10:58:18PM -0400, Christopher Browne wrote:

1. Nobody has gone through any formal proofs, and there are few
systems _anywhere_ that are 100% reliable.

I think the problem is that ext2 is known to be not perfectly crash
safe. That is, fsck on reboot after a crash can cause, in some
extreme cases, recently-fscynced data to end up in lost+found/. The
data may or may not be recoverable from there.

I don't think anyone would object to such a characterisation of ext2.
It was not designed, ever, for perfect data safety -- it was designed
as a reasonably good compromise for most cases. _Every_ filesystem
entails some compromises. This happens to be the one entailed by
ext2.

For production use with valuable data, for my money (or, more
precisely, my time when a system panics for no good reason), it is
always worth the additional speed penalty to use something like
metadata journalling. Maybe others have more time to spare.

perhaps even including performance metrics for *BSD. That, not
Linux-baiting, is the answer...

I didn't see anyone Linux-baiting.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110

On Tue, 12 Aug 2003, Andrew Sullivan wrote:

On Mon, Aug 11, 2003 at 10:58:18PM -0400, Christopher Browne wrote:

1. Nobody has gone through any formal proofs, and there are few
systems _anywhere_ that are 100% reliable.

I think the problem is that ext2 is known to be not perfectly crash
safe. That is, fsck on reboot after a crash can cause, in some
extreme cases, recently-fscynced data to end up in lost+found/. The
data may or may not be recoverable from there.

I don't think anyone would object to such a characterisation of ext2.
It was not designed, ever, for perfect data safety -- it was designed
as a reasonably good compromise for most cases. _Every_ filesystem
entails some compromises. This happens to be the one entailed by
ext2.

For production use with valuable data, for my money (or, more
precisely, my time when a system panics for no good reason), it is
always worth the additional speed penalty to use something like
metadata journalling. Maybe others have more time to spare.

I think the issue here is if you are running with the async mount option,
then it is quite likely that your volume will be corrupted if there are
writes going on and power fails.

I'm pretty sure that as long as the partition is mounted sync, this isn't
a problem.

I have seen reports where ext3 caused the data corruption (old kernels,
2.4.4 and before I believe) problem, not ext2. I.e. the addition of
journaling caused data loss.

Given that possibility, it may well have been at one time that ext2 was a
safer bet than ext3.

perhaps even including performance metrics for *BSD. That, not
Linux-baiting, is the answer...

I didn't see anyone Linux-baiting.

No more than the typical, light hearted stuff we toss back and forth. I
certainly wasn't upset by any of it.

People:

On Mon, Aug 11, 2003 at 10:58:18PM -0400, Christopher Browne wrote:

1. Nobody has gone through any formal proofs, and there are few
systems _anywhere_ that are 100% reliable.

I think the problem is that ext2 is known to be not perfectly crash
safe. That is, fsck on reboot after a crash can cause, in some
extreme cases, recently-fscynced data to end up in lost+found/. The
data may or may not be recoverable from there.

Aside from that, as recently as eighteen months ago I had to manually fsck an
ext2 system after an unexpected power-out. After my interactive session the
system recovered and no data was lost. However, the client lost 3.5 hours of
work time ... 2.5 hours for me to get to the site, and 1 hour to recover the
server (mostly waiting time).

So it's a tradeoff with loss of performance vs. recovery time. In a server
room with redundant backup power supplies, "clean room" security and
fail-over services, I can certainly imagine that data journalling would not
be needed. That is, however, the minority ...

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Tue, Aug 12, 2003 at 09:36:21AM -0700, Josh Berkus wrote:

So it's a tradeoff with loss of performance vs. recovery time. In
a server room with redundant backup power supplies, "clean room"
security and fail-over services, I can certainly imagine that data
journalling would not be needed.

You can have all the redundant power, high availability hardware, and
ultra-Robocop security going, and still have crashes: so far as I
know, _nobody_ makes perfectly reliable hardware, and the harder you
push it, the more likely you are to find trouble. And certainly,
when you have a surprise outage because the CPU where the kernel
happened to be burned itself up, an extra hour or two offline while
you do fsck is liable to make you cry out variations of those four
letters more than once. :-/

A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110

Christopher, I appreciate your comments. At the end it goes down to personal
experience with one or the other file system. From that I can tell, that
I have
made good experience with UFS, EXT2, and XFS. I made catastrophic ex-
perience with ReiserFS (not during operation but you are a looser when
it fails
because the recovery methods are likely to be insufficient)

So at the end if somebody runs technical equipment, regardless whether it's
a computer or a chemical fab. It can fail and you need to make up your mind
about contingency.

This is due even before you start operating the equipment.

So waste too much time on thinking about the perfect file system. But
evaluate
the potential damage that can result from failure. Develop a Backup&Recovery
strategy and test it, test it and test it again, so that you can do it
blindly when it's
due.

Ciao, Toni