Обсуждение: TRAP: BadArgument - mcxt.c, Line: 813

With the latest server

testdb=# select version();
                                                       version
----------------------------------------------------------------------------------------------------------------------
 PostgreSQL 9.5devel_HEAD_20150329_0154_2c33e0fbceb0 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.9.2, 64-bit
(1 row)

I get a crash while restoring a trgm GIN index.


The attached bash creates 2 test tables (t5, t6).

A dumpfile, created thus:
  pg_dump -F c -v  -h /tmp -p 6545 -t t6 -f ~/pg_stuff/dumps/testdb_t6.dump testdb

cannot be restored in an empty database: it crashed the server (see below).

A restore of the smaller table t5 does not crash the system; the indexing is then OK.

Restore:
  pg_restore -v -O -x -d testdb ~/pg_stuff/dumps/testdb_t6.dump

I get this crash from restoring :

2015-03-29 17:32:55.846 CEST 8016 LOG:  database system is ready to accept connections
TRAP: BadArgument("!(((CurrentMemoryContext) != ((void *)0) && (((((const Node*)((CurrentMemoryContext)))->type) ==
T_AllocSetContext))))", File: "mcxt.c", Line: 813)
2015-03-29 17:35:02.459 CEST 8016 LOG:  server process (PID 8062) was terminated by signal 6: Aborted
2015-03-29 17:35:02.459 CEST 8016 DETAIL:  Failed process was running: CREATE INDEX t6_trgm_re_idx ON t6 USING gin (txt
gin_trgm_ops);



2015-03-29 17:35:02.459 CEST 8016 LOG:  terminating any other active server processes
2015-03-29 17:35:02.502 CEST 8016 LOG:  all server processes terminated; reinitializing
2015-03-29 17:35:02.710 CEST 8114 LOG:  database system was interrupted; last known up at 2015-03-29 17:32:55 CEST
2015-03-29 17:35:02.735 CEST 8114 LOG:  database system was not properly shut down; automatic recovery in progress
2015-03-29 17:35:02.828 CEST 8114 LOG:  redo starts at 0/270E550
2015-03-29 17:35:05.665 CEST 8114 LOG:  invalid magic number 0000 in log segment 000000010000000000000010, offset
7716864
2015-03-29 17:35:05.665 CEST 8114 LOG:  redo done at 0/1075AD90
2015-03-29 17:35:05.665 CEST 8114 LOG:  last completed transaction was at log time 2015-03-29 17:34:11.149606+02
2015-03-29 17:35:10.296 CEST 8016 LOG:  database system is ready to accept connections


So it would seem the CREATE INDEX is the actual problem (I haven't tried that command separately).


Erik Rijkers

On Sun, March 29, 2015 17:40, Erik Rijkers wrote:
> With the latest server
>
> testdb=# select version();
>                                                        version
>
----------------------------------------------------------------------------------------------------------------------
>  PostgreSQL 9.5devel_HEAD_20150329_0154_2c33e0fbceb0 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.9.2,
64-bit
> (1 row)
>
> I get a crash while restoring a trgm GIN index.
>

I forget to say this crash only happens with an assert-enabled server.

./configure --prefix=/home/aardvark/pg_stuff/pg_installations/pgsql.HEAD
\--bindir=/home/aardvark/pg_stuff/pg_installations/pgsql.HEAD/bin
\--libdir=/home/aardvark/pg_stuff/pg_installations/pgsql.HEAD/lib\--with-pgport=6545 --quiet --enable-depend
--enable-cassert\--enable-debug --with-extra-version=_HEAD_20150329_1726_2c33e0fbceb0 \--with-openssl --with-perl
--with-libxml--with-libxslt --with-zlib
 


thanks,

Erik Rijkers

"Erik Rijkers" <er@xs4all.nl> writes:
> I get a crash while restoring a trgm GIN index.

Hm, interesting: this seems to be the first negative fallout from
commit eaa5808e8ec4e82ce1a87103a6b6f687666e4e4c, which made
MemoryContextReset() delete not reset child contexts.  ginbuild()
is creating a funcCtx as a child of its tmpCtx but then supposing
that it can reset the tmpCtx without damaging the other one.

Easy enough to fix, but it's a bit worrisome that we did not find
this in regression testing.  Apparently the regression tests do
not exercise the "early dump" code path in ginBuildCallback...
        regards, tom lane