From: Pavel Biryukov <79166341370@yandex.ru>
To: Amit Langote <amitlangote09@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: posgres 12 bug (partitioned table)
Date: Tue, 27 Oct 2020 16:55:17 +0300
Message-ID: <407111603806900@mail.yandex.ru> (raw)
In-Reply-To: <CA+HiwqEGgy8x5M2dotzH7HSd0v+byyJXGU8S+d5NFnrOBiTZDA@mail.gmail.com>
References: <141051591267657@mail.yandex.ru>
<1251598.1591289850@sss.pgh.pa.us>
<20200811180231.fcssvhelqpnydnx7@alap3.anarazel.de>
<CA+HiwqH7bA+orwhcA5dofKR_UNzk-S8GPK23g1vCrWxAjnK=Og@mail.gmail.com>
<81885.1597205290@sss.pgh.pa.us>
<CA+HiwqFx8oBGTDmwVQNHQrSGw4we84E4z5J+q2zFRJeAt5BaCA@mail.gmail.com>
<20200812162718.ycxrktzoe6rpdy5k@alap3.anarazel.de>
<CA+HiwqEGgy8x5M2dotzH7HSd0v+byyJXGU8S+d5NFnrOBiTZDA@mail.gmail.com>
<div>Hi!</div><div> </div><div>What's the state with this issue?</div><div> </div><div>-- <br />С уважением, Павел</div><div> </div><div> </div><div> </div><div>13.08.2020, 07:13, "Amit Langote" <amitlangote09@gmail.com>:</div><blockquote><p>Hi,<br /><br />On Thu, Aug 13, 2020 at 1:27 AM Andres Freund <<a href="mailto:andres@anarazel.de" rel="noopener noreferrer">andres@anarazel.de</a>> wrote:</p><blockquote> On 2020-08-12 14:19:12 +0900, Amit Langote wrote:<br /> > On Wed, Aug 12, 2020 at 1:08 PM Tom Lane <<a href="mailto:tgl@sss.pgh.pa.us" rel="noopener noreferrer">tgl@sss.pgh.pa.us</a>> wrote:<br /> > > It's not like we don't have a technology for doing that. The way this<br /> > > ideally would work, IMV, is that the parent partitioned table either<br /> > > has or doesn't have a given system column. If it does, then every<br /> > > child must too, just like the way things work for user columns.<br /> ><br /> > Ah, I may have misread "insisting that all partitions have a given<br /> > system column" as doing that on every query, but maybe Andres meant<br /> > what you are describing here.<br /><br /> I think Tom's formulation makes sense.</blockquote><p><br />Yes, I agree.<br /> </p><blockquote> > > This'd require (a) some sort of consensus about which kinds of system<br /> > > columns can make sense --- as Andres noted, 32-bit xmin might not be<br /> > > the best choice here --- and (b) some notation for users to declare<br /> > > which of these columns they want in a partitioned table. Once upon<br /> > > a time we had WITH OIDS, maybe that idea could be extended.<br /> ><br /> > For (a), isn't there already a consensus that all table AMs support at<br /> > least the set of system columns described in 5.5 System Columns [1]<br /> > even if the individual members of that set are no longer the best<br /> > choice at this point?<br /><br /> I don't think there is. I don't think xmin/xmax/cmin/cmax should be<br /> among those. tableoid and ctid are handled by generic code, so I think<br /> they would be among the required columns.<br /><br /> Where do you see that concensus?</blockquote><p><br />Perhaps I was wrong to use the word consensus. I was trying to say<br />that table AM extensibility work didn't change the description in 5.5<br />System Columns, which still says *all* tables, irrespective of their<br />AM, implicitly have those columns, so I assumed we continue to ask AM<br />authors to have space for those columns in their tuples. Maybe, that<br />list is a legacy of heapam and updating it in am AM-agnostic manner<br />would require consensus.<br /> </p><blockquote> > I do agree that we'd need (b) in some form to require AMs to fill<br /> > those columns which it seems is not the case currently.<br /><br /> Hm? What are you referencing here?</blockquote><p><br />I meant that WITH <a-system-column> specified on a table presumably<br />forces an AM to ensure that the column is present in its tuples, like<br />WITH OIDS specification on a table would force heapam to initialize<br />the oid system column in all tuples being inserted into that table.<br />Lack of the same notation for other system columns means that AMs<br />don't feel forced to ensure those columns are present in their tuples.<br />Also, having the WITH notation makes it easy to enforce that all<br />partitions in a given hierarchy have AMs that respect the WITH<br />specification.<br /> </p>--<br />Amit Langote<br />EnterpriseDB: <a href="http://www.enterprisedb.com/"; rel="noopener noreferrer">http://www.enterprisedb.com</a></blockquote;
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: 79166341370@yandex.ru, amitlangote09@gmail.com, andres@anarazel.de, tgl@sss.pgh.pa.us, pgsql-bugs@lists.postgresql.org
Subject: Re: posgres 12 bug (partitioned table)
In-Reply-To: <407111603806900@mail.yandex.ru>
* 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