Horton

Re: Huge memory consumption on partitioned table with FKs

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>
Cc: Amit Langote <amitlangote09@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, keisuke kuroda <keisuke.kuroda.3862@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, tatsuhito.kasahara.rd@hco.ntt.co.jp
Date: 2021-03-11T17:01:56Z
Lists: pgsql-hackers 
Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> writes:
> Thanks for fixing the problem! :-D

Hmm, I'm not sure we're done with this patch:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=husky&dt=2021-03-10%2021%3A09%3A32

The critical log extract is

2021-03-11 05:10:13.012 CET [21574:1082] pg_regress/foreign_key LOG:  statement: insert into fk_notpartitioned_pk (a, b)
	  select 2048, x from generate_series(1,10) x;
2021-03-11 05:10:13.104 CET [11830:368] LOG:  server process (PID 21574) was terminated by signal 11: Segmentation fault
2021-03-11 05:10:13.104 CET [11830:369] DETAIL:  Failed process was running: insert into fk_notpartitioned_pk (a, b)
	  select 2048, x from generate_series(1,10) x;

Now, maybe it's a coincidence that husky failed on a
partitioned-foreign-key test right after this patch went in, but I bet
not.  Since husky runs CLOBBER_CACHE_ALWAYS, it looks to me like we've
overlooked some cache-reset scenario or other.

			regards, tom lane

Commits

  1. Avoid creating duplicate cached plans for inherited FK constraints.