On 09/09/2021 17:25, Tom Lane wrote:
Having done that, the check in md.c could be reduced to an Assert,
although there's something to be said for leaving it as-is as an
extra layer of defense.
Some operations call smgrextend() directly, like B-tree index creation.
We don't want those operation
Christoph Berg writes:
>> Can you provide a stack trace from that?
> #2 0x558b6223d46e in ExceptionalCondition
> (conditionName=conditionName@entry=0x558b623b2577 "tagPtr->blockNum != P_NEW",
> errorType=errorType@entry=0x558b6229b016 "FailedAssertion",
> fileName=fileName@entry=0x5
Re: Tom Lane
> Can you provide a stack trace from that?
PG log:
TRAP: FailedAssertion("tagPtr->blockNum != P_NEW", File:
"./build/../src/backend/storage/buffer/buf_table.c", Line: 125)
postgres: 13/main: cbe postgres [local]
INSERT(ExceptionalCondition+0x7d)[0x558b6223d44d]
postgres: 13/main: c
Christoph Berg writes:
> I was wondering what happens when the 32 TiB per table limit is
> reached, so I faked 32767 1 GiB sparse files using dd and then tried
> inserting more rows.
> On a cassert-enabled build I got:
> TRAP: FailedAssertion("tagPtr->blockNum != P_NEW", File:
> "./build/../src
On Thu, Sep 9, 2021 at 7:52 AM Christoph Berg
wrote:
> Shouldn't the cassert build raise the ERROR instead as well?
We should definitely get an ERROR in both cases, not an assertion
failure. Exactly which ERROR we get seems negotiable.
--
Robert Haas
EDB: http://www.enterprisedb.com
I was wondering what happens when the 32 TiB per table limit is
reached, so I faked 32767 1 GiB sparse files using dd and then tried
inserting more rows.
On a cassert-enabled build I got:
TRAP: FailedAssertion("tagPtr->blockNum != P_NEW", File:
"./build/../src/backend/storage/buffer/buf_table.c"
