Are ctid chaining loops safe without relation size checks?

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Are ctid chaining loops safe without relation size checks?
Date: 2019-05-15 19:02:09
Message-ID: 20190515190209.eacokhc7rjd3t2fo@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

While looking at [1] I was rephrasing this comment + chck in
heap_get_latest_tid():

- * Since this can be called with user-supplied TID, don't trust the input
- * too much. (RelationGetNumberOfBlocks is an expensive check, so we
- * don't check t_ctid links again this way. Note that it would not do to
- * call it just once and save the result, either.)
*/
- 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?

And it's not just heap_get_latest_tid() afaict. As far as I can tell
just about every ctid chaining code ought to test the t_ctid link
against the relation size - otherwise it seems entirely possible to get
"could not read block %u in file \"%s\": %m" or
"could not read block %u in file \"%s\": read only 0 of %d bytes"
style errors, no?

These loops are of such long-standing vintage, that I feel like I must
be missing something.

Greetings,

Andres Freund

[1] https://www.postgresql.org/message-id/20190515185447.gno2jtqxyktylyvs%40alap3.anarazel.de

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-15 19:05:43 ClonedConstraint typedef is dead code?
Previous Message Andres Freund 2019-05-15 18:54:47 Re: Pluggable Storage - Andres's take