Re: WARNING: relcache reference leak: relation "p1" not closed

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kgrittn(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: WARNING: relcache reference leak: relation "p1" not closed
Date: 2017-03-07 01:37:46
Message-ID: 5e9dda6d-5d63-2e76-1bbb-c7ba75e4f6ad@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017/03/07 7:28, Tom Lane wrote:
> Kevin Grittner <kgrittn(at)gmail(dot)com> writes:
>> With e434ad39ae7316bcf35fd578dd34ad7e1ff3c25f I did a `make world`,
>> `make install-world`, a fresh default initdb, a start with default
>> config, `make installcheck`, connected to the regression database
>> with psql as the initial superuser, and ran:
>
>> regression=# vacuum freeze analyze;
>> WARNING: relcache reference leak: relation "p1" not closed
>> VACUUM
>
> p1 is a partitioned table. (BTW, could I lobby for people not to use such
> generic, collision-prone names for tables that will be left behind after
> the regression tests?) Also, I find that "vacuum analyze" is sufficient,
> or even just "analyze", or "analyze p1". I think it's highly likely this
> was introduced by 3c3bb99330aa9b4c2f6258bfa0265d806bf365c3. Certainly
> that failed to add appropriate regression test cases, or we would have
> noticed this already.

That's right, sorry about that. Attached patch fixes the relcache leak
and adds tests in vacuum.sql and truncate.sql.

Thanks,
Amit

Attachment Content-Type Size
0001-Fix-relcache-ref-leak-in-acquire_inherited_sample_ro.patch text/x-diff 3.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-03-07 01:49:48 Re: WARNING: relcache reference leak: relation "p1" not closed
Previous Message David Rowley 2017-03-07 01:09:06 Small fix to postgresql.conf.sample's comment on max_parallel_workers