I wrote:
> #4 0x4e85b4 in ExceptionalCondition (
> conditionName=0x1ac4ac "!(nestLevel > 0 && nestLevel <= GUCNestLevel)",
> errorType=0x1abf44 "FailedAssertion", fileName=0x1abee4 "guc.c",
> lineNumber=3907) at assert.c:57
> #5 0x501f48 in AtEOXact_GUC (isCommit=-86 'ª', nestLevel=
Andrew Dunstan writes:
> Tom Lane wrote:
>> #5 0x501f48 in AtEOXact_GUC (isCommit=-86 'ª', nestLevel=84) at guc.c:3907
> This looks like maybe a corrupted stack - the args to AtEOXact_GUC at
> that location in xact.c are hardwired.
No, that's just a fairly typical behavior of debugging with -O
Tom Lane wrote:
#4 0x4e85b4 in ExceptionalCondition (
conditionName=0x1ac4ac "!(nestLevel > 0 && nestLevel <= GUCNestLevel)",
errorType=0x1abf44 "FailedAssertion", fileName=0x1abee4 "guc.c",
lineNumber=3907) at assert.c:57
#5 0x501f48 in AtEOXact_GUC (isCommit=-86 'ª', nestLeve
In a somewhat misguided attempt to test something else, I did this in
CVS HEAD:
do $$begin
for i in 1 .. 1 loop
execute 'create table t' || i::text || ' (f1 int primary key)';
end loop;
end$$;
This ran for awhile and then ran out of lock table space,
