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
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 |