Re: SearchSysCacheTuple(Copy)

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SearchSysCacheTuple(Copy)
Date: 2000-11-15 01:12:22
Message-ID: 3A11E2F5.1E05174@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> I said:
> > This class of bugs has been there since the beginning of Postgres,
> > so I do not feel that we need to panic about it. Let's take the
> > time to design and implement a proper solution, rather than expending
> > effort on a stopgap solution that'll have to be undone later.
>
> I've reviewed the earlier threads on SearchSysCache and done some more
> thinking. Here is a concrete proposal for doing it right:
>
> 1. Add a reference-count field and an already-dead boolean to each

[snip]

I agree with your proposal.

>
> Callers that want to be certain they have a completely-up-to-date copy
> should acquire a suitable lock on the associated system relation before
> calling SearchSysCache().

I'm suspcious if it's practical.
What is a suitable lock ?
The lock should conflict with RowExclusiveLock at least.
It must be one of the lock which is stronger than Row
ExclusiveLock or ShareLock(ShareLock is neither stronger
nor weaker than RowExclusiveLock).
RowExclusiveLock doesn't conflcit each other.
There seems to be few places where above locks for
system relations are appropriate.

Regards.
Hiroshi Inoue

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chih-Chang Hsieh 2000-11-15 01:16:58 Re: [PATCHES] A Patch for MIC to EUC_TW code converting inmbsupport
Previous Message Tatsuo Ishii 2000-11-15 00:59:48 Re: can't insert "³\" as varchar in 7.0.2 and 7.1