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
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 |
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 |