Re: [SQL] Storing an ordered list
On Wed, Jul 26, 2006 at 20:13:03 -0400, Michael Artz <[EMAIL PROTECTED]> wrote: > On 7/26/06, Bruno Wolff III <[EMAIL PROTECTED]> wrote: > >If you use numeric instead of int, then it is easy to insert new values. > > Hmm, hadn't thought about that. How would you normally implement it? > I'm thinking that, if I wanted to insert between A and B, I could take > (A.order + B.order)/2, which would be pretty simple. Is there a > better way? I think that will depend. To keep the size of the number down, you will probably want to use the number with the fewest digits to the right of the decimal point that gives you a number between the two values. That will be a bit more complicated than the above formula. But you will want to do something to keep the size of the numerics down since it seems like reordering will be common. Another issue to consider is concurrency. You may want to lock the table against concurrent reordering, as doing two at once may lead to some unexpected events. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[SQL] PostgreSQL server terminated by signal 11
Hi, My PostgreSQL server running on a Linux machine is terminated by signal 11 whenever I try to create some indexes on a table, which contains quite a lot of data. However I succeeded in creating some other indexes without having the PostgreSQL server terminated: agora=> CREATE INDEX IDX_GSLOG_EVENTTIME agora-> ON GSLOG_EVENT (EVENT_DATE_CREATED); CREATE INDEX Time: 152908.797 ms agora=> explain analyze select max(event_date_created) from gslog_event; QUERY PLAN -- Result (cost=3.80..3.81 rows=1 width=0) (actual time=0.218..0.221 rows=1 loops=1) InitPlan -> Limit (cost=0.00..3.80 rows=1 width=8) (actual time=0.197..0.200 rows=1 loops=1) -> Index Scan Backward using idx_gslog_eventtime on gslog_event (cost=0.00..39338251.59 rows=10348246 width=8) (actual time=0.188..0.188 rows=1 loops=1) Filter: (event_date_created IS NOT NULL) Total runtime: 0.324 ms (6 rows) Time: 41.085 ms agora=> CREATE INDEX IDX_GSLOG_EVENT_SPREAD_PROTOCOL_NAME agora-> ON GSLOG_EVENT (EVENT_DATE_CREATED) agora-> WHERE EVENT_NAME::text <> 'player-login'::text agora-> AND PLAYER_USERNAME IS NOT NULL agora-> AND GAME_CLIENT_VERSION IS NULL; server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. The PostgreSQL log file doesn’t give more information about what went wrong, except that the server process has been terminated: LOG: server process (PID 22270) was terminated by signal 11 LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing FATAL: the database system is starting up LOG: database system was interrupted at 2006-07-27 15:29:27 GMT LOG: checkpoint record is at 249/179D44A8 LOG: redo record is at 249/179D44A8; undo record is at 0/0; shutdown FALSE LOG: next transaction ID: 543712876; next OID: 344858 LOG: next MultiXactId: 2; next MultiXactOffset: 3 LOG: database system was not properly shut down; automatic recovery in progress LOG: redo starts at 249/179D44EC LOG: record with zero length at 249/179E4888 LOG: redo done at 249/179E2DFC LOG: database system is ready LOG: transaction ID wrap limit is 2147484146, limited by database "postgres" I checked the memory installed on the machine, running memtest86 during more than one day; no error found. I checked bad blocks on every hard drive installed in this machine, using e2fsck -c /dev/hdxx; no bad block found. I’ve already dropped the table, inserted data, and tried to create all the indexes. The server systematically crashed when creating some specific indexes. The only idea I have for the moment would be to setup another machine with the same database environment. Other idea(s)? Thanks -- Daniel CAUNE Ubisoft Online Technology (514) 490 2040 ext. 3613
[SQL] Disk is full, what's cool to get rid of?
Hello, quick question. I've run into an issue with the disk that my development box is on filling up and preventing pretty much any writing (inserts, updates, deletes, etc...) from happening. Other than some piddly text logs the db is pretty much the only thing on the box. So, my question is: what can I do to free space and run a full vacuum? (I was not the one who set up this box and there has been virtually no administration or maintenance on it that I know of...) How about the WAL files in pg_xlog? How critical are they when no data on the system is critical in and of itself? Any suggestions would be greatly appreciated... -- erik jones <[EMAIL PROTECTED]> software development emma(r) ---(end of broadcast)--- TIP 1: 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: [SQL] Disk is full, what's cool to get rid of?
You can probably just "tune2fs -m 0 " to give yourself enough space to get out of the jam before you go deleting things. Then you might want to vacuum full afterwards. On Thu, 27 Jul 2006, Erik Jones wrote: Hello, quick question. I've run into an issue with the disk that my development box is on filling up and preventing pretty much any writing (inserts, updates, deletes, etc...) from happening. Other than some piddly text logs the db is pretty much the only thing on the box. So, my question is: what can I do to free space and run a full vacuum? (I was not the one who set up this box and there has been virtually no administration or maintenance on it that I know of...) How about the WAL files in pg_xlog? How critical are they when no data on the system is critical in and of itself? Any suggestions would be greatly appreciated... -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [SQL] Disk is full, what's cool to get rid of?
> administration or maintenance on it that I know of...) How about the > WAL files in pg_xlog? How critical are they when no data on the system > is critical in and of itself? Any suggestions would be greatly > appreciated... If the data isn't critical, you maybe could truncate a table to clear enough space. Deleting anything under pg_xlog is more or less guaranteed to mean your database is garbage. A -- Andrew Sullivan | [EMAIL PROTECTED] If they don't do anything, we don't need their acronym. --Josh Hamilton, on the US FEMA ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] PostgreSQL server terminated by signal 11
On Thu, 27 Jul 2006, Daniel Caune wrote: My PostgreSQL server running on a Linux machine is terminated by signal 11 whenever I try to create some indexes on a table, which contains quite a lot of data. However I succeeded in creating some other indexes without having the PostgreSQL server terminated: Daniel, I would guess this is more appropriate for the -admin list so I cc'd it. I think you are most likely running out of memory or running up against a ulimit on memory. I would first check my ulimit settings on the postgres user and see if they are a bit small. -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [SQL] Storage of Binary Data
> For my web projects, we have been storing binary data (like images, PDF's, > etc) on the hard drive of the web server instead of the database. Within > the database, we keep information, like whether an image is present, in a > separate column. In most cases, this is probably the best approach. It has the problem that COMMITs of this data aren't atomic (the file write could succeed and the database write fail, for example). But that can usually be worked around, and at least you're not bulking your database with binaries. A -- Andrew Sullivan | [EMAIL PROTECTED] This work was visionary and imaginative, and goes to show that visionary and imaginative work need not end up well. --Dennis Ritchie ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [SQL] Disk is full, what's cool to get rid of?
I can't tell you the number of times that little trick has saved my life. On Thu, 2006-07-27 at 11:32, Jeff Frost wrote: > You can probably just "tune2fs -m 0 " to give yourself enough > space to get out of the jam before you go deleting things. Then you might > want to vacuum full afterwards. > > On Thu, 27 Jul 2006, Erik Jones wrote: > > > Hello, quick question. I've run into an issue with the disk that my > > development box is on filling up and preventing pretty much any writing > > (inserts, updates, deletes, etc...) from happening. Other than some piddly > > text logs the db is pretty much the only thing on the box. So, my question > > is: what can I do to free space and run a full vacuum? (I was not the one > > who set up this box and there has been virtually no administration or > > maintenance on it that I know of...) How about the WAL files in pg_xlog? > > How critical are they when no data on the system is critical in and of > > itself? Any suggestions would be greatly appreciated... > > > > ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [SQL] Disk is full, what's cool to get rid of?
Awesome. Do I need to reset that to any magic # after the vacuum? I'm not all that up on filesystem maintenance/tweaking... Scott Marlowe wrote: I can't tell you the number of times that little trick has saved my life. On Thu, 2006-07-27 at 11:32, Jeff Frost wrote: You can probably just "tune2fs -m 0 " to give yourself enough space to get out of the jam before you go deleting things. Then you might want to vacuum full afterwards. On Thu, 27 Jul 2006, Erik Jones wrote: Hello, quick question. I've run into an issue with the disk that my development box is on filling up and preventing pretty much any writing (inserts, updates, deletes, etc...) from happening. Other than some piddly text logs the db is pretty much the only thing on the box. So, my question is: what can I do to free space and run a full vacuum? (I was not the one who set up this box and there has been virtually no administration or maintenance on it that I know of...) How about the WAL files in pg_xlog? How critical are they when no data on the system is critical in and of itself? Any suggestions would be greatly appreciated... ---(end of broadcast)--- TIP 6: explain analyze is your friend -- erik jones <[EMAIL PROTECTED]> software development emma(r) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [SQL] Disk is full, what's cool to get rid of?
Depends what the default is on your system. The default is 5% with the version of mke2fs that I have here, so you would just: tune2fs -m 5 to put it back. On Thu, 27 Jul 2006, Erik Jones wrote: Awesome. Do I need to reset that to any magic # after the vacuum? I'm not all that up on filesystem maintenance/tweaking... Scott Marlowe wrote: I can't tell you the number of times that little trick has saved my life. On Thu, 2006-07-27 at 11:32, Jeff Frost wrote: You can probably just "tune2fs -m 0 " to give yourself enough space to get out of the jam before you go deleting things. Then you might want to vacuum full afterwards. On Thu, 27 Jul 2006, Erik Jones wrote: Hello, quick question. I've run into an issue with the disk that my development box is on filling up and preventing pretty much any writing (inserts, updates, deletes, etc...) from happening. Other than some piddly text logs the db is pretty much the only thing on the box. So, my question is: what can I do to free space and run a full vacuum? (I was not the one who set up this box and there has been virtually no administration or maintenance on it that I know of...) How about the WAL files in pg_xlog? How critical are they when no data on the system is critical in and of itself? Any suggestions would be greatly appreciated... ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [SQL] Disk is full, what's cool to get rid of?
Awesome. Makes sense as 5% is exactly the amount of space that appeared after running it. Thanks! Jeff Frost wrote: Depends what the default is on your system. The default is 5% with the version of mke2fs that I have here, so you would just: tune2fs -m 5 to put it back. On Thu, 27 Jul 2006, Erik Jones wrote: Awesome. Do I need to reset that to any magic # after the vacuum? I'm not all that up on filesystem maintenance/tweaking... Scott Marlowe wrote: I can't tell you the number of times that little trick has saved my life. On Thu, 2006-07-27 at 11:32, Jeff Frost wrote: You can probably just "tune2fs -m 0 " to give yourself enough space to get out of the jam before you go deleting things. Then you might want to vacuum full afterwards. On Thu, 27 Jul 2006, Erik Jones wrote: Hello, quick question. I've run into an issue with the disk that my development box is on filling up and preventing pretty much any writing (inserts, updates, deletes, etc...) from happening. Other than some piddly text logs the db is pretty much the only thing on the box. So, my question is: what can I do to free space and run a full vacuum? (I was not the one who set up this box and there has been virtually no administration or maintenance on it that I know of...) How about the WAL files in pg_xlog? How critical are they when no data on the system is critical in and of itself? Any suggestions would be greatly appreciated... ---(end of broadcast)--- TIP 6: explain analyze is your friend -- erik jones <[EMAIL PROTECTED]> software development emma(r) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [SQL] PostgreSQL server terminated by signal 11
"Daniel Caune" <[EMAIL PROTECTED]> writes: > My PostgreSQL server running on a Linux machine is terminated by signal > 11 whenever I try to create some indexes on a table, which contains > quite a lot of data. Judging from your examples it's got something to do with the partial index WHERE clause. What PG version is this exactly? If you leave out different parts of the WHERE, does it still crash? Does the crash happen immediately after you give the command, or does it run for awhile? It might be worth getting a stack trace from the failure (best way is to attach to the running backend with gdb, provoke the crash, and do "bt" --- search for "gdb" in the archives if you need details). regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] Disk is full, what's cool to get rid of?
Andrew Sullivan <[EMAIL PROTECTED]> writes: > If the data isn't critical, you maybe could truncate a table to clear > enough space. Deleting anything under pg_xlog is more or less > guaranteed to mean your database is garbage. If you're desperate you could shut down the postmaster, run pg_resetxlog, restart the postmaster. This would cut xlog contents to the minimum --- however, they'd probably soon grow back to whatever they are now, so it's not much of a long-term solution. It might give you some breathing room to look for other places to trim though. If the database hasn't been maintained well then you likely are suffering from table bloat and/or index bloat. A desperation measure for fixing that is drop all indexes, vacuum full, recreate all indexes. (There are other procedures you may find recommended, such as CLUSTER, but they have transient disk-space requirements that you're not gonna be able to afford when your back is to the wall.) regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [SQL] Disk is full, what's cool to get rid of?
Won't help some of us, who set -m 0 on selected filesystems to begin with. But if we could get tune2fs -m -5 to work, then we could unreserve space that didn't previously exist. Think of the possibilties! I'll look into that as soon as I'm done modding my C compiler to handle the --force option. -cw- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erik Jones Sent: Thursday, July 27, 2006 4:00 PM To: Jeff Frost Cc: Scott Marlowe; General Postgresql List Subject: Re: [SQL] Disk is full, what's cool to get rid of? Awesome. Makes sense as 5% is exactly the amount of space that appeared after running it. Thanks! Jeff Frost wrote: > Depends what the default is on your system. The default is 5% with > the version of mke2fs that I have here, so you would just: > > tune2fs -m 5 > > to put it back. > ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[SQL] return setof records
Alright, first I'll apologize for asking this question another time. I've looked throught the archives and have found different ways on both the archives and different ways in the the documentation to do this and depending on which way I do it, I get different errors, so pick your poison on that. Everywhere I've looked the agreement was that making a call to the function had to be done as follows: SELECT * FROM sp_frontalerts_summary(1,'2006-07-27 18:08:09','2006-07-27 19:58:15' ) as (numitems int, region int); So there isn't a question on that. My question is, how do I return a "setof record" back to the application. I've tried the following ways: - CREATE OR REPLACE FUNCTION sp_frontalerts_summary (p_usernum int, p_lastlogin TIMESTAMP,p_now TIMESTAMP) RETURNS SETOF RECORD AS $$ DECLARE returnRecord RECORD; BEGIN FOR returnRecord in select count(item) as numitems,0 as region from frontalerts where usernum=p_usernum and pinup=0 LOOP RETURN NEXT returnRecord; END LOOP; RETURN; END; $$ LANGUAGE plpgsql; - Also have tried it with EXECUTE after the "FOR returnRecord in" and before the "select count(item)..." Also have tried to do just a "select count(item) as numitems,0 as region from frontalerts where usernum=p_usernum and pinup=0" without any type of returning (only a "RETURNS SETOF RECORD AS $$..") (the way that the documentation talks about doing it in one area) Now this is a little of a simplified version, but I have the same problem with all of the stored procs. If you know what I'm doing wrong, please let me know. Or if you have anything I should possibly try, let me know that too. I've searched high and low and really thought I had it this time, but I guess not. Also, sorry for such an easy question, but I'm new to PostgreSQL so this port from MS SQL to PostgreSQL on someone else's code is kickin my butt. Thank you in adavance for any help. Chris ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [SQL] PostgreSQL server terminated by signal 11
> De : Tom Lane [mailto:[EMAIL PROTECTED] > Envoyé : jeudi, juillet 27, 2006 16:06 > À : Daniel Caune > Cc : pgsql-sql@postgresql.org > Objet : Re: [SQL] PostgreSQL server terminated by signal 11 > > "Daniel Caune" <[EMAIL PROTECTED]> writes: > > My PostgreSQL server running on a Linux machine is terminated by signal > > 11 whenever I try to create some indexes on a table, which contains > > quite a lot of data. > > Judging from your examples it's got something to do with the partial > index WHERE clause. What PG version is this exactly? If you leave out > different parts of the WHERE, does it still crash? Does the crash > happen immediately after you give the command, or does it run for > awhile? It might be worth getting a stack trace from the failure > (best way is to attach to the running backend with gdb, provoke the > crash, and do "bt" --- search for "gdb" in the archives if you need > details). > > regards, tom lane The postgres server version is 8.1.4. Yes, if leave the WHERE clause a simple index, I don't encounter any problem: CREATE INDEX IDX_GSLOG_EVENTTIME ON GSLOG_EVENT (EVENT_DATE_CREATED); Anyway, I'm not sure, Tom, that is only related to the WHERE clause as crash occur with composite index too, such as: CREATE INDEX IDX_GSLOG_EVENT_PLAYER_EVENT ON GSLOG_EVENT (PLAYER_USERNAME, EVENT_NAME); The crash may happen a while after sending the command. For example, supposing I reboot the Linux machine and I immediately run the command (i.e. most of memory is unused), it takes more than five minutes before crash occurs. At such time the memory usage is the following (top every second): Mem: 2075860k total, 1787600k used, 288260k free, 6300k buffers Swap: 369452k total,0k used, 369452k free, 1748032k cached When reconnecting to the new postgres respawn, it takes approximately the same time for having it crashing, whatever the number of times I proceed like this. I did some other tests trying to detect any common denominator that may make the postgres server crashing. Here some results are: select max(length(game_client_version)) from gslog_event; => [CRASH] select max(length(game_client_version)) from gslog_event where game_client_version is not null; => [OK, max = 28] select count(*) from gslog_event where length(game_client_version) >= 0; => [OK, count = 4463726] select count(*) from gslog_event where upper(game_client_version) = 'FARCRYPC1.33'; => [OK, count = 576318] select count(*) from gslog_event where lower(player_username) = 'lythanhphu'; => [CRASH] I was thinking about nullable value, but finally, you know what? I have strictly no idea! :-) I'll look at the archive for running postgres with gdb and provide more accurate information. Thanks, -- Daniel ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [SQL] PostgreSQL server terminated by signal 11
> -Message d'origine- > De : Tom Lane [mailto:[EMAIL PROTECTED] > Envoyé : jeudi, juillet 27, 2006 16:06 > À : Daniel Caune > Cc : pgsql-sql@postgresql.org > Objet : Re: [SQL] PostgreSQL server terminated by signal 11 > > "Daniel Caune" <[EMAIL PROTECTED]> writes: > > My PostgreSQL server running on a Linux machine is terminated by signal > > 11 whenever I try to create some indexes on a table, which contains > > quite a lot of data. > > Judging from your examples it's got something to do with the partial > index WHERE clause. What PG version is this exactly? If you leave out > different parts of the WHERE, does it still crash? Does the crash > happen immediately after you give the command, or does it run for > awhile? It might be worth getting a stack trace from the failure > (best way is to attach to the running backend with gdb, provoke the > crash, and do "bt" --- search for "gdb" in the archives if you need > details). > > regards, tom lane Quite a long time I didn't use gdb! :-) Anyway I proceed as described hereafter; correct me if I was wrong. > ps -eaf | grep postgres postgres 2792 2789 0 21:50 pts/200:00:00 su postgres postgres 2793 2792 0 21:50 pts/200:00:00 bash postgres 2902 1 7 22:17 ?00:01:10 postgres: dbo agora [local] idle postgres 2952 1 2 22:32 ?00:00:00 /usr/lib/postgresql/8.1/bin/postmaster -D /var/lib/postgresql/8.1/main -c unix_socket_directory=/var/run/postgresql -c config_file=/etc/postgresql/8.1/main/postgresql.conf -c hba_file=/etc/postgresql/8.1/main/pg_hba.conf -c ident_file=/etc/postgresql/8.1/main/pg_ident.conf postgres 2954 2952 0 22:32 ?00:00:00 postgres: writer process postgres 2955 2952 0 22:32 ?00:00:00 postgres: stats buffer process postgres 2956 2955 0 22:32 ?00:00:00 postgres: stats collector process I connected to the postgres server using psql and I retrieved the backend pid by executing the statement "SELECT pg_backend_pid();" I started gdb under the UNIX account postgres and I attached the backend process providing the pid returned by the statement. I run the command responsible for creating the index and I entered "continue" in gdb for executing the command. After a while, the server crashes: Program received signal SIGSEGV, Segmentation fault. 0x08079e2a in slot_attisnull () (gdb) Continuing. Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. I can't do "bt" since the program no longer exists. How can I provide more information, stack trace, and so on? -- Daniel ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [SQL] PostgreSQL server terminated by signal 11
"Daniel Caune" <[EMAIL PROTECTED]> writes: > I run the command responsible for creating the index and I entered "continue" > in gdb for executing the command. After a while, the server crashes: > Program received signal SIGSEGV, Segmentation fault. > 0x08079e2a in slot_attisnull () > (gdb) > Continuing. > Program terminated with signal SIGSEGV, Segmentation fault. > The program no longer exists. > I can't do "bt" since the program no longer exists. I think you typed one carriage return too many and the thing re-executed the last command, ie, the continue. Try it again. The lack of arguments shown for slot_attisnull suggests that all we're going to get is a list of function names, without line numbers or argument values. If that's not enough to figure out the problem, can you rebuild with --enable-debug to get a more useful stack trace? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [SQL] PostgreSQL server terminated by signal 11
On Thu, 27 Jul 2006 19:00:27 -0400
"Daniel Caune" <[EMAIL PROTECTED]> wrote:
> I run the command responsible for creating the index and I entered "continue"
> in gdb for executing the command. After a while, the server crashes:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08079e2a in slot_attisnull ()
That's a pretty small function. I don't see much room for error. This
diff in src/backend/access/common/heaptuple.c seems like the most
likely place to catch it.
RCS file: /cvsroot/pgsql/src/backend/access/common/heaptuple.c,v
retrieving revision 1.110
diff -u -p -u -r1.110 heaptuple.c
--- heaptuple.c 14 Jul 2006 14:52:16 - 1.110
+++ heaptuple.c 27 Jul 2006 23:37:54 -
@@ -1470,8 +1470,13 @@ slot_getsomeattrs(TupleTableSlot *slot,
bool
slot_attisnull(TupleTableSlot *slot, int attnum)
{
- HeapTuple tuple = slot->tts_tuple;
- TupleDesc tupleDesc = slot->tts_tupleDescriptor;
+ HeapTuple tuple;
+ TupleDesc tupleDesc;
+
+ assert(slot != NULL);
+
+ tuple = slot->tts_tuple;
+ tupleDesc = slot->tts_tupleDescriptor;
/*
* system attributes are handled by heap_attisnull
Of course, you still have to find out what's calling it with slot set
to NULL if that turns out to be the problem. It may also be that slot
is not NULL but set to garbage. You could also add a notice there.
Two, in fact. One to display the address of slot and one to display
the value of slot->tts_tuple or slot->tts_tupleDescriptor. If the
first shows a non NULL value and the second causes your crash that
tells you that the value of slot is probably trashed before
calling the function.
Do this in conjunction with Tom Lanes suggestion of "--enable-debug" for
more information.
--
D'Arcy J.M. Cain | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [SQL] PostgreSQL server terminated by signal 11
> -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > De la part de Tom Lane > Envoyé : jeudi 27 juillet 2006 19:26 > À : Daniel Caune > Cc : pgsql-admin@postgresql.org; pgsql-sql@postgresql.org > Objet : Re: [SQL] PostgreSQL server terminated by signal 11 > > "Daniel Caune" <[EMAIL PROTECTED]> writes: > > I run the command responsible for creating the index and I entered > "continue" in gdb for executing the command. After a while, the server > crashes: > > > Program received signal SIGSEGV, Segmentation fault. > > 0x08079e2a in slot_attisnull () > > (gdb) > > Continuing. > > > Program terminated with signal SIGSEGV, Segmentation fault. > > The program no longer exists. > > > I can't do "bt" since the program no longer exists. > > I think you typed one carriage return too many and the thing re-executed > the last command, ie, the continue. Try it again. > OK, I'll try that tomorrow morning. Perhaps can I set a conditional breakpoint to function slot_attisnull when parameter slot is null (or slot->tts_tupleDescriptor is null). > The lack of arguments shown for slot_attisnull suggests that all we're > going to get is a list of function names, without line numbers or > argument values. If that's not enough to figure out the problem, can > you rebuild with --enable-debug to get a more useful stack trace? > Well, I installed PostgreSQL using apt-get but that won't be a problem to get the source from the CVS repository and to build a postgres binary using the option you provide to me. Just let me the time to do that. :-) Thanks, -- Daniel ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] PostgreSQL server terminated by signal 11
> -Message d'origine-
> De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> De la part de D'Arcy J.M. Cain
> Envoyé : jeudi 27 juillet 2006 19:49
> À : Daniel Caune
> Cc : [EMAIL PROTECTED]; pgsql-admin@postgresql.org; pgsql-
> [EMAIL PROTECTED]
> Objet : Re: [SQL] PostgreSQL server terminated by signal 11
>
> On Thu, 27 Jul 2006 19:00:27 -0400
> "Daniel Caune" <[EMAIL PROTECTED]> wrote:
> > I run the command responsible for creating the index and I entered
> "continue" in gdb for executing the command. After a while, the server
> crashes:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x08079e2a in slot_attisnull ()
>
> That's a pretty small function. I don't see much room for error. This
> diff in src/backend/access/common/heaptuple.c seems like the most
> likely place to catch it.
>
> RCS file: /cvsroot/pgsql/src/backend/access/common/heaptuple.c,v
> retrieving revision 1.110
> diff -u -p -u -r1.110 heaptuple.c
> --- heaptuple.c 14 Jul 2006 14:52:16 - 1.110
> +++ heaptuple.c 27 Jul 2006 23:37:54 -
> @@ -1470,8 +1470,13 @@ slot_getsomeattrs(TupleTableSlot *slot,
> bool
> slot_attisnull(TupleTableSlot *slot, int attnum)
> {
> - HeapTuple tuple = slot->tts_tuple;
> - TupleDesc tupleDesc = slot->tts_tupleDescriptor;
> + HeapTuple tuple;
> + TupleDesc tupleDesc;
> +
> + assert(slot != NULL);
> +
> + tuple = slot->tts_tuple;
> + tupleDesc = slot->tts_tupleDescriptor;
>
> /*
> * system attributes are handled by heap_attisnull
>
> Of course, you still have to find out what's calling it with slot set
> to NULL if that turns out to be the problem. It may also be that slot
> is not NULL but set to garbage. You could also add a notice there.
> Two, in fact. One to display the address of slot and one to display
> the value of slot->tts_tuple or slot->tts_tupleDescriptor. If the
> first shows a non NULL value and the second causes your crash that
> tells you that the value of slot is probably trashed before
> calling the function.
>
Yes, I was afraid to go that deeper, but it's time! :-))
Actually it seems, from the source code, that a null slot->tts_tuple won't lead
to a segmentation fault in function slot_attisnull, while slot and
slot->tts_tupleDescriptor will. I will trace the function trying to discover
what goes wrong behind the scene.
> Do this in conjunction with Tom Lane suggestion of "--enable-debug" for
> more information.
>
OK
--
Daniel
---(end of broadcast)---
TIP 1: 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: [SQL] PostgreSQL server terminated by signal 11
Daniel CAUNE <[EMAIL PROTECTED]> writes: > Actually it seems, from the source code, that a null slot->tts_tuple > won't lead to a segmentation fault in function slot_attisnull, while > slot and slot->tts_tupleDescriptor will. I'll bet on D'Arcy's theory that slot is being passed in as NULL. Exactly why remains to be seen ... we need that stack trace! regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
