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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
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-25 19:07:21
Message-ID: 3918.1177528041@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackerspgsql-patches
I wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>> We could have two kinds of seq scans, with and without support for 
>> concurrent inserts.

> Yeah, I considered that too, but it just seems too error-prone.  We
> could maybe make it trustworthy by having hash_seq_search complain if
> it noticed there had been any concurrent insertions --- but then you're
> putting new overhead into hash_seq_search, which kind of defeats the
> argument for it (and hash_seq_search is a bit of a bottleneck, so extra
> cycles there matter).

I just finished looking through the uses of hash_seq_search, and
realized that there is one place where it would be a bit painful to
convert to the insertion-safe approach I'm proposing; namely nodeAgg.c.
The places where the hashtable iteration is started and used are
scattered, and we don't really track whether the iteration is done or
not, so it's hard to be sure where to cancel the iteration.  It could
probably be made to work but it seems like it'd be fragile.

I still don't want to introduce more checking overhead into
hash_seq_search, though, so what I'm now thinking about is a new
dynahash primitive named something like "hash_freeze", which'd mark a
hashtable as disallowing insertions.  If the hashtable is frozen before
hash_seq_init then we don't add it to the central list of scans, and
therefore there is no cleanup to do at the end.  nodeAgg can use this
mode since it doesn't modify its hashtable anymore after beginning its
readout scan.

BTW, we didn't really get into details, but for the insertion-safe case
I'm envisioning adding a routine "hash_seq_term", which you would need
to call if and only if you abandon a hash_seq_search scan without
running it to completion (if you do the complete scan, hash_seq_search
will automatically call hash_seq_term before returning NULL).  All but
a very small number of places run their searches to completion and
therefore won't require any source code changes with this API.

Thoughts?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Stefan KaltenbrunnerDate: 2007-04-25 19:11:22
Subject: Re: strange buildfarm failures
Previous:From: Alvaro HerreraDate: 2007-04-25 19:04:20
Subject: Re: Vacuum-full very slow

pgsql-bugs by date

Next:From: Kevin GrittnerDate: 2007-04-25 20:15:03
Subject: Re: BUG #3252: Select Order by time
Previous:From: Jeff DavisDate: 2007-04-25 18:48:53
Subject: Re: not bug after all, sorry for the noise

pgsql-patches by date

Next:From: Andrew DunstanDate: 2007-04-25 19:19:41
Subject: Re: Fix for MSVC header installation
Previous:From: Dave PageDate: 2007-04-25 19:03:12
Subject: Re: Fix for MSVC header installation

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