Re: posgres 12 bug (partitioned table)
От | Robert Haas |
---|---|
Тема | Re: posgres 12 bug (partitioned table) |
Дата | |
Msg-id | CA+TgmoaN0kQa3nxToHtD8nRymSnUYaj4XL3zKq8Q_0AUJcQNPQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: posgres 12 bug (partitioned table) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: posgres 12 bug (partitioned table)
|
Список | pgsql-bugs |
On Thu, Jun 4, 2020 at 12:57 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Pavel Biryukov <79166341370@yandex.ru> writes: > > Hello. I'm catch error "virtual tuple table slot does not have system > > attributes" when inserting row into partitioned table with RETURNING > > xmin > > Reproduced here. The example works in v11, and in v10 if you remove > the unnecessary-to-the-example primary key, so it seems like a clear > regression. I didn't dig for the cause but I suppose it's related > to Andres' slot-related changes. I wonder whether it's really correct to classify this as a bug. The subsequent discussion essentially boils down to this: the partitioned table's children could use any AM, and they might not all use the same AM. The system columns that are relevant for the heap may therefore be relevant to all, some, or none of the children. In fact, any fixed kind of tuple table slot we might choose to use for the parent has this problem. If all of the children are of the same type -- and today that would have to be heap -- then using that type of tuple table slot for the parent as well would make sense. But there's no real reason why that's the correct answer in general. If the children are all of some other type, using a heap slot for the parent is wrong; and if they're all of different types, it's unclear that anything other than a virtual slot makes any sense. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-bugs по дате отправления: