Re: Lyris looking to help fix PostgresSQL crashing problems
От | Bruce Momjian |
---|---|
Тема | Re: Lyris looking to help fix PostgresSQL crashing problems |
Дата | |
Msg-id | 200209220422.g8M4M9L14276@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Lyris looking to help fix PostgresSQL crashing problems (John Buckman <john@lyris.com>) |
Список | pgsql-hackers |
John Buckman wrote: > > John Buckman <john@lyris.com> writes: > > > It seems that with larger database sizes (500,000 rows and larger) and > > > high stress, the server daemon has a tendency to core. > > > We'd love to see some stack traces ... > > Yeah, I just didn't know what form this list prefers to work on > things, which is why I'd prefer to hire a regular participant > of this list. If gcc 'where' stack traces are what you want, > we can do that. Yep, in most cases, the crash creates a core file in the database directory. A backtrace of that core file is usually a good start. You should to sure there are debugging symbols in the binary (gcc -g). The server log files also often contain valuable information. > I suspect that the problems may be platform-or-build related, > because we've often had trouble replicating customer problems > on our own systems. For example, we had many reports of problems > with 7.2.x, and saw it crash often on a customer's redhat machine > that we had ssh access to, but couldn't make it crash in our > own lab. :( That's why we need help. If we could make a simple > C test case that crashed pgsql, I'm sure you guys could fix the > problem in a jiffy. Yes, that does make it harder, but a backtrace usually gets us started. It may also be tickling some OS bug or a hardware failure, or a simple exhaustion of some resource. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: