From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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-11 18:06:59 |
Message-ID: | 20200811180659.ddbrligtbvcsnewx@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Hi,
On 2020-08-11 13:52:00 -0400, Tom Lane wrote:
> For xmin in particular, you don't have to assume "everything's a heap".
> What you have to assume is "everything uses MVCC", which seems a more
> defensible position. It'll still fall down for foreign tables that are
> partitions, though.
Don't think that necessarily implies having a compatible xmin / xmax
around. Certainly not a 32bit one. I guess an AM could always return
InvalidOid, but that doesn't seem particularly helpful either.
I think it'd be better if we actually tried to provide a way to do
whatever xmin is being used properly. I've seen many uses of xmin/xmax
and many of them didn't work at all, and most of remaining ones only
worked in common cases.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Biryukov | 2020-08-11 18:31:52 | Re: posgres 12 bug (partitioned table) |
Previous Message | Andres Freund | 2020-08-11 18:06:29 | Re: posgres 12 bug (partitioned table) |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Biryukov | 2020-08-11 18:31:52 | Re: posgres 12 bug (partitioned table) |
Previous Message | Andres Freund | 2020-08-11 18:06:29 | Re: posgres 12 bug (partitioned table) |