Re: s_lock_stuck (was Problems w/ LO)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: t-ishii(at)sra(dot)co(dot)jp
Cc: "hackers(at)postgreSQL(dot)org" <hackers(at)postgreSQL(dot)org>
Subject: Re: s_lock_stuck (was Problems w/ LO)
Date: 1999-05-31 19:39:54
Message-ID: 16502.928179594@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> I've been looking into the "stuck spin lock" problem under high
> load. Unless it being solved, PostgreSQL would not be usable in the
> "real world."

> Question to hackers: Why does s_lock_stuck() call abort()? Shouldn't
> be elog(ERROR) or elog(FATAL)?

I think that is probably the right thing. elog(ERROR) will not do
anything to release the stuck spinlock, and IIRC not even elog(FATAL)
will. The only way out is to clobber all the backends and reinitialize
shared memory. The postmaster will not do that unless a backend dies
without making an exit report --- which means doing abort().

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 1999-05-31 19:51:06 Re: [HACKERS] please?
Previous Message Pablo Funes 1999-05-31 19:27:58 Re: [HACKERS] please?