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

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: David Steele <david@pgmasters.net>
Cc: Pavel Biryukov <79166341370@yandex.ru>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: posgres 12 bug (partitioned table)
Date: Thu, 22 Apr 2021 15:09:59 -0400
Message-ID: <1194023.1619118599@sss.pgh.pa.us> (raw)
In-Reply-To: <20210422185724.z54trqb4j6oavwjv@alap3.anarazel.de>
References: <407111603806900@mail.yandex.ru>
	<CA+HiwqFjEim_RMCiaFxA4nUx00o3auXKPy-OsOcog+chg5K-zA@mail.gmail.com>
	<cd492dbd-a0ba-4790-bcf7-c4af2d2dc8d1@pgmasters.net>
	<CA+HiwqG7qhKJnFpZOqyrFngqcMzja+p=gssMK=73b+-BZffxqw@mail.gmail.com>
	<CA+HiwqHqnC=A9a+=F-k8J=JV-EKKt3vTgxq01=9af-0HE045NQ@mail.gmail.com>
	<793243.1619032209@sss.pgh.pa.us>
	<CA+HiwqGASb2n+fOKVgDUddzV-_vc6ZxRj9i5oWMWOw1VK0_c7g@mail.gmail.com>
	<1102101.1619115665@sss.pgh.pa.us>
	<20210422183148.xsopy2qsym7a7app@alap3.anarazel.de>
	<1130714.1619116646@sss.pgh.pa.us>
	<20210422185724.z54trqb4j6oavwjv@alap3.anarazel.de>

Andres Freund <andres@anarazel.de> writes:
> On 2021-04-22 14:37:26 -0400, Tom Lane wrote:
>> OK, I could work with that.  Shall we spell the error message the
>> same as if it really were a virtual slot, or does it need to be
>> different to avoid confusion?

> Hm. Seems like it'd be better to have a distinct error message? Feels
> like it'll often indicate separate issues whether a non-materialized
> heap slot or a virtual slot has its system columns accessed.

After thinking about it for a bit, I'm inclined to promote this to
a user-facing error, and have all the slot types report

	ereport(ERROR,
	        (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
	         errmsg("cannot retrieve a system column in this context")));

which is at least somewhat intelligible to end users.  A developer
trying to figure out why it happened would resort to \errverbose or
more likely gdb in any case, so the lack of specificity doesn't
seem like a problem.

> Not entirely clear to me how we'd track whether we have valid system
> column data or not once materialized - which I think is why we
> historically had the cases where we returned bogus values.

Right, but with this fix we won't need to materialize.

			regards, tom lane





view thread (46+ messages)  latest in thread

Message-ID: <1194023.1619118599@sss.pgh.pa.us>
Permalink:  ../1194023.1619118599@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/1194023.1619118599@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, andres@anarazel.de, amitlangote09@gmail.com, david@pgmasters.net, 79166341370@yandex.ru, pgsql-bugs@lists.postgresql.org
  Subject: Re: posgres 12 bug (partitioned table)
  In-Reply-To: <1194023.1619118599@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