On Tue, Oct 29, 2013 at 10:47 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-10-28 11:54:31 -0400, Robert Haas wrote:
>> > There's one snag I currently can see, namely that we actually need to
>> > prevent that a formerly dropped relfilenode is getting reused. Not
>> > entirely sure what the best way for that is.
>>
>> I'm not sure in detail, but it seems to me that this all part of the
>> same picture. If you're tracking changed relfilenodes, you'd better
>> track dropped ones as well.
>
> What I am thinking about is the way GetNewRelFileNode() checks for
> preexisting relfilenodes. It uses SnapshotDirty to scan for existing
> relfilenodes for a newly created oid. Which means already dropped
> relations could be reused.
> I guess it could be as simple as using SatisfiesAny (or even better a
> wrapper around SatisfiesVacuum that knows about recently dead tuples).
I think modifying GetNewRelFileNode() is attacking the problem from
the wrong end. The point is that when a table is dropped, that fact
can be communicated to the same machine machinery that's been tracking
the CTID->CTID mappings. Instead of saying "hey, the tuples that were
in relfilenode 12345 are now in relfilenode 67890 in these new
positions", it can say "hey, the tuples that were in relfilenode 12345
are now GONE".
>> Completely aside from this issue, what
>> keeps a relation from being dropped before we've decoded all of the
>> changes made to its data before the point at which it was dropped? (I
>> hope the answer isn't "nothing".)
>
> Nothing. But there's no need to prevent it, it'll still be in the
> catalog and we don't ever access a non-catalog relation's data during
> decoding.
Oh, right. But what about a drop of a user-catalog table?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
