Skip site navigation (1) Skip section navigation (2)

Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Dorochevsky, Michel" <michel(dot)dorochevsky(at)softcon(dot)de>, pgsql-bugs(at)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Date: 2007-04-24 20:04:03
Message-ID: 462E62B3.6080808@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackerspgsql-patches
Tom Lane wrote:
> The pending-fsync stuff in md.c is also expecting to be able to add
> entries during a scan.

No, mdsync starts the scan from scratch after calling AbsorbFsyncRequests.

> I don't think we can go in the direction of forbidding insertions during
> a scan --- as the case at hand shows, it's just not always obvious that
> that could happen, and finding/fixing such a problem is nigh impossible.
> (We were darn fortunate to be able to reproduce this one.)  Plus we have
> a couple of places where it's really necessary to be able to do it,
> anyway.
> 
> The only answer I can see that seems reasonably robust is to change
> dynahash.c so that it tracks whether any seq_search scans are open on a
> hashtable, and doesn't carry out any splits while one is.  This wouldn't
> cost anything noticeable in performance, assuming that not very many
> splits are postponed.  The PITA aspect of it is that we'd need to add
> bookkeeping mechanisms to ensure that the count of active scans gets
> cleaned up on error exit.  It's not like we've not got lots of those,
> though.

We could have two kinds of seq scans, with and without support for 
concurrent inserts. If you open a scan without that support, it acts 
just like today, and no extra bookkeeping or clean up by the caller is 
required. If you need concurrent inserts, we inhibit bucket splits, but 
it's up to the caller to explicitly close the scan, possibly with 
PG_TRY/CATCH. I'm not sure if that's simpler in the end, but we could 
get away without adding generic bookkeeping mechanism.

> Possibly we could simplify matters a bit by not worrying about cleaning
> up leaked counts at subtransaction abort, ie, the list of open scans
> would only get forced to empty at top transaction end.  This carries a
> slightly higher risk of meaningful performance degradation, but in
> practice I doubt it's a big problem.  If we agreed that then we'd not
> need ResourceOwner support --- it could be handled like LWLock counts.

Hmm. Unlike lwlocks, hash tables can live in different memory contexts, 
so we can't just have list of open scans similar to held_lwlocks array.

Do we need to support multiple simultaneous seq scans of a hash table? I 
suppose we do..

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-04-24 20:25:40
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Previous:From: Bruce MomjianDate: 2007-04-24 19:54:49
Subject: Re: [HACKERS] Email signature in release announcement posting

pgsql-bugs by date

Next:From: Tom LaneDate: 2007-04-24 20:25:40
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Previous:From: Gary WinslowDate: 2007-04-24 18:55:18
Subject: BUG #3253: 8.2.4 Installer Displays No Default Install Path and Browse Error 2864

pgsql-patches by date

Next:From: Tom LaneDate: 2007-04-24 20:25:40
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Previous:From: Tom LaneDate: 2007-04-24 18:19:30
Subject: Re: [HACKERS] Full page writes improvement, code update

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group