Re: Re: AW: Re: OID wraparound: summary and proposal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: AW: Re: OID wraparound: summary and proposal
Date
Msg-id 29251.997192134@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: AW: Re: OID wraparound: summary and proposal  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers
Hannu Krosing <hannu@tm.ee> writes:
> Will it be easier to make Relation shared and persistent or creating 
> a new shared structure that has just a counter+lock for each 
> relation oid ?

The latter.  Relation (by which I mean a whole relcache entry with all
its subsidiary structure, not only struct RelationData) is too large,
complex and heavyweight a structure to be a good candidate for moving
into shared memory.  It also contains a lot of backend-local status
data in its current incarnation.

Some kind of shared cache for sequence generators (essentially,
generalizing the existing shared OID counter into N counters) is
probably the answer.  But it would have to be a cache, not the whole
truth, so there'd need to be an underlying table that holds counters not
currently swapped into cache.  That part we don't have a good model for
in the existing OID-generator code, nor in the existing sequence code.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: OID wraparound: summary and proposal
Next
From: Tom Lane
Date:
Subject: Re: Notes about int8 sequences