Hi, I've spent a bit more time looking at the GiST part as part of my "parallel GiST build" patch nearby, and I think there's some sort of memory leak.
Consider this: create table t (a text); insert into t select md5(i::text) from generate_series(1,25000000) s(i); create index on t using gist (a gist_trgm_ops); select gist_index_check('t_a_idx', true); This creates a ~4GB GiST trigram index, and then checks it. But that gets killed, because of OOM killer. On my test machine it consumes ~6.5GB of memory before OOM intervenes. The memory context stats look like this: TopPortalContext: 8192 total in 1 blocks; 7680 free (0 chunks); 512 used PortalContext: 1024 total in 1 blocks; 616 free (0 chunks); 408 used: <unnamed> ExecutorState: 8192 total in 1 blocks; 4024 free (4 chunks); 4168 used printtup: 8192 total in 1 blocks; 7952 free (0 chunks); 240 used ExprContext: 8192 total in 1 blocks; 7224 free (10 chunks); 968 used amcheck context: 3128950872 total in 376 blocks; 219392 free (1044 chunks); 3128731480 used ExecutorState: 8192 total in 1 blocks; 7200 free (0 chunks); 992 used ExprContext: 8192 total in 1 blocks; 7952 free (0 chunks); 240 used GiST scan context: 22248 total in 2 blocks; 7808 free (8 chunks); 14440 used This is from before the OOM kill, but it shows there's ~3GB of memory is the amcheck context. Seems like a memory leak to me - I didn't look at which place leaks. regards -- Tomas Vondra