Re: posgres 12 bug (partitioned table)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Biryukov <79166341370(at)yandex(dot)ru>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: posgres 12 bug (partitioned table)
Date: 2020-08-12 16:27:18
Message-ID: 20200812162718.ycxrktzoe6rpdy5k@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Hi,

On 2020-08-12 14:19:12 +0900, Amit Langote wrote:
> On Wed, Aug 12, 2020 at 1:08 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> > > On Wed, Aug 12, 2020 at 3:02 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > >> Medium term I think we should just plain out forbid references to system
> > >> columns in partioned tables Or at least insist that all partitions have
> > >> that column.
> >
> > > Performance-wise I would prefer the former, because the latter would
> > > involve checking *all* partitions statically in the INSERT case,
> > > something that we've avoided doing so far.
> >
> > It's not like we don't have a technology for doing that. The way this
> > ideally would work, IMV, is that the parent partitioned table either
> > has or doesn't have a given system column. If it does, then every
> > child must too, just like the way things work for user columns.
>
> Ah, I may have misread "insisting that all partitions have a given
> system column" as doing that on every query, but maybe Andres meant
> what you are describing here.

I think Tom's formulation makes sense.

> > This'd require (a) some sort of consensus about which kinds of system
> > columns can make sense --- as Andres noted, 32-bit xmin might not be
> > the best choice here --- and (b) some notation for users to declare
> > which of these columns they want in a partitioned table. Once upon
> > a time we had WITH OIDS, maybe that idea could be extended.
>
> For (a), isn't there already a consensus that all table AMs support at
> least the set of system columns described in 5.5 System Columns [1]
> even if the individual members of that set are no longer the best
> choice at this point?

I don't think there is. I don't think xmin/xmax/cmin/cmax should be
among those. tableoid and ctid are handled by generic code, so I think
they would be among the required columns.

Where do you see that concensus?

> I do agree that we'd need (b) in some form to require AMs to fill
> those columns which it seems is not the case currently.

Hm? What are you referencing here?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2020-08-12 20:41:57 BUG #16580: PostgreSQL PassTheHash Protocol Design Weakness Detected - vulnerability
Previous Message Tom Lane 2020-08-12 12:57:48 Re: BUG #16579: In some areas of UTC+8, "CST" in the log is recognized as the wrong time zone when importing these

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-08-12 16:56:03 Re: Parallel query hangs after a smart shutdown is issued
Previous Message Dmitry Dolgov 2020-08-12 16:19:02 pg_stat_statements and "IN" conditions