Re: [HACKERS] ISN patch that applies cleanly with git apply
hi peter, > I would like to hear what people think of my observations about the > design of contrib/isn. In particular, I'd like Jan Otto to contribute > - he probably has more domain knowledge than I do. I haven't heard > from Jan about the proposed regression test. > > In producing this patch, did you work off the listing of all the > 628,000 assigned publisher codes that is only available in book form > at a cost of €558? How might I verify the correctness of the new > ISBN_range, preferably without spending €558?:-) no, i used only the official information from international isbn agency to produce this patch. Range Message (XML) from http://www.isbn-international.org/page/ranges we have much more information (payed) about publishers and its prefixes internally, but for hyphenation we dont need more information as provided in the above xml-file. additionally i put in support for the 979-prefix, because new ranges get applied to this new prefix. as far as i know old ranges will never change. regards, jan
Re: [HACKERS] ISN patch that applies cleanly with git apply
hi tom, >> Peter Eisentraut asked Jan to produce a regression test for the ISN >> contrib module, which he is apparently working on. I would like to see >> him more clearly explaining how that will work though - so far, it's >> really just been described in very broad strokes. > > Even more to the point, what about a link to the relevant changes in the > standard? It's impossible for anyone to tell whether these changes are > sane in a vacuum, and a regression test will prove nothing at all except > perhaps self-consistency. we can only prove self-consistency, because there is no algorithm behind the scene. the ranges gets applied to publishers depending on how much books they publishing over time and probably other criteria. of course, we can build regression-tests for checkdigits and convert-functions. e.g. convert an isbn-10 to isbn-13. regards, jan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] patch for contrib/isn
hi all, currently i am working on a big project for a german bookseller and publisher. one of the requirements was correct hyphenation of ISBN-13 for about 14.400.000 books in postgresql database. so added support for hyphenating isbn with the new 979-prefix and additionally added all missing ranges since year 2006 for isbn with 978-prefix. patch against HEAD is attached and validated against a lot of previously wrong and correct hyphenated isbn. regards, jan contrib_isn-1.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch for contrib/isn
On Aug 6, 2010, at 11:08 PM, Peter Eisentraut wrote: > On ons, 2010-08-04 at 19:32 +0200, Jan Otto wrote: >> patch against HEAD is attached and validated against a lot of >> previously wrong and correct hyphenated isbn. > > I think this module could use a regression test. i'll take a look at this within next days. regards, jan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] drop tablespace error: invalid argument
Jan Otto writes: ERROR: could not read directory "pg_tblspc/16464": Invalid argument STATEMENT: DROP TABLESPACE testspace; I have digged a bit around in the source code of postgresql to build a self contained test-case for Apple and found that the implementation of Apples readdir() is buggy. readdir() fails under some circumstances. So i have build a patch against current pgsql's HEAD to work around the issue. If the bug in readdir() goes into the final release snow leopard we have a solution. This patch basically frees dirdesc and rereads the tablespace location in case a subdirectory was deleted from the tablespace. this is the place where snow leopard fails to read the next entry with readdir(). The bug in readdir() appeared in the final snow leopard too. Anybody with Snow Leopard installed can check this, with simply doing the regression tests (make check). The tablespace regression test is failing. The patch i sent in works around the issue. if it is not acceptable to reread the tablespace-directory after every delete i can rewrite the workaround. Probably it is preferred that we write all entries of the directory into an array and looping through that array after that instead of looping with ReadDir()? regards, jan otto
Re: [HACKERS] More Snow Leopard fun: multiarch problems while building plperl
hi tom, Anyway, the long and the short of it is that we are extracting this value for perl_embed_ldflags: perl_embed_ldflags = -arch x86_64 -arch i386 -arch ppc -L/usr/ local/lib -L/System/Library/Perl/5.10.0/darwin-thread-multi-2level/ CORE -lperl -ldl -lm -lutil -lc and it seems to me that it's a pretty bad idea to have this switch collection trying to override the arch(es) that Postgres is actually being built for. Does anyone have an opinion about that pro or con? Anybody have an idea about a simple way to get rid of those switches? patch for file configure: 6811c6811 < perl_embed_ldflags=`echo X"$pgac_tmp1" | sed "s/^X//;s%$pgac_tmp2%%"` --- > perl_embed_ldflags=`echo X"$pgac_tmp1" | sed "s/^X//;s%$pgac_tmp2% %" | sed "s/-arch\ [a-zA-Z0-9_-]*//g"` $ configure --with-perl $ make -j8>build.log $ file src/pl/plperl/plperl.so src/pl/plperl/plperl.so: Mach-O 64-bit bundle x86_64 $ regards, jan otto -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More Snow Leopard fun: multiarch problems while building plperl
hi tom, $ file /System/Library/Perl/lib/5.10/libperl.dylib /System/Library/Perl/lib/5.10/libperl.dylib: Mach-O universal binary with 3 architectures /System/Library/Perl/lib/5.10/libperl.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 /System/Library/Perl/lib/5.10/libperl.dylib (for architecture i386):Mach-O dynamically linked shared library i386 /System/Library/Perl/lib/5.10/libperl.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc which I found rather surprising because I thought Snow Leopard had yanked out all support for PPC. However, there it is. But you do *not* these universal libraries are needed for older programs to run. you can run programs with ppc-architecture on snow leopard. and you probably need it if you cross-compile for a ppc-machine. $ file plperl.so plperl.so: Mach-O universal binary with 3 architectures plperl.so (for architecture x86_64):Mach-O 64-bit bundle x86_64 plperl.so (for architecture i386): Mach-O bundle i386 plperl.so (for architecture ppc): Mach-O bundle ppc another way is to extract the needed architectures after the build. e.g. for x86_64: ditto --rsrc --arch x86_64 libperl.so libperl.so.tmp && mv libperl.so.tmp libperl.so regards, jan otto -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More Snow Leopard fun: multiarch problems while building plperl
hi tom,
perl_embed_ldflags is currently the difference of
perl -MExtUtils::Embed -e ldopts
minus
perl -MConfig -e 'print $Config{ccdlflags}'
In that spirit, the answer would be to find something else in
ExtUtils
or Config that we can remove from ldopts.
As far as I can tell, there is nothing in Config that exposes just the
-arch switches without any other stuff. I'm inclined to go with Jan
Otto's solution of sed'ing out those switches by name. It's a bit
ugly
but should be safe.
Yes it is really ugly.
The problem here is that ARCHFLAGS is not set. If it is set correctly
the ldopts would be correctly set:
$ export ARCHFLAGS="-arch x86_64"
$ perl -MExtUtils::Embed -e ldopts
-arch x86_64 -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-
thread-multi-2level/CORE -lperl -ldl -lm -lutil -lc
$
if ARCHFLAGS is not set Config_heavy.pl puts '-arch x86_64 -arch i386 -
arch ppc' in by default:
$ unset ARCHFLAGS
$ perl -MExtUtils::Embed -e ldopts
-L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-thread-
multi-2level/CORE -lperl -ldl -lm -lutil -lc
$
more elegant would be something like this instead of 'perl -
MExtUtils::Embed -e ldopts'
[ "$ARCHFLAGS" ] || export ARCHFLAGS=""; perl -MExtUtils::Embed -e
ldopts
example:
$ export ARCHFLAGS="-arch x86_64"
$ [ "$ARCHFLAGS" ] || export ARCHFLAGS=""; perl -MExtUtils::Embed -e
ldopts
-arch x86_64 -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-
thread-multi-2level/CORE -lperl -ldl -lm -lutil -lc
$ unset ARCHFLAGS
$ [ "$ARCHFLAGS" ] || export ARCHFLAGS=""; perl -MExtUtils::Embed -e
ldopts
-L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-thread-
multi-2level/CORE -lperl -ldl -lm -lutil -lc
$
so we make shure if somebody tries to build an universal binary of
postgres by setting the correct ARCHFLAGS
the configure works too.
patch against HEAD:
diff -c -r1.653 configure
*** configure 26 Aug 2009 22:24:41 - 1.653
--- configure 8 Sep 2009 17:47:29 -
***
*** 6941,6947
{ $as_echo "$as_me:$LINENO: checking for flags to link embedded
Perl" >&5
$as_echo_n "checking for flags to link embedded Perl... " >&6; }
! pgac_tmp1=`$PERL -MExtUtils::Embed -e ldopts`
pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
perl_embed_ldflags=`echo X"$pgac_tmp1" | sed "s/^X//;s%$pgac_tmp2%%"`
if test -z "$perl_embed_ldflags" ; then
--- 6941,6947
{ $as_echo "$as_me:$LINENO: checking for flags to link embedded
Perl" >&5
$as_echo_n "checking for flags to link embedded Perl... " >&6; }
! pgac_tmp1=`[ "$ARCHFLAGS" ] || export ARCHFLAGS=""; $PERL -
MExtUtils::Embed -e ldopts`
pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
perl_embed_ldflags=`echo X"$pgac_tmp1" | sed "s/^X//;s%$pgac_tmp2%%"`
if test -z "$perl_embed_ldflags" ; then
regards, jan otto
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More Snow Leopard fun: multiarch problems while building plperl
The problem here is that ARCHFLAGS is not set. If it is set correctly
the ldopts would be correctly set:
$ export ARCHFLAGS="-arch x86_64"
$ perl -MExtUtils::Embed -e ldopts
-arch x86_64 -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-
thread-multi-2level/CORE -lperl -ldl -lm -lutil -lc
$
if ARCHFLAGS is not set Config_heavy.pl puts '-arch x86_64 -arch
i386 -arch ppc' in by default:
$ unset ARCHFLAGS
$ perl -MExtUtils::Embed -e ldopts
-L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-thread-
multi-2level/CORE -lperl -ldl -lm -lutil -lc
$
sorry wrong pasted:
$ unset ARCHFLAGS
$ perl -MExtUtils::Embed -e ldopts
-arch x86_64 -arch i386 -arch ppc -L/usr/local/lib -L/System/
Library/Perl/5.10.0/darwin-thread-multi-2level/CORE -lperl -ldl -lm -
lutil -lc
$
more elegant would be something like this instead of 'perl -
MExtUtils::Embed -e ldopts'
[ "$ARCHFLAGS" ] || export ARCHFLAGS=""; perl -MExtUtils::Embed -e
ldopts
example:
$ export ARCHFLAGS="-arch x86_64"
$ [ "$ARCHFLAGS" ] || export ARCHFLAGS=""; perl -MExtUtils::Embed -e
ldopts
-arch x86_64 -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-
thread-multi-2level/CORE -lperl -ldl -lm -lutil -lc
$ unset ARCHFLAGS
$ [ "$ARCHFLAGS" ] || export ARCHFLAGS=""; perl -MExtUtils::Embed -e
ldopts
-L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-thread-
multi-2level/CORE -lperl -ldl -lm -lutil -lc
$
so we make shure if somebody tries to build an universal binary of
postgres by setting the correct ARCHFLAGS
the configure works too.
patch against HEAD:
diff -c -r1.653 configure
*** configure 26 Aug 2009 22:24:41 - 1.653
--- configure 8 Sep 2009 17:47:29 -
***
*** 6941,6947
{ $as_echo "$as_me:$LINENO: checking for flags to link embedded
Perl" >&5
$as_echo_n "checking for flags to link embedded Perl... " >&6; }
! pgac_tmp1=`$PERL -MExtUtils::Embed -e ldopts`
pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
perl_embed_ldflags=`echo X"$pgac_tmp1" | sed "s/^X//;s%$pgac_tmp2%%"`
if test -z "$perl_embed_ldflags" ; then
--- 6941,6947
{ $as_echo "$as_me:$LINENO: checking for flags to link embedded
Perl" >&5
$as_echo_n "checking for flags to link embedded Perl... " >&6; }
! pgac_tmp1=`[ "$ARCHFLAGS" ] || export ARCHFLAGS=""; $PERL -
MExtUtils::Embed -e ldopts`
pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
perl_embed_ldflags=`echo X"$pgac_tmp1" | sed "s/^X//;s%$pgac_tmp2%%"`
if test -z "$perl_embed_ldflags" ; then
regards, jan otto
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More Snow Leopard fun: multiarch problems while building plperl
Ups, my previous patch was already applied in HEAD. This patch removes
the sed-patch
and added the check and set of ARCHFLAGS.
diff -c -r1.655 configure
*** configure 8 Sep 2009 18:15:55 - 1.655
--- configure 8 Sep 2009 18:30:04 -
***
*** 6941,6949
{ $as_echo "$as_me:$LINENO: checking for flags to link embedded
Perl" >&5
$as_echo_n "checking for flags to link embedded Perl... " >&6; }
! pgac_tmp1=`$PERL -MExtUtils::Embed -e ldopts`
pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
! perl_embed_ldflags=`echo X"$pgac_tmp1" | sed -e "s/^X//" -e "s%
$pgac_tmp2%%" -e "s/ -arch [-a-zA-Z0-9_]*//g"`
if test -z "$perl_embed_ldflags" ; then
{ $as_echo "$as_me:$LINENO: result: no" >&5
$as_echo "no" >&6; }
--- 6941,6949
{ $as_echo "$as_me:$LINENO: checking for flags to link embedded
Perl" >&5
$as_echo_n "checking for flags to link embedded Perl... " >&6; }
! pgac_tmp1=`[ "$ARCHFLAGS" ] || export ARCHFLAGS=""; $PERL -
MExtUtils::Embed -e ldopts`
pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
! perl_embed_ldflags=`echo X"$pgac_tmp1" | sed -e "s/^X//" -e "s%
$pgac_tmp2%%"`
if test -z "$perl_embed_ldflags" ; then
{ $as_echo "$as_me:$LINENO: result: no" >&5
$as_echo "no" >&6; }
regards, jan otto
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More Snow Leopard fun: multiarch problems while building plperl
Ups, my previous patch was already applied in HEAD. This patch removes the sed-patch and added the check and set of ARCHFLAGS. This seems to be assuming a lot more about the behavior of Apple's Perl hacks than I think we should. The patch as committed is good, because having any -arch flags in $perl_embed_ldflags is flat out wrong no matter what. They need to be in some other variable such as CFLAGS in order to have the desired effect. Of course. I meant only that Config_heavy.pl (required by Config.pm) depends on correctly setup of ARCHFLAGS. If you're proposing that the whole Postgres build system start paying attention to ARCHFLAGS instead of/in addition to CFLAGS, we could talk about that, but it'll be a much larger patch. See also the thread here If you dont want the linker warnings about libperl.dylib has not the required architecture and getting the ldopts with 'perl -MExtUtils::Embed -e ldopts' then you have to specify the correct arch-flags in ARCHFLAGS to get the correct ldopts (or strip out the '-arch xxx' from that output). I think that plperl in postgres build system is the only place where ARCHFLAGS is needed. i am not aware of other places. for me these linker warnings are not a real problem, because i know the reason for that and it is not affecting me or my work. http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php which points out that propagating -arch is the least of our worries. i will take a look. regards, jan otto -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] drop tablespace error: invalid argument
Well, 10.6.1 is out and it's still got the readdir() bug :-(. Has someone filed a bug report about this with Apple? yes i have filed a bugreport and keep this list informed when there is something going on. regards, jan otto -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] drop tablespace error: invalid argument
ERROR: could not read directory "pg_tblspc/16464": Invalid argument STATEMENT: DROP TABLESPACE testspace; Hmm ... can't reproduce this here, not even on OSX. From the version number I suspect you are using unreleased Snow Leopard. I'd venture it's a newly-introduced kernel bug and you need to talk to Apple about it. Thank you Tom. I will file a bugreport at Apple. Hey Jan, did you get any response to that bug report? Somebody else dug up a document suggesting that this might be intentional on Apple's part: http://archives.postgresql.org/pgsql-bugs/2009-11/msg00040.php If he's right, we have a nontrivial problem here :-( no this is not intentional. i got late (22. Oct 2009) feedback from apple that my reported bug was marked as duplicate. quoting apple: "After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering. This issue has been filed in our bug database under the original Bug ID# 6795764." regards, jan otto -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] drop tablespace error: invalid argument
Hey Jan, did you get any response to that bug report? Somebody else dug up a document suggesting that this might be intentional on Apple's part: http://archives.postgresql.org/pgsql-bugs/2009-11/msg00040.php i was not subscribed to pgsql-bugs list. i have read this message now and see he is referring to an article that was last modified at 22. april 2008 and was written for the first mac os x (10.0)! this article is very very old and was maybe modified during changes of apples knowledgbase-urls. a quick check on mac os x 10.4 und 10.5 confirmed that this behaviour/ bug is not present like described in this article. probably it was in 10.0.x... i have no older version of mac os x available here to check. regards, jan otto -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] drop tablespace error: invalid argument
>> My inclination is to continue assuming that the EINVAL is a new bug >> introduced in Snow Leopard. I sure hope they fix it in 10.6.2 though. >> If they don't, we may have to think about a workaround, messy as that >> will apparently be. > > 10.6.2 is out, and it appears to fix the bug --- if I remove the hack > in tablespace.c, we still pass regression tests. > > Someone else please confirm? If so I'll revert that patch. Yes i can confirm that this bug is fixed in Mac OS X 10.6.2. I have checked it twice. With removed workaround in tablespace.c and with my self written testcase from september. regards, jan otto -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] drop tablespace error: invalid argument
hello hackers, i have problems dropping an existing empty tablespace. here is a reduced example: AscheMobil:~ asche$ cat test2.sql CREATE TABLESPACE testspace LOCATION '/opt/postgresql/data2'; CREATE SCHEMA testschema; CREATE TABLE testschema.foobar (id int) TABLESPACE testspace; DROP SCHEMA testschema CASCADE; DROP TABLESPACE testspace; AscheMobil:~ asche$ /opt/postgresql/bin/psql asche lrwx-- 1 asche staff 21 Aug 16 13:08 16464 -> /opt/postgresql/ data2 AscheMobil:~ asche$ ls -l /opt/postgresql/data2/ total 8 -rw--- 1 asche staff 4 Aug 16 13:08 PG_VERSION AscheMobil:~ asche$ id uid=501(asche) gid=20(staff) groups=20(staff),204(_developer),100 (_lpoperator),98(_lpadmin),81(_appserveradm),80(admin),79 (_appserverusr),61(localaccounts),12(everyone),402 (com.apple.sharepoint.group.1),401(com.apple.access_screensharing) if i dont create the table testschema.foobar i can drop the tablespace without problems. there is another effect i wonder about. when i execute 'DROP TABLESPACE testspace;' two times at the end of script the second drop statement drops the tablespace correctly. AscheMobil:~ asche$ echo 'DROP TABLESPACE testspace;'>>test2.sql AscheMobil:~ asche$ cat test2.sql CREATE TABLESPACE testspace LOCATION '/opt/postgresql/data2'; CREATE SCHEMA testschema; CREATE TABLE testschema.foobar (id int) TABLESPACE testspace; DROP SCHEMA testschema CASCADE; DROP TABLESPACE testspace; DROP TABLESPACE testspace; AscheMobil:~ asche$ /opt/postgresql/bin/psql asche < test2.sql CREATE TABLESPACE CREATE SCHEMA CREATE TABLE NOTICE: drop cascades to table testschema.foobar DROP SCHEMA ERROR: could not read directory "pg_tblspc/16469": Invalid argument STATEMENT: DROP TABLESPACE testspace; ERROR: could not read directory "pg_tblspc/16469": Invalid argument DROP TABLESPACE AscheMobil:~ asche$ ls -l /opt/postgresql/data2/ AscheMobil:~ asche$ ls -l /opt/postgresql/data/pg_tblspc/ AscheMobil:~ asche$ /opt/postgresql/bin/psql asche -c 'select version()' version PostgreSQL 8.4.0 on i386-apple-darwin10.0.0, compiled by GCC i686- apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646), 64-bit (1 row) this is the original postgresql-8.4.0 source package from http://www.postgresql.org/ftp/source/v8.4.0/ compiled with: ./configure --enable-debug --with-openssl --with-perl --with-python -- with-tcl --with-libxml --with-libxslt --with-zlib --prefix=/opt/ postgresql it would be nice if somebody can take a look at this. regards, jan otto
Re: [HACKERS] drop tablespace error: invalid argument
ERROR: could not read directory "pg_tblspc/16464": Invalid argument STATEMENT: DROP TABLESPACE testspace; Hmm ... can't reproduce this here, not even on OSX. From the version number I suspect you are using unreleased Snow Leopard. I'd venture it's a newly-introduced kernel bug and you need to talk to Apple about it. Thank you Tom. I will file a bugreport at Apple. regards, jan otto -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] drop tablespace error: invalid argument
On Aug 16, 2009, at 8:25 PM, Tom Lane wrote:
Jan Otto writes:
ERROR: could not read directory "pg_tblspc/16464": Invalid argument
STATEMENT: DROP TABLESPACE testspace;
Hmm ... can't reproduce this here, not even on OSX. From the version
number I suspect you are using unreleased Snow Leopard. I'd venture
it's a newly-introduced kernel bug and you need to talk to Apple about
it.
regards, tom lane
I have digged a bit around in the source code of postgresql to build a
self contained test-case for Apple and found that the implementation
of Apples readdir() is buggy. readdir() fails under some circumstances.
So i have build a patch against current pgsql's HEAD to work around
the issue. If the bug in readdir() goes into the final release snow
leopard
we have a solution.
This patch basically frees dirdesc and rereads the tablespace location
in case a subdirectory was deleted from the tablespace. this is the
place
where snow leopard fails to read the next entry with readdir().
regards, jan otto
diff -c -r1.61 tablespace.c
*** pgsql/src/backend/commands/tablespace.c 22 Jan 2009 20:16:02
- 1.61
--- pgsql/src/backend/commands/tablespace.c 17 Aug 2009 22:36:01
-
***
*** 611,616
--- 611,623
errmsg("could not remove
directory \"%s\": %m",
subfile)));
+ /*
+* The following two lines work around a bug in Mac OS
X Snow Leopard (Build 10A432)
+* readdir() implementation. We free dirdesc and
reread location from start.
+*/
+ FreeDir(dirdesc);
+ dirdesc = AllocateDir(location);
+
pfree(subfile);
}
