Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

[Amit Langote]

On 2017/03/08 1:34, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 1:43 AM, Amit Langote wrote:
>> On 2017/03/07 14:04, Tom Lane wrote:
>>> Therefore, there should definitely be a partitioned table, hopefully with
>>> a less generic name than "p1", in the final regression DB state.  Whether
>>> this particular one from alter_table.sql is a good candidate, I dunno.
>>> But let's not drop it without adding a better-thought-out replacement.
>>
>> OK, let's drop p1 in alter_table.sql.  I think a partitioned table created
>> in insert.sql is a good candidate to keep around after having it renamed,
>> which patch 0003 does.
> 
> Committed 0001.
> 
> Committed 0002 and 0003 together.

Thanks.

Regards,
Amit




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

[Robert Haas]

On Tue, Mar 7, 2017 at 1:43 AM, Amit Langote
 wrote:
> On 2017/03/07 14:04, Tom Lane wrote:
>> Amit Langote  writes:
>>> Also, I found out that alter_table.sql mistakenly forgot to drop
>>> partitioned table "p1".  Patch 0002 takes care of that.
>>
>> While that might or might not have been intentional, I think it's an
>> astoundingly bad idea to not leave any partitioned tables behind in
>> the final state of the regression database.  Doing so would likely
>> have meant that this particular bug evaded detection for much longer
>> than it did.  Moreover, it would mean that the pg_upgrade test would
>> have exactly no coverage of partitioned cases.
>
> That's true.  Should have been apparent to me.
>
>> Therefore, there should definitely be a partitioned table, hopefully with
>> a less generic name than "p1", in the final regression DB state.  Whether
>> this particular one from alter_table.sql is a good candidate, I dunno.
>> But let's not drop it without adding a better-thought-out replacement.
>
> OK, let's drop p1 in alter_table.sql.  I think a partitioned table created
> in insert.sql is a good candidate to keep around after having it renamed,
> which patch 0003 does.

Committed 0001.

Committed 0002 and 0003 together.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

[Amit Langote]

On 2017/03/07 14:04, Tom Lane wrote:
> Amit Langote  writes:
>> Also, I found out that alter_table.sql mistakenly forgot to drop
>> partitioned table "p1".  Patch 0002 takes care of that.
> 
> While that might or might not have been intentional, I think it's an
> astoundingly bad idea to not leave any partitioned tables behind in
> the final state of the regression database.  Doing so would likely
> have meant that this particular bug evaded detection for much longer
> than it did.  Moreover, it would mean that the pg_upgrade test would
> have exactly no coverage of partitioned cases.

That's true.  Should have been apparent to me.

> Therefore, there should definitely be a partitioned table, hopefully with
> a less generic name than "p1", in the final regression DB state.  Whether
> this particular one from alter_table.sql is a good candidate, I dunno.
> But let's not drop it without adding a better-thought-out replacement.

OK, let's drop p1 in alter_table.sql.  I think a partitioned table created
in insert.sql is a good candidate to keep around after having it renamed,
which patch 0003 does.

Thanks,
Amit
>From 0fe3bcea9424133b8711bdcc23b1432cde4fc394 Mon Sep 17 00:00:00 2001
From: amit 
Date: Tue, 7 Mar 2017 10:26:16 +0900
Subject: [PATCH 1/3] Fix relcache ref leak in acquire_inherited_sample_rows

Add tests for vacuum, analyze, truncate on partitioned table, as
3c3bb9933 should have.
---
 src/backend/commands/analyze.c |  7 +--
 src/test/regress/expected/truncate.out |  6 ++
 src/test/regress/expected/vacuum.out   |  9 +
 src/test/regress/sql/truncate.sql  |  7 +++
 src/test/regress/sql/vacuum.sql| 10 ++
 5 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index a70c760341..b91df986c5 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -1360,11 +1360,14 @@ acquire_inherited_sample_rows(Relation onerel, int elevel,
 		else
 		{
 			/*
-			 * ignore, but release the lock on it.  could be a partitioned
-			 * table.
+			 * ignore, but release the lock on it.  don't try to unlock the
+			 * passed-in relation
 			 */
+			Assert(childrel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE);
 			if (childrel != onerel)
 heap_close(childrel, AccessShareLock);
+			else
+heap_close(childrel, NoLock);
 			continue;
 		}
 
diff --git a/src/test/regress/expected/truncate.out b/src/test/regress/expected/truncate.out
index 5c5277e0f1..81612d8c88 100644
--- a/src/test/regress/expected/truncate.out
+++ b/src/test/regress/expected/truncate.out
@@ -420,3 +420,9 @@ SELECT nextval('truncate_a_id1'); -- fail, seq should have been dropped
 ERROR:  relation "truncate_a_id1" does not exist
 LINE 1: SELECT nextval('truncate_a_id1');
^
+-- partitioned table
+CREATE TABLE truncparted (a int, b char) PARTITION BY LIST (a);
+CREATE TABLE truncparted1 PARTITION OF truncparted FOR VALUES IN (1);
+INSERT INTO truncparted VALUES (1, 'a');
+TRUNCATE truncparted;
+DROP TABLE truncparted;
diff --git a/src/test/regress/expected/vacuum.out b/src/test/regress/expected/vacuum.out
index 9b604be4b6..6f68663087 100644
--- a/src/test/regress/expected/vacuum.out
+++ b/src/test/regress/expected/vacuum.out
@@ -82,3 +82,12 @@ VACUUM FULL vactst;
 VACUUM (DISABLE_PAGE_SKIPPING) vaccluster;
 DROP TABLE vaccluster;
 DROP TABLE vactst;
+-- partitioned table
+CREATE TABLE vacparted (a int, b char) PARTITION BY LIST (a);
+CREATE TABLE vacparted1 PARTITION OF vacparted FOR VALUES IN (1);
+INSERT INTO vacparted VALUES (1, 'a');
+UPDATE vacparted SET b = 'b';
+VACUUM (ANALYZE) vacparted;
+VACUUM (FULL) vacparted;
+VACUUM (FREEZE) vacparted;
+DROP TABLE vacparted;
diff --git a/src/test/regress/sql/truncate.sql b/src/test/regress/sql/truncate.sql
index a3d6f5368f..d61eea1a42 100644
--- a/src/test/regress/sql/truncate.sql
+++ b/src/test/regress/sql/truncate.sql
@@ -215,3 +215,10 @@ SELECT * FROM truncate_a;
 DROP TABLE truncate_a;
 
 SELECT nextval('truncate_a_id1'); -- fail, seq should have been dropped
+
+-- partitioned table
+CREATE TABLE truncparted (a int, b char) PARTITION BY LIST (a);
+CREATE TABLE truncparted1 PARTITION OF truncparted FOR VALUES IN (1);
+INSERT INTO truncparted VALUES (1, 'a');
+TRUNCATE truncparted;
+DROP TABLE truncparted;
diff --git a/src/test/regress/sql/vacuum.sql b/src/test/regress/sql/vacuum.sql
index 7b819f654d..7c5fb04917 100644
--- a/src/test/regress/sql/vacuum.sql
+++ b/src/test/regress/sql/vacuum.sql
@@ -64,3 +64,13 @@ VACUUM (DISABLE_PAGE_SKIPPING) vaccluster;
 
 DROP TABLE vaccluster;
 DROP TABLE vactst;
+
+-- partitioned table
+CREATE TABLE vacparted (a int, b char) PARTITION BY LIST (a);
+CREATE TABLE vacparted1 PARTITION OF vacparted FOR VALUES IN (1);
+INSERT INTO vacparted VALUES (1, 'a');
+UPDATE vacparted SET b = 'b';
+VACUUM (ANALYZE) vacparted;
+VACUUM (FULL) vacparted;
+VACUUM 

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

[Tom Lane]

Amit Langote  writes:
> Also, I found out that alter_table.sql mistakenly forgot to drop
> partitioned table "p1".  Patch 0002 takes care of that.

While that might or might not have been intentional, I think it's an
astoundingly bad idea to not leave any partitioned tables behind in
the final state of the regression database.  Doing so would likely
have meant that this particular bug evaded detection for much longer
than it did.  Moreover, it would mean that the pg_upgrade test would
have exactly no coverage of partitioned cases.

Therefore, there should definitely be a partitioned table, hopefully with
a less generic name than "p1", in the final regression DB state.  Whether
this particular one from alter_table.sql is a good candidate, I dunno.
But let's not drop it without adding a better-thought-out replacement.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

[Amit Langote]

On 2017/03/07 10:49, Michael Paquier wrote:
> On Tue, Mar 7, 2017 at 10:37 AM, Amit Langote
>  wrote:
>> On 2017/03/07 7:28, Tom Lane wrote:
>>> Kevin Grittner  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.
> 
> (I was just poking at that)
>  if (childrel != onerel)
>  heap_close(childrel, AccessShareLock);
> +else
> +heap_close(childrel, NoLock);
>  continue;
> Shouldn't that be conditional on the relkind of childrel?

I think we could simply Assert that childrel is partitioned table in this
whole block.  A child table could be a regular table, a materialized view
(?), a foreign table and a partitioned table, the first three of which are
handled by the first two blocks.

Updated patch attached.

Also, I found out that alter_table.sql mistakenly forgot to drop
partitioned table "p1".  Patch 0002 takes care of that.

Thanks,
Amit
>From 0fe3bcea9424133b8711bdcc23b1432cde4fc394 Mon Sep 17 00:00:00 2001
From: amit 
Date: Tue, 7 Mar 2017 10:26:16 +0900
Subject: [PATCH 1/2] Fix relcache ref leak in acquire_inherited_sample_rows

Add tests for vacuum, analyze, truncate on partitioned table, as
3c3bb9933 should have.
---
 src/backend/commands/analyze.c |  7 +--
 src/test/regress/expected/truncate.out |  6 ++
 src/test/regress/expected/vacuum.out   |  9 +
 src/test/regress/sql/truncate.sql  |  7 +++
 src/test/regress/sql/vacuum.sql| 10 ++
 5 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index a70c760341..b91df986c5 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -1360,11 +1360,14 @@ acquire_inherited_sample_rows(Relation onerel, int elevel,
 		else
 		{
 			/*
-			 * ignore, but release the lock on it.  could be a partitioned
-			 * table.
+			 * ignore, but release the lock on it.  don't try to unlock the
+			 * passed-in relation
 			 */
+			Assert(childrel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE);
 			if (childrel != onerel)
 heap_close(childrel, AccessShareLock);
+			else
+heap_close(childrel, NoLock);
 			continue;
 		}
 
diff --git a/src/test/regress/expected/truncate.out b/src/test/regress/expected/truncate.out
index 5c5277e0f1..81612d8c88 100644
--- a/src/test/regress/expected/truncate.out
+++ b/src/test/regress/expected/truncate.out
@@ -420,3 +420,9 @@ SELECT nextval('truncate_a_id1'); -- fail, seq should have been dropped
 ERROR:  relation "truncate_a_id1" does not exist
 LINE 1: SELECT nextval('truncate_a_id1');
^
+-- partitioned table
+CREATE TABLE truncparted (a int, b char) PARTITION BY LIST (a);
+CREATE TABLE truncparted1 PARTITION OF truncparted FOR VALUES IN (1);
+INSERT INTO truncparted VALUES (1, 'a');
+TRUNCATE truncparted;
+DROP TABLE truncparted;
diff --git a/src/test/regress/expected/vacuum.out b/src/test/regress/expected/vacuum.out
index 9b604be4b6..6f68663087 100644
--- a/src/test/regress/expected/vacuum.out
+++ b/src/test/regress/expected/vacuum.out
@@ -82,3 +82,12 @@ VACUUM FULL vactst;
 VACUUM (DISABLE_PAGE_SKIPPING) vaccluster;
 DROP TABLE vaccluster;
 DROP TABLE vactst;
+-- partitioned table
+CREATE TABLE vacparted (a int, b char) PARTITION BY LIST (a);
+CREATE TABLE vacparted1 PARTITION OF vacparted FOR VALUES IN (1);
+INSERT INTO vacparted VALUES (1, 'a');
+UPDATE vacparted SET b = 'b';
+VACUUM (ANALYZE) vacparted;
+VACUUM (FULL) vacparted;
+VACUUM (FREEZE) vacparted;
+DROP TABLE vacparted;
diff --git a/src/test/regress/sql/truncate.sql b/src/test/regress/sql/truncate.sql
index a3d6f5368f..d61eea1a42 100644
--- a/src/test/regress/sql/truncate.sql
+++ b/src/test/regress/sql/truncate.sql
@@ -215,3 +215,10 @@ SELECT * FROM truncate_a;
 DROP TABLE truncate_a;
 
 SELECT nextval('truncate_a_id1'); -- fail, seq should have been dropped
+
+-- partitioned table
+CREATE TABLE truncparted (a int, b char) 

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

[Michael Paquier]

On Tue, Mar 7, 2017 at 10:37 AM, Amit Langote
 wrote:
> On 2017/03/07 7:28, Tom Lane wrote:
>> Kevin Grittner  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.

(I was just poking at that)
 if (childrel != onerel)
 heap_close(childrel, AccessShareLock);
+else
+heap_close(childrel, NoLock);
 continue;
Shouldn't that be conditional on the relkind of childrel?
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

[Amit Langote]

On 2017/03/07 7:28, Tom Lane wrote:
> Kevin Grittner  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
>From b964b4dca34c637ec0acf64146f34caffcbb7aab Mon Sep 17 00:00:00 2001
From: amit 
Date: Tue, 7 Mar 2017 10:26:16 +0900
Subject: [PATCH] Fix relcache ref leak in acquire_inherited_sample_rows

Add tests for vacuum, analyze, truncate on partitioned table, as
3c3bb9933 should have.
---
 src/backend/commands/analyze.c |  4 +++-
 src/test/regress/expected/truncate.out |  6 ++
 src/test/regress/expected/vacuum.out   |  9 +
 src/test/regress/sql/truncate.sql  |  7 +++
 src/test/regress/sql/vacuum.sql| 10 ++
 5 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index a70c760341..354412b886 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -1361,10 +1361,12 @@ acquire_inherited_sample_rows(Relation onerel, int elevel,
 		{
 			/*
 			 * ignore, but release the lock on it.  could be a partitioned
-			 * table.
+			 * table.  don't try to unlock the passed-in relation.
 			 */
 			if (childrel != onerel)
 heap_close(childrel, AccessShareLock);
+			else
+heap_close(childrel, NoLock);
 			continue;
 		}
 
diff --git a/src/test/regress/expected/truncate.out b/src/test/regress/expected/truncate.out
index 5c5277e0f1..81612d8c88 100644
--- a/src/test/regress/expected/truncate.out
+++ b/src/test/regress/expected/truncate.out
@@ -420,3 +420,9 @@ SELECT nextval('truncate_a_id1'); -- fail, seq should have been dropped
 ERROR:  relation "truncate_a_id1" does not exist
 LINE 1: SELECT nextval('truncate_a_id1');
^
+-- partitioned table
+CREATE TABLE truncparted (a int, b char) PARTITION BY LIST (a);
+CREATE TABLE truncparted1 PARTITION OF truncparted FOR VALUES IN (1);
+INSERT INTO truncparted VALUES (1, 'a');
+TRUNCATE truncparted;
+DROP TABLE truncparted;
diff --git a/src/test/regress/expected/vacuum.out b/src/test/regress/expected/vacuum.out
index 9b604be4b6..6f68663087 100644
--- a/src/test/regress/expected/vacuum.out
+++ b/src/test/regress/expected/vacuum.out
@@ -82,3 +82,12 @@ VACUUM FULL vactst;
 VACUUM (DISABLE_PAGE_SKIPPING) vaccluster;
 DROP TABLE vaccluster;
 DROP TABLE vactst;
+-- partitioned table
+CREATE TABLE vacparted (a int, b char) PARTITION BY LIST (a);
+CREATE TABLE vacparted1 PARTITION OF vacparted FOR VALUES IN (1);
+INSERT INTO vacparted VALUES (1, 'a');
+UPDATE vacparted SET b = 'b';
+VACUUM (ANALYZE) vacparted;
+VACUUM (FULL) vacparted;
+VACUUM (FREEZE) vacparted;
+DROP TABLE vacparted;
diff --git a/src/test/regress/sql/truncate.sql b/src/test/regress/sql/truncate.sql
index a3d6f5368f..d61eea1a42 100644
--- a/src/test/regress/sql/truncate.sql
+++ b/src/test/regress/sql/truncate.sql
@@ -215,3 +215,10 @@ SELECT * FROM truncate_a;
 DROP TABLE truncate_a;
 
 SELECT nextval('truncate_a_id1'); -- fail, seq should have been dropped
+
+-- partitioned table
+CREATE TABLE truncparted (a int, b char) PARTITION BY LIST (a);
+CREATE TABLE truncparted1 PARTITION OF truncparted FOR VALUES IN (1);
+INSERT INTO truncparted VALUES (1, 'a');
+TRUNCATE truncparted;
+DROP TABLE truncparted;
diff --git a/src/test/regress/sql/vacuum.sql b/src/test/regress/sql/vacuum.sql
index 7b819f654d..7c5fb04917 100644
--- a/src/test/regress/sql/vacuum.sql
+++ b/src/test/regress/sql/vacuum.sql
@@ -64,3 +64,13 @@ VACUUM (DISABLE_PAGE_SKIPPING) vaccluster;
 
 DROP TABLE vaccluster;
 DROP TABLE vactst;
+
+-- partitioned table
+CREATE TABLE vacparted (a int, b char) PARTITION BY LIST (a);
+CREATE TABLE vacparted1 PARTITION OF vacparted FOR VALUES IN (1);
+INSERT INTO vacparted VALUES (1, 'a');
+UPDATE vacparted SET b = 'b';
+VACUUM (ANALYZE) vacparted;
+VACUUM (FULL) vacparted;
+VACUUM (FREEZE) vacparted;
+DROP TABLE vacparted;
-- 
2.11.0


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

[Tom Lane]

Kevin Grittner  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.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] WARNING: relcache reference leak: relation "p1" not closed

[Kevin Grittner]

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

--
Kevin Grittner


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

[Kevin Grittner]

[original message held up for review -- should be along eventualy...]

On Mon, Mar 6, 2017 at 3:11 PM, Kevin Grittner  wrote:
> 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

Still present in e6477a8134ace06ef3a45a7ce15813cd398e72d8

-- 
Kevin Grittner


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers