Re: Are ctid chaining loops safe without relation size checks?

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Are ctid chaining loops safe without relation size checks?
Date: 2019-05-15 19:07:13
Message-ID: 20190515190713.GA5326@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-May-15, Andres Freund wrote:

> - blk = ItemPointerGetBlockNumber(tid);
> - if (blk >= RelationGetNumberOfBlocks(relation))
> - elog(ERROR, "block number %u is out of range for relation \"%s\"",
> - blk, RelationGetRelationName(relation));
>
> Which I dutifully rewrote. But I'm actually not sure it's safe at all
> for heap to rely on t_ctid links to be valid. What prevents a ctid link
> to point to a page that's since been truncated away?

Umm .. IIUC all index entries for truncated pages should have been
removed prior to the truncation. Otherwise, how would those index
entries not become immediately data corruption the instant the heap is
re-grown to cover those truncated pages? So I think if the TID comes
directly from user then this is a check worth doing, but if the TID
comes from an index, then it isn't.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-15 19:09:34 Re: Are ctid chaining loops safe without relation size checks?
Previous Message Tom Lane 2019-05-15 19:05:43 ClonedConstraint typedef is dead code?