[HACKERS] ERROR: Index pg_toast_8443892_index is not a btree
I get the following error when vacuuming a db or inserting a big value in a column of a toastable datatype (GEOMETRY). ERROR: Index pg_toast_8443892_index is not a btree My last action has been killing a psql that was getting mad about receiving too much input and beeping as hell (readline issue ?). After that, I put the insert query I was trying to feed to psql in a file and sourced it... Bump! that error appeared. psql:B:477: ERROR: Index pg_toast_8443892_index is not a btree Line 477 is EOF... Vacuum does not solve this (as you can see in the first error message) Do you have any hint about how to fix this ? TIA --strk; ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Double linked list with one pointer
At 2003-12-07 18:19:26 +0100, [EMAIL PROTECTED] wrote: There is a new type in C99 for integer that can hold a pointer value. I think it's called intptr_t resp. uintptr_t, but I don't have the standard around. Yes, they're called intptr_t and uintptr_t (ยง7.18.1.4), but they're both optional types. I note in passing that the xor-trick is one of the pointer-hiding tricks that are the bane of garbage collectors for C (the other common example being writing a pointer to a file and reading it back). -- ams ---(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: [HACKERS] CVS HEAD compile failure
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Attached is a compile failure I am seeing in CVS HEAD in bin/pg_dump. Hmm. I made some what-I-thought-were-unimportant changes in the order of header inclusions in pg_dump. Probably what you are seeing is a previously unnoticed case of some header that requires some other header to be included beforehand. The syntax errors are likely due to a typedef name not being defined before use. Does that help? Uh, no? :-) Where is the typedef here: int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void (*free_func)(void *)); -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] CVS HEAD compile failure
Andrew Dunstan wrote: fresh checkout just compiled fine for me on Linux (RH8) with ssl enabled. Maybe it is your openssl installation? It is openssl 0.9.7c. 7.4 CVS compiles fine so I don't see how it can be my SSL install. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Build error?
Joe Conway wrote: Is that something broken on my system??? Bruce just reported something like this too. I had a somewhat similar issue about a week and a half ago. It may be a long shot, but try: ./configure \ --with-openssl \ --with-krb5 \ --with-includes=/usr/kerberos/include \ --with-libs=/usr/kerberos/lib of course replacing /usr/kerberos/* with whatever is correct for your system. In my experience there has always (well, for quite some time anyway) been a dependency between openssl and krb5. Just before I ran into the latest problem, Peter made a change to configure that seemed to trigger it for me: http://archives.postgresql.org/pgsql-committers/2003-11/msg00278.php How long has it been since you rebuilt from cvs? A few days. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CVS HEAD compile failure
Bruce Momjian wrote: Andrew Dunstan wrote: fresh checkout just compiled fine for me on Linux (RH8) with ssl enabled. Maybe it is your openssl installation? It is openssl 0.9.7c. 7.4 CVS compiles fine so I don't see how it can be my SSL install. I just tried with this version of openssl (on RH9), and it still compiled fine (CFLAGS=-H shows the right files being picked up). Can you give us the complete config settings? Maybe some interaction between them has found a bug somewhere. (BTW, the INSTALL file says you can use --with-openssl=/path but configure barfs on it - we need to fix one or the other). cheers andrew ---(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: [HACKERS] CVS HEAD compile failure
Bruce Momjian [EMAIL PROTECTED] writes: Where is the typedef here: int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void (*free_func)(void *)); size_t ... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] ERROR: Index pg_toast_8443892_index is not a btree
strk wrote: I get the following error when vacuuming a db or inserting a big value in a column of a toastable datatype (GEOMETRY). ERROR: Index pg_toast_8443892_index is not a btree My last action has been killing a psql that was getting mad about receiving too much input and beeping as hell (readline issue ?). You must have killed a lot more than your psql frontend to get that as a result. After that, I put the insert query I was trying to feed to psql in a file and sourced it... Bump! that error appeared. psql:B:477: ERROR: Index pg_toast_8443892_index is not a btree Line 477 is EOF... Vacuum does not solve this (as you can see in the first error message) Do you have any hint about how to fix this ? Try reindex table tablename. If you really only lost that btree index, that should do. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] CVS HEAD compile failure
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Where is the typedef here: int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void (*free_func)(void *)); size_t ... If there's a missing typedef shouldn't we see something like this: `size_t' undeclared (first use in this function) (assuming he is using gcc)? cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] ERROR: Index pg_toast_8443892_index is not a btree
JanWieck wrote: strk wrote: I get the following error when vacuuming a db or inserting a big value in a column of a toastable datatype (GEOMETRY). ERROR: Index pg_toast_8443892_index is not a btree My last action has been killing a psql that was getting mad about receiving too much input and beeping as hell (readline issue ?). You must have killed a lot more than your psql frontend to get that as a result. really... I hit ^C at the psql terminal and kill -9 psql_pid The only other reason I can thing about is the data type text input function screwing pg internal pointers... After that, I put the insert query I was trying to feed to psql in a file and sourced it... Bump! that error appeared. psql:B:477: ERROR: Index pg_toast_8443892_index is not a btree Line 477 is EOF... Vacuum does not solve this (as you can see in the first error message) Do you have any hint about how to fix this ? Try reindex table tablename. If you really only lost that btree index, that should do. gis=# reindex table test; -- this is the table I was trying to insert into WARNING: table test wasn't reindexed REINDEX gis=# reindex table pg_toast_8443892; -- this was an assuption I made ERROR: Relation pg_toast_8443892 does not exist gis=# vacuum; ERROR: Index pg_toast_8443892_index is not a btree gis=# Where could this pg_toast_8443892_index reference be found ? --strk; ---(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: [HACKERS] CVS HEAD compile failure
Bruce Momjian [EMAIL PROTECTED] writes: Andrew Dunstan wrote: fresh checkout just compiled fine for me on Linux (RH8) with ssl enabled. Maybe it is your openssl installation? It is openssl 0.9.7c. 7.4 CVS compiles fine so I don't see how it can be my SSL install. I've been able to reproduce this on one of my machines, and it's nasty. It's a conflict between other people's headers. /usr/local/include/zlib.h (version 1.1.4) quoth: typedef void (*free_func) OF((voidpf opaque, voidpf address)); /usr/local/ssl/include/openssl/crypto.h (0.9.7c) quoth: int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void (*free_func)(void *)); So if this version of zlib.h is included before this version of crypto.h, things break. Other way 'round works fine. We can work around this by being more careful about inclusion order of these headers. Ultimately it would be nice if the upstream library authors could avoid the name conflict. I'm of the opinion that zlib should not be typedef'ing a name as generic as free_func, but if they've made that part of their exported API, it might be hard for them to change. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] CVS HEAD compile failure
Andrew Dunstan [EMAIL PROTECTED] writes: (BTW, the INSTALL file says you can use --with-openssl=/path but Only because it hasn't yet been rebuilt from installation.sgml. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] CVS HEAD compile failure
int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void (*free_func)(void *)); If there's a missing typedef shouldn't we see something like this: `size_t' undeclared (first use in this function) (assuming he is using gcc)? Try it. typedefs are weird in the C language, they change the syntactical value of the identifier. The parser actually has to know whether an identifier is a typedef or not in order to figure out how to parse the code. Syntax errors in known good code, especially header files are a typical symptom of missing typedefs. A good thing to know to recognize right away or else you'll spend lots of time puzzling over seemingly good code. -- greg ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] ERROR: Index pg_toast_8443892_index is not a btree
strk wrote: JanWieck wrote: strk wrote: I get the following error when vacuuming a db or inserting a big value in a column of a toastable datatype (GEOMETRY). ERROR: Index pg_toast_8443892_index is not a btree My last action has been killing a psql that was getting mad about receiving too much input and beeping as hell (readline issue ?). You must have killed a lot more than your psql frontend to get that as a result. really... I hit ^C at the psql terminal and kill -9 psql_pid The only other reason I can thing about is the data type text input function screwing pg internal pointers... You mean the text input function did stomp over shared memory of the buffer cache? That would be the first time I hear of this. Could you please do select oid as datoid from pg_database where datname = 'dbname'; select A.relfilenode from pg_class A, pg_class B, pg_class C where C.relname = 'tablename' and B.oid = C.reltoastrelid and A.oid = B.reltoastidxid; With that information, give us an ls -l $PGDATA/base/datoid/relfilenode This file is the toast tables index. After that, I put the insert query I was trying to feed to psql in a file and sourced it... Bump! that error appeared. psql:B:477: ERROR: Index pg_toast_8443892_index is not a btree Line 477 is EOF... Vacuum does not solve this (as you can see in the first error message) Do you have any hint about how to fix this ? Try reindex table tablename. If you really only lost that btree index, that should do. gis=# reindex table test; -- this is the table I was trying to insert into WARNING: table test wasn't reindexed Is there more information about why it wasn't reindexed in the postmaster log? REINDEX gis=# reindex table pg_toast_8443892; -- this was an assuption I made ERROR: Relation pg_toast_8443892 does not exist gis=# vacuum; ERROR: Index pg_toast_8443892_index is not a btree gis=# Where could this pg_toast_8443892_index reference be found ? As you might guess from the second select above ... Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] ERROR: Index pg_toast_8443892_index is not a btree
strk [EMAIL PROTECTED] writes: gis=# reindex table pg_toast_8443892; -- this was an assuption I made ERROR: Relation pg_toast_8443892 does not exist If it's 7.3 or later you need to say reindex table pg_toast.pg_toast_8443892; regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CVS HEAD compile failure
Greg Stark [EMAIL PROTECTED] writes: Syntax errors in known good code, especially header files are a typical symptom of missing typedefs. A good thing to know to recognize right away or else you'll spend lots of time puzzling over seemingly good code. Actually it turns out the error was the other way round: a name that the code did not expect to be a typedef was being taken as one. But yeah, impossible syntax errors in C code are often a symptom of typedef trouble. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] CVS HEAD compile failure
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
fresh checkout just compiled fine for me on Linux (RH8) with ssl
enabled. Maybe it is your openssl installation?
It is openssl 0.9.7c. 7.4 CVS compiles fine so I don't see how it can
be my SSL install.
I've been able to reproduce this on one of my machines, and it's nasty.
It's a conflict between other people's headers.
/usr/local/include/zlib.h (version 1.1.4) quoth:
typedef void (*free_func) OF((voidpf opaque, voidpf address));
/usr/local/ssl/include/openssl/crypto.h (0.9.7c) quoth:
int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void (*free_func)(void *));
So if this version of zlib.h is included before this version of
crypto.h, things break. Other way 'round works fine.
We can work around this by being more careful about inclusion order
of these headers. Ultimately it would be nice if the upstream library
authors could avoid the name conflict. I'm of the opinion that zlib
should not be typedef'ing a name as generic as free_func, but if
they've made that part of their exported API, it might be hard for them
to change.
In that case I'm confused about why this code compiles on my machine:
#include stdio.h
#include zconf.h
typedef voidpf (*alloc_func) OF((voidpf opaque, uInt items, uInt size));
typedef void (*free_func) OF((voidpf opaque, voidpf address));
int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void
(*free_func)(void *));
int main()
{
return 0;
}
Also, in compiling pg_dump/common.c, zlib.h (which has this typedef on
my machine) *is* included before openssl/crypto.h.
Either there is something I'm not getting (quite possible ;-) ), or the
problem lies deeper. (compiler version maybe?)
cheers
andrew
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] ERROR: Index pg_toast_8443892_index is not a btree
tgl wrote: strk [EMAIL PROTECTED] writes: gis=# reindex table pg_toast_8443892; -- this was an assuption I made ERROR: Relation pg_toast_8443892 does not exist If it's 7.3 or later you need to say reindex table pg_toast.pg_toast_8443892; regards, tom lane It worked! Thank you very much. --strk; ---(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
[HACKERS] 73.5 and uw 713
Hi all, I've upgraded my system from 7.3.4 to 7.3.5 yesterday and have already experienced to crash during vacuum full. I have'nt recompiled with debug yet but it's a sigsegv in function repair_frag in vacuum.c Does it ring a bell? Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CVS HEAD compile failure
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I've been able to reproduce this on one of my machines, and it's nasty. In that case I'm confused about why this code compiles on my machine: What compiler are you using? I'm using gcc 2.95.3 (on the machine that shows the failure), and I think Bruce is also using something less than the latest. It's possible that more recent gcc's are able to figure out that the reference to free_func should be interpreted as a parameter name and not a typedef. In fact, trying your test program fails here: $ gcc -Wall zzz.c zzz.c:8: parse error before `free_func' zzz.c:8: parse error before `)' $ so compiler difference definitely seems to be the answer. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] aggregate + view + alias crash on 7.4 stable
Tatsuo Ishii [EMAIL PROTECTED] writes: test=# select count(a.*) from pg_indexes a limit 10; server closed the connection unexpectedly Hmmm ... the crash is certainly UnGood, but is there any reason we should accept this query rather than generating an error? If the SQL is not legal, generating an error is enough, I think. The actual bug turns out to affect any use of a whole-row reference to a subquery, so it has to be fixed whether you think the above is particularly meaningful or not --- for example, if foo() is defined to accept a parameter that is the rowtype of pg_indexes, it surely should work to say select foo(a.*) from pg_indexes a; In light of that, I just fixed the bug and did not do anything about prohibiting passing rowtype values to count(). We have historically allowed that, and I haven't got a good argument for removing it. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CVS HEAD compile failure
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I've been able to reproduce this on one of my machines, and it's nasty. In that case I'm confused about why this code compiles on my machine: What compiler are you using? I'm using gcc 2.95.3 (on the machine that shows the failure), and I think Bruce is also using something less than the latest. It's possible that more recent gcc's are able to figure out that the reference to free_func should be interpreted as a parameter name and not a typedef. In fact, trying your test program fails here: $ gcc -Wall zzz.c zzz.c:8: parse error before `free_func' zzz.c:8: parse error before `)' $ so compiler difference definitely seems to be the answer. gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 73.5 and uw 713
[EMAIL PROTECTED] writes: I've upgraded my system from 7.3.4 to 7.3.5 yesterday and have already experienced to crash during vacuum full. I have'nt recompiled with debug yet but it's a sigsegv in function repair_frag in vacuum.c Considering that vacuum.c hasn't changed in that branch since 7.3beta4, it's highly unlikely that this represents a regression between 7.3.4 and 7.3.5. Pre-existing bug, maybe ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CVS HEAD compile failure
On Mon, Dec 08, 2003 at 01:27:35PM -0500, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I've been able to reproduce this on one of my machines, and it's nasty. In that case I'm confused about why this code compiles on my machine: What compiler are you using? I'm using gcc 2.95.3 (on the machine that shows the failure) I can compile current cvs with gcc 2.95.3, openssl 0.9.7b and zlib 1.2.1. zlib 1.2.1 still has the same typedef though. Kurt ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] CVS HEAD compile failure
Kurt Roeckx wrote: On Mon, Dec 08, 2003 at 01:27:35PM -0500, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I've been able to reproduce this on one of my machines, and it's nasty. In that case I'm confused about why this code compiles on my machine: What compiler are you using? I'm using gcc 2.95.3 (on the machine that shows the failure) I can compile current cvs with gcc 2.95.3, openssl 0.9.7b and zlib 1.2.1. zlib 1.2.1 still has the same typedef though. compile success with gcc 2.96 here. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(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: [HACKERS] CVS HEAD compile failure
Kurt Roeckx [EMAIL PROTECTED] writes: I can compile current cvs with gcc 2.95.3, openssl 0.9.7b and zlib 1.2.1. current CVS meaning since I fixed the include order ? regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] CVS HEAD compile failure
Tom Lane wrote: Kurt Roeckx [EMAIL PROTECTED] writes: I can compile current cvs with gcc 2.95.3, openssl 0.9.7b and zlib 1.2.1. current CVS meaning since I fixed the include order ? Good question. Using my cvsup tree here, which I did sup today already. So what -D would trigger the failure? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 73.5 and uw 713
Is there ay way I can help with this debugging? On Mon, 8 Dec 2003, Tom Lane wrote: Date: Mon, 08 Dec 2003 14:03:42 -0500 From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: pgsql-hackers list [EMAIL PROTECTED] Subject: Re: [HACKERS] 73.5 and uw 713 [EMAIL PROTECTED] writes: I've upgraded my system from 7.3.4 to 7.3.5 yesterday and have already experienced to crash during vacuum full. I have'nt recompiled with debug yet but it's a sigsegv in function repair_frag in vacuum.c Considering that vacuum.c hasn't changed in that branch since 7.3beta4, it's highly unlikely that this represents a regression between 7.3.4 and 7.3.5. Pre-existing bug, maybe ... regards, tom lane -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CVS HEAD compile failure
Jan Wieck [EMAIL PROTECTED] writes: Good question. Using my cvsup tree here, which I did sup today already. So what -D would trigger the failure? Hopefully, you can't ... If you revert src/bin/pg_dump/pg_backup_archiver.h to version 1.54 you'd see the problem, assuming your compiler is vulnerable. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] on_shmem_exit() callback function type.
It seems that on_shmem_exit() first argument is a function that needs to be called back. The function itself doesn't have a prototype, but it's called with and int and Datum as argument when it's used. It seems that almost none of the functions it calls will actually need any argument, I could only found 3 that actually use it. Those most weird one was DummyProcKill, which itself doesn't take any arguments, but it asked to be called with proctype as argument. Should I convert them all to take the 2 arguments instead, or just leave it as is? Kurt ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] on_shmem_exit() callback function type.
Kurt Roeckx wrote: It seems that on_shmem_exit() first argument is a function that needs to be called back. The function itself doesn't have a prototype, but it's called with and int and Datum as argument when it's used. It seems that almost none of the functions it calls will actually need any argument, I could only found 3 that actually use it. Those most weird one was DummyProcKill, which itself doesn't take any arguments, but it asked to be called with proctype as argument. Should I convert them all to take the 2 arguments instead, or just leave it as is? If you wish to clean up that area, feel free. It could use it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Release cycle length
Any chance you might be able to put together a HOWTO on this? I think it would be extremely valuable to a lot of people. On Tue, Nov 25, 2003 at 11:25:34PM -0500, Andrew Sullivan wrote: On Mon, Nov 24, 2003 at 11:08:44PM -0600, Jim C. Nasby wrote: Has anyone looked at using replication as a migration method? If Looked at? Sure. Heck, I've done it. Yes, it works. Is it painless? Well, that depends on whether you think using erserver is painless. ;-) It's rather less downtime than pg_dump | psql, I'll tell you. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ERROR: Index pg_toast_8443892_index is not a btree
I get the following error when vacuuming a db or inserting a big value in a column of a toastable datatype (GEOMETRY). ERROR: Index pg_toast_8443892_index is not a btree My last action has been killing a psql that was getting mad about receiving too much input and beeping as hell (readline issue ?). Is there anything stopping us going through the code and finding all ereports that can be fixed by a REINDEX, and issue a HINT with all of them saying that they should REINDEX the broken index? That would seem to me to be really helpful for people. Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] ERROR: Index pg_toast_8443892_index is not a btree
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Is there anything stopping us going through the code and finding all ereports that can be fixed by a REINDEX, and issue a HINT with all of them saying that they should REINDEX the broken index? How would you know which ones correspond to REINDEX-fixable conditions? I generally dislike hints that tell people their first action should be to destroy the evidence, anyway. If they had an index problem, REINDEX will guarantee there is no chance of learning anything about it. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Something's not (de)compressing right
Elliot Lee [EMAIL PROTECTED] writes: http://archives.postgresql.org/pgsql-hackers/2000-07/msg00483.php I'm having this same problem with postgresql 7.3.4. You aren't having the same problem, because that UNION bug was fixed ages ago. Easy to reproduce by running an 'INSERT' query. Let's see the test case then ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 73.5 and uw 713
[EMAIL PROTECTED] writes: Is there ay way I can help with this debugging? Can you speculate on what might have caused the crash? Is the crash reproducible? When the backend crashed, it should have produced a core file (assuming your system is configured to do so). Can you post the stacktrace you can get from this core file (preferably after you've recompiled PG with debugging symbols) and post it to the list? -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Minor (very) feature request...
Steve Wampler wrote: Would it be (is it?) possible to add timestamp to the log messages put out by postgresql? I've got several databases running in an environment where users have this annoying habit of coming up to me with (Oh yes, three days ago around 4pm our instrument had trouble writing to database X.). Having some way of telling which messages were output when would be helpful in such cases, since I'm not allowed to beat the users into submission... I thought the postgresql.conf option log_timestamp was added precisely for that purpose. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
