From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Zhihong Yu <zyu(at)yugabyte(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: casting operand to proper type in BlockIdGetBlockNumber |
Date: | 2022-03-03 21:45:14 |
Message-ID: | 3441768.1646343914@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> The message says:
> src/backend/utils/adt/tid.c:112:16: runtime error: left shift of 65535 by 16 places cannot be represented in type 'int'
> Afaics that means bi_hi is 65535. So either we're dealing with a very large
> relation or BlockIdGetBlockNumber() is getting passed InvalidBlockNumber?
Presumably the latter, since we surely aren't using any terabyte-size
relations in our tests.
> It might be enough to do something like
> SELECT * FROM pg_class WHERE ctid = '(65535, 17)';
> to trigger the problem?
I tried to provoke it with cases like
# select '(-1,0)'::tid;
tid
----------------
(4294967295,0)
(1 row)
# select '(4000000000,1)'::tid;
tid
----------------
(4000000000,1)
(1 row)
without success.
On a nearby topic, I see that tidin's overflow checks are somewhere
between sloppy and nonexistent:
# select '(40000000000,1)'::tid;
tid
----------------
(1345294336,1)
(1 row)
I think I'll fix that while I'm looking at it ... but it still
doesn't explain why no complaint in tidout.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2022-03-03 22:00:23 | Re: pg_stop_backup() v2 incorrectly marked as proretset |
Previous Message | Tom Lane | 2022-03-03 21:40:42 | Re: pg_stop_backup() v2 incorrectly marked as proretset |