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-25 21:14:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackerspgsql-patches
Tom Lane wrote:
> 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.

This plan includes having the list of hash tables that mustn't be 
expanded? And the list would be cleaned up at the end of transaction, to 
avoid leaks.

> 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.

Sounds good to me.

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2007-04-25 21:44:25
Subject: Re: Avoiding unnecessary reads in recovery
Previous:From: Tom LaneDate: 2007-04-25 21:08:49
Subject: Re: Vacuum-full very slow

pgsql-bugs by date

Next:From: Tom LaneDate: 2007-04-25 21:46:47
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Previous:From: Jeff DavisDate: 2007-04-25 20:57:09
Subject: Re: pg_dump doesn't properly honor -O for sequences

pgsql-patches by date

Next:From: Magnus HaganderDate: 2007-04-25 21:31:20
Subject: Re: Fix for MSVC header installation
Previous:From: Tom LaneDate: 2007-04-25 20:56:46
Subject: Re: Fix for MSVC header installation

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