Skip site navigation (1) Skip section navigation (2)

Re: Segfault Exiting psql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Wheeler <david(at)justatheory(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>,Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: Segfault Exiting psql
Date: 2005-08-28 18:04:43
Message-ID: 25600.1125252283@sss.pgh.pa.us (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackers
Awhile back I wrote:
> Hmm, I don't see that symptom, but I do see some strange stuff building
> PG CVS tip on a fully-up-to-date (10.4.2) OS X machine.
> ...
> Second, at exit from an interactive psql session,

> regression=# \q
> could not save history to file "/Users/tgl/.psql_history": Invalid argument
> $

I looked into this and found that psql is preferentially linking to the
version of libedit that Apple supplies (even though I had GNU readline
in /usr/local/lib).  And as best I can tell, in libedit the
write_history() function returns the number of items written to the
history file, rather than 0-on-success as our code is expecting.
So we print out a bogus error report mentioning the prior value of errno.

I'm not sure if this behavior is common to all versions of libedit,
but consulting Apple's source at
http://www.opensource.apple.com/darwinsource/10.3/libedit-3/libedit/history.c
makes it clear (look at history_save() about 3/4ths of the way down).
The function actually fails to detect I/O errors at all, other than
failure of the initial open() call.

What I'm kind of inclined to do is change our saveHistory() function
to not look at the return value of write_history() at all, but instead
do

	errno = 0;
	write_history(fname);  /* return value is not standardized */
	if (errno)
		print message;

Anyone have a better idea?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2005-08-28 18:17:49
Subject: Re: Win32 Thread safetyness
Previous:From: Stefan KaltenbrunnerDate: 2005-08-28 17:28:37
Subject: Re: small pg_dumpall bug/warning in 8.1beta1

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group