pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Pavel Borisov <pashkin.elfe@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations
Date: Thu, 14 Oct 2021 17:13:35 -0400
Message-ID: <903680.1634246015@sss.pgh.pa.us> (raw)
In-Reply-To: <02C6345B-D186-4F88-A976-A2CD1051CB93@enterprisedb.com>
References: <17212-34dd4a1d6bba98bf@postgresql.org>
	<CA+TgmoYa5exExaONEnGBWRdi7A3=FKuKzewY8DXTj6+045wiFQ@mail.gmail.com>
	<CAH2-WzkwRUayddmb3uxCadV_y--DHfY+UMmjtOokiAO2xNh5fA@mail.gmail.com>
	<CA+Tgmoat1M4MAqUQM1H+bkWR=wXmi33bB0YRR=xaFk9ADs5Jeg@mail.gmail.com>
	<CAH2-Wzk3NzXYXsUKWBFuBm6aiXTh-_L2Dm9wPqfFenUvG+VbRw@mail.gmail.com>
	<543F3BF3-EDED-4C52-AF05-623921B6C409@enterprisedb.com>
	<CAH2-WzkXphRHgbaUXqMgb7SBmc_VbwdyWGYqphV6KbOH7stfxA@mail.gmail.com>
	<55A2BFE7-AAAF-4A64-BD3A-5C98EA982267@enterprisedb.com>
	<CAH2-WzniogVqNuWzNVLOKjkd8FBcSry29hN9=wiROUPw92fmGg@mail.gmail.com>
	<07159C9A-40DA-47BF-B2F4-! 203F5AC00890@enterprisedb.com>
	<CAH2-Wzkt-umhXfR1nqy=ZDXMfoN3LDK4W5VtchfWyRAuPWxtnA@mail.gmail.com>
	<40DB088B-C96F-49B2-BC84-BDC8D35C7E97@enterprisedb.com>
	<CAH2-Wzne7L9fX2LdZ9enNZpO2wuqbrsubCw2thH__CC_nZazjw@mail.gmail.com>
	<0B7DA7A4-2872-485B-BFDD-BF8E9BB07B26@enterprisedb.com>
	<726473.1634184950@sss.pgh.pa.us>
	<b5ec84db-c5af-bfac-fe4f-a704a364f90b@dunslane.net>
	<02C6345B-D186-4F! 88-A976-A2CD1051CB93@enterprisedb.com>

Mark Dilger <mark.dilger@enterprisedb.com> writes:
> The pg_amcheck patch Peter committed for me adds a new test, src/bin/pg_amcheck/t/006_bad_targets.pl, which creates two PostgresNode objects (a primary and a standby) and uses PostgresNode::background_psql().  It doesn't bother to "finish" the returned harness, which may be the cause of an installation hanging around long enough to be in the way when another test tries to start.

(a) Isn't that just holding open one connection, not the whole instance?

(b) Wouldn't finish()ing that connection cause the temp tables to be
dropped, negating the entire point of the test?

TBH, I seriously doubt this test case is worth expending buildfarm
cycles on forevermore.  I'm more than a bit tempted to just drop
it, rather than also expending developer time figuring out why it's
not as portable as it looks.

			regards, tom lane





view thread (83+ messages)  latest in thread

Message-ID: <903680.1634246015@sss.pgh.pa.us>
Permalink:  ../903680.1634246015@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/903680.1634246015@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, mark.dilger@enterprisedb.com, andrew@dunslane.net, pg@bowt.ie, robertmhaas@gmail.com, pashkin.elfe@gmail.com, exclusion@gmail.com, pgsql-hackers@postgresql.org
  Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations
  In-Reply-To: <903680.1634246015@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox