Re: Posgresql 7.2b1 crashes
От | mlw |
---|---|
Тема | Re: Posgresql 7.2b1 crashes |
Дата | |
Msg-id | 3BE1A862.6107E4D0@mohawksoft.com обсуждение исходный текст |
Ответ на | Re: Posgresql 7.2b1 crashes ("Mr. Shannon Aldinger" <god@yinyang.hjsoft.com>) |
Список | pgsql-hackers |
Tom Lane wrote: > > "Mr. Shannon Aldinger" <god@yinyang.hjsoft.com> writes: > > I don't have a core file, it died overnight both times so i don't know > > exactly but I can give you the general query it performs. By crash i mean > > the postmaster process is gone along with it's sub-processes or threads. > > Postmaster dies too? Wow. If you aren't seeing a core file, perhaps > it's because you are starting the postmaster under "ulimit -c 0". > You need the process context to be "ulimit -c unlimited" to allow cores > to be dropped. Might be worth running with -d 2 to enable query logging > as well. I have seen the same thing, and I have been trying to reproduce it. I know for a fact that it was in the middle of : (In a C application using libpq.) declare temp_curs binary cursor for select scene_name_full, track from favorites where rating > 6 and track < 1000000000 order by scene_name_full Performing a loop on: fetch 1000 from temp_curs I have lots of memory, lots of disk, I'm pretty sure it isn't a resource issue. (It could be a shared memory issue?) I have not been able to reproduce it. Hope this helps. cdinfo=# explain select scene_name_full, track from favorites where rating > 6 and track < 1000000000 order by scene_name_full; NOTICE: QUERY PLAN: Sort (cost=517675.50..517675.50 rows=2091003 width=18) -> Seq Scan on favorites (cost=0.00..135699.52 rows=2091003 width=18) EXPLAIN
В списке pgsql-hackers по дате отправления: