Re: [BUGS] BUG #1273: bad path for english.stop in tsearch2
> The following bug has been logged online: > > Bug reference: 1273 > Logged by: Werner Bohl > > Email address: [EMAIL PROTECTED] > > PostgreSQL version: 8.0 Beta > > Operating system: Windows XP pro > > Description:bad path for english.stop in tsearch2 > > Details: > > Running Postgresql 8.0beta2-dev3. > When issuing a query using tsearch2. It erred, looking for > english.stop in /usr/local/psql/share/contrib. > > Fixed creating that directory structure and placing > english.stop there, but it should look for that file under > Program Files/PostgreSQL/8.0-beta2-dev3/share/contrib. Hello. This has been fixed in the pginstaller cvs and will be included in the next beta release. //Magnus ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #1286: indices not used after a pg_restore
The following bug has been logged online:
Bug reference: 1286
Logged by: Federico Di Gregorio
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.5
Operating system: Debian GNU/Linux sarge
Description:indices not used after a pg_restore
Details:
We have a (big) database with a lot of functional indices (the indices are
quite strange but should replicate an old ISAM sorting procedure).
After a pg_dump/pg_restore (using the tar format) queries that were using
the indices don't use them anymore until the indices are dropped and
recreated. After that the indices are used the correct way.
Note that after the pg_restore we also tried a complete
VACUUM/ANALYZE/REINDEX but the situation does not change. The indices are
not used until dropped and recreated.
Please, if you discuss this on the bugs mailing list keep me in cc:.
Example of one of the indices:
CREATE INDEX "MOVIMENTII5" ON movimenti USING btree
(upper(((to_char("TYPE_REF", 'S00'::text) || to_char("IDREF",
'S00'::text)) || to_char("IDMOVIMENT", 'S00'::text;
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] BUG #1286: indices not used after a pg_restore
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > After a pg_dump/pg_restore (using the tar format) queries that were using > the indices don't use them anymore until the indices are dropped and > recreated. After that the indices are used the correct way. I do not believe that you remembered to ANALYZE after restore. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Fatal "make check" bug with 8.0 beta 3 under Mac OS 10.3
Tom Lane wrote: OS X has an unreasonably small limit on shared memory size; if you don't raise it (IIRC you can do this in /etc/rc) then you don't get to have more than one postmaster at a time. OK, I see what you're talking about from looking in /etc/rc. You might want to put something about this in the installation notes (if it's not already there), and/or put something in "configure" itself to notify users of this problem. Thanks for the response! Reuven ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] 'configure' bug on Mac OS X 10.3.5
Hi,
I just downloaded a fresh distribution of postgresql-8.0.0beta3 and tried
compiling it on a Mac OS X 10.3.5 (Panther -- fresh install), and it gave me
the following error:
sledge:~/tmp/postgresql-8.0.0beta3 sfg900$ ./configure
--prefix=/opt/postgresql-8.0.0beta3 --with-python --with-openssl --with-tcl
--with-perl --enable-thread-safety
checking build system type... powerpc-apple-darwin7.5.0
checking host system type... powerpc-apple-darwin7.5.0
checking which template to use... darwin
checking whether to build with 64-bit integer date/time support... no
checking whether NLS is wanted... no
checking for default port number... 5432
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking how to turn off strict aliasing in gcc -no-cpp-precomp...
-fno-strict-aliasing
configure: using CFLAGS=-O2 -fno-strict-aliasing
checking whether the C compiler still works... yes
checking how to run the C preprocessor... gcc -no-cpp-precomp -E
checking allow thread-safe client libraries... yes
checking whether to build with Tcl... yes
checking whether to build Perl modules... yes
checking whether to build Python modules... yes
checking whether to build with Kerberos 4 support... no
checking whether to build with Kerberos 5 support... no
checking whether to build with PAM support... no
checking whether to build with Rendezvous support... no
checking whether to build with OpenSSL support... yes
configure: using CPPFLAGS=
configure: using LDFLAGS=
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking for flex... /usr/bin/flex
checking whether ln -s works... yes
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for ranlib... ranlib
checking for lorder... lorder
checking for tar... /sw/bin/tar
checking for strip... strip
checking whether it is possible to strip libraries... no
checking for bison... bison -y
configure: WARNING:
*** If you are going to modify the grammar files or build from CVS, the
installed
*** version of Bison is too old. Bison version 1.875 or later is required.
checking for perl... /usr/bin/perl
checking for Perl archlibexp...
/System/Library/Perl/5.8.1/darwin-thread-multi-2level
checking for Perl privlibexp... /System/Library/Perl/5.8.1
checking for Perl useshrplib... true
checking for flags to link embedded Perl... -L/usr/local/lib
/System/Library/Perl/5.8.1/darwin-thread-multi-2level/auto/DynaLoader/DynaLo
ader.a -L/System/Library/Perl/5.8.1/darwin-thread-multi-2level/CORE -lperl
-ldl -lm -lc
checking for python... /usr/bin/python
checking for Python distutils module... yes
checking Python installation directories...
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3
checking how to link an embedded Python application...
-L/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/con
fig -ldl -lpython2.3
checking for main in -lbsd... no
checking for setproctitle in -lutil... no
checking for main in -lm... yes
checking for main in -ldl... yes
checking for main in -lnsl... no
checking for main in -lsocket... no
checking for main in -lipc... no
checking for main in -lIPC... no
checking for main in -llc... no
checking for main in -ldld... no
checking for main in -lld... no
checking for main in -lcompat... no
checking for main in -lBSD... no
checking for main in -lgen... no
checking for main in -lPW... no
checking for main in -lresolv... yes
checking for library containing getopt_long... none required
checking for main in -lunix... no
checking for library containing crypt... none required
checking for library containing fdatasync... no
checking for shmget in -lcygipc... no
checking for readline... no
configure: error: readline library not found
If you have readline already installed, see config.log for details on the
failure. It is possible the compiler isn't looking in the proper directory.
Use --without-readline to disable readline support.
I checked and I don't have 'readline' installed. --without-readline did the
trick, but shouldn't this be handled automatically? If readline is not
found, configure should carry on with a '--without-readline', rather than
reporting an error.
Moreover, there's no 'gmake' in Mac OS X, and it uses 'make' instead. The
installation guide should mention this as well.
Cheers,
Fahad
--
main(){int j=12345;char t[]=":aAbcdefFgGhijklmnNopqrsStuUvwyz \n",
*i="dUGScUiAbpmwqbmgduAvpmmlzce\nlmGGUbFbzjdb";while(*i){j+=
strchr(t,*i++)-t;j%=sizeof t-1;putchar(t[j]);}return 0;}
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] SELECT FOR UPDATE and LIMIT 1 behave oddly
Tom, > The FOR UPDATE part executes after the LIMIT part. Arguably this is a > bad thing, but I'm concerned about the compatibility issues if we change > it. In that case, maybe I should do a doc patch warning people not to combine them? Hmmm come to think of it, is there any easy way to query "give me the first row which is not locked"?If I tie pg_locks to a query, will I get wierd effects? Just musing -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] 'configure' bug on Mac OS X 10.3.5
On Wed, 2004-10-13 at 10:23, Fahad G. wrote: > I checked and I don't have 'readline' installed. --without-readline did the > trick, but shouldn't this be handled automatically? This is intentional -- what's wrong with stopping? ISTM that stopping and letting the user know what went wrong is probably better than just continuing: many users will install readline when they discover it isn't installed, and it is easy to miss a warning emitted by "configure" as its output flies past. > Moreover, there's no 'gmake' in Mac OS X, and it uses 'make' instead. The > installation guide should mention this as well. The docs say: "(On some systems GNU make is the default tool with the name make.)" -Neil ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] SELECT FOR UPDATE and LIMIT 1 behave oddly
On Thu, 2004-10-14 at 14:02, Tom Lane wrote: > The FOR UPDATE part executes after the LIMIT part. Arguably this is a > bad thing, but I'm concerned about the compatibility issues if we change > it. I agree backward compat is a concern, but it seems pretty clear to me that this is not the optimal behavior. If there are any people who actually need the old behavior, they can nest the FOR UPDATE in a FROM-clause subselect: SELECT * FROM foo FOR UPDATE LIMIT 5; -- used to lock the whole table SELECT * FROM (SELECT * FROM foo FOR UPDATE) x LIMIT 5; -- will always do so Would it be sufficient to put a large warning in the "incompatibilities" section of the release notes? -Neil ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] 'configure' bug on Mac OS X 10.3.5
On Fri, Oct 15, 2004 at 12:03:39PM +1000, Neil Conway wrote: > On Wed, 2004-10-13 at 10:23, Fahad G. wrote: > > I checked and I don't have 'readline' installed. --without-readline did the > > trick, but shouldn't this be handled automatically? > > This is intentional -- what's wrong with stopping? ISTM that stopping > and letting the user know what went wrong is probably better than just > continuing: many users will install readline when they discover it isn't > installed, and it is easy to miss a warning emitted by "configure" as > its output flies past. What about emitting at the end of configure something like Features enabled: command line editing, parser generation, PL/Perl Features disabled: coffee maker, online gambling, PL/Python -- Alvaro Herrera () "And as an added bonus, now my computer goes to the toilet for me, leaving me free to spend time on more useful activities! yay slug codefests!" (C. Parker) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] BUG #1286: indices not used after a pg_restore
Federico Di Gregorio <[EMAIL PROTECTED]> writes: > On Thu, 2004-10-14 at 06:54 -0400, Tom Lane wrote: >> I do not believe that you remembered to ANALYZE after restore. > unfortunately for your belief, i remembered. :) > also, this problem can be replicated at will. i can send a dump that > exposes the problem if necessary but i'll need some time to purge > customers data and create a dump a can freely send. I'd like to see it, please. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] SELECT FOR UPDATE and LIMIT 1 behave oddly
Neil Conway <[EMAIL PROTECTED]> writes: > I agree backward compat is a concern, but it seems pretty clear to me > that this is not the optimal behavior. If there are any people who > actually need the old behavior, they can nest the FOR UPDATE in a > FROM-clause subselect: > SELECT * FROM foo FOR UPDATE LIMIT 5; -- used to lock the whole table > SELECT * FROM (SELECT * FROM foo FOR UPDATE) x LIMIT 5; -- will always > do so Allowing FOR UPDATE in sub-selects opens a can of worms that I do not think we'll be able to re-can (at least not without the proverbial larger size of can). The fundamental question about the above construct is: exactly which rows did it lock? And what's your proof that that set is what it *should* have locked? What if some of the locked rows didn't get returned to the client? Even if LIMIT happens to work in a convenient way, allowing FOR UPDATE inside a subselect would expose us to a lot of other cases (joins and aggregates for instance) that I don't believe we can guarantee pleasant behavior for. My recollection is that the original FOR UPDATE and LIMIT behaviors were both implemented at the top level in execMain.c, and at that time LIMIT effectively executed after FOR UPDATE. We later pushed LIMIT down to become a plan node, which was a good idea in every respect except that it changed the order of application of these two behaviors. I'm afraid of the semantic consequences of pushing down FOR UPDATE into a plan node however. Maybe it can be made to work but I think a lot of very careful thought will need to go into it. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] 'configure' bug on Mac OS X 10.3.5
Neil Conway <[EMAIL PROTECTED]> writes: > On Wed, 2004-10-13 at 10:23, Fahad G. wrote: >> I checked and I don't have 'readline' installed. --without-readline did the >> trick, but shouldn't this be handled automatically? > This is intentional Indeed. A few releases back we did actually behave that way (drop the readline functionality and continue) but it was persuasively argued that this was a Bad Thing. To see why, you should consider the fact that configure is often run in non-interactive contexts (such as RPM package construction) where its output isn't likely to be scrutinized by humans. RPM package makers would much rather get a build failure than have the thing bull ahead and build a substandard RPM. Even when configure *is* invoked interactively, the output isn't likely to be scrutinized closely; and a newbie may not understand the implications of a bleat in the output even if he reads it. So basically, the opinion around here is that if you want a build with nonfunctional readline capability, you need to say so on the configure command line. The default assumption is that you want readline, and we aim to do that or die trying. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] SELECT FOR UPDATE and LIMIT 1 behave oddly
On Fri, 2004-10-15 at 14:22, Tom Lane wrote: > Allowing FOR UPDATE in sub-selects opens a can of worms that I do not > think we'll be able to re-can (at least not without the proverbial > larger size of can). Ah, I see. I had tried some trivial queries to determine if we supported FOR UPDATE in subqueries, such as: select * from def, abc, (select * from abc for update) x; But of course a more careful examination shows that we don't (I'd guess the planner is transforming the above subquery into a join). I think it would make sense to reject the above query for the sake of consistency. It seems that would be easy to do by rejecting FOR UPDATE of subqueries in the analysis phase, rather than going to the trouble of explicitly allowing them (see analyze.c circa line 2753) and then rejecting them in the planner. BTW, FOR UPDATE's interaction with LIMIT is not undocumented -- we actually document the opposite of what we implement. From the SELECT ref page: FOR UPDATE may appear before LIMIT for compatibility with PostgreSQL versions before 7.3. It effectively executes after LIMIT, however, and so that is the recommended place to write it. > The fundamental question about the above construct is: exactly which > rows did it lock? I'm not sure I understand. The rows the query locks should be the result set of the subquery. Also, I think it only makes sense to allow FOR UPDATE in FROM-clause subselects, and it would also be reasonable to disable some subquery optimizations (e.g. subquery pullup) when FOR UPDATE is specified. > What if some of the locked rows didn't get returned to the client? In the case of SELECT ... FOR UPDATE LIMIT x, exactly the same condition applies: some number of locked rows will not be returned to the client. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] SELECT FOR UPDATE and LIMIT 1 behave oddly
Neil Conway <[EMAIL PROTECTED]> writes: > On Fri, 2004-10-15 at 14:22, Tom Lane wrote: >> What if some of the locked rows didn't get returned to the client? > In the case of SELECT ... FOR UPDATE LIMIT x, exactly the same condition > applies: some number of locked rows will not be returned to the client. Au contraire: every row that gets locked will be returned to the client. The gripe at hand is that the number of such rows may be smaller than the client wished, because the LIMIT step is applied before we do the FOR UPDATE step (which has not only the effect of locking selected rows, but of disregarding rows that were deleted since our query snapshot). regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] SELECT FOR UPDATE and LIMIT 1 behave oddly
On Fri, 2004-10-15 at 15:30, Tom Lane wrote: > Au contraire: every row that gets locked will be returned to the client. > The gripe at hand is that the number of such rows may be smaller than > the client wished, because the LIMIT step is applied before we do the > FOR UPDATE step Ah, my apologies -- I misunderstood. Clearly not enough coffee this morning :-) Sorry for the noise. -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
