Some time ago, Grant Finnemore <[EMAIL PROTECTED]> wrote:
> TRAP: FailedAssertion("!(((ntp)->t_data)->t_infomask & 0x0010)", File:
> "catcache.c", Line: 1728)
I think we finally figured out where this came from:
http://archives.postgresql.org/pgsql-bugs/2004-12/msg00128.php
Ok, will do. Thanks.
Tom Lane wrote:
Grant Finnemore <[EMAIL PROTECTED]> writes:
I'm afraid that I did not get a core dump. Sorry.
My normal configure includes both debug and cassert - is there anything
else I should set to ensure core dumps are generated?
Check "ulimit -c" in the postmaster's env
Grant Finnemore <[EMAIL PROTECTED]> writes:
> I'm afraid that I did not get a core dump. Sorry.
> My normal configure includes both debug and cassert - is there anything
> else I should set to ensure core dumps are generated?
Check "ulimit -c" in the postmaster's environment.
Personally I always
I'm afraid that I did not get a core dump. Sorry.
My normal configure includes both debug and cassert - is there anything
else I should set to ensure core dumps are generated?
Regards,
Grant
Tom Lane wrote:
Grant Finnemore <[EMAIL PROTECTED]> writes:
TRAP: FailedAssertion("!(((ntp)->t_data)->t_info
Grant Finnemore <[EMAIL PROTECTED]> writes:
> TRAP: FailedAssertion("!(((ntp)->t_data)->t_infomask & 0x0010)", File:
> "catcache.c", Line: 1728)
This seems moderately impossible :-(. Did you get a core dump? If so
please provide a stack backtrace.
regards, tom lane
---
It's happened again, and in both cases seems to be on a call to
VACUUM FULL
Grant Finnemore wrote:
Hi,
I am using a version of PostgreSQL compiled from a CVS update of yesterday,
and compiled with
make clean all
make install
One client connection to the database doing routine and low volume
po
Hi,
I am using a version of PostgreSQL compiled from a CVS update of yesterday,
and compiled with
make clean all
make install
One client connection to the database doing routine and low volume population
scripts (using schemas) After several normal runs of the population script, a
run caused th
