Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Tom Lane wrote:
> >> One other interesting thought that occurs to me: are we going to support
> >> UPDATEs that cause a row to belong to a different partition? If so, how
> >> are we going to handle the update chain links?
>
> > Bah, I didn't mention it? My current thinking is that it would be
> > disallowed; if you have chosen your partitioning key well enough it
> > shouldn't be necessary. As a workaround you can always DELETE/INSERT.
> > Maybe we can allow it later, but for a first cut this seems more than
> > good enough.
>
> Hm. I certainly agree that it's a case that could be disallowed for a
> first cut, but it'd be nice to have some clue about how we might allow it
> eventually.
I hesitate to suggest this, but we have free flag bits in
MultiXactStatus. We could use a specially marked multixact member to
indicate the OID of the target relation; perhaps set an infomask bit to
indicate that this has happened. Of course, no HOT updates are possible
so I think it's okay from a heap_prune_chain perspective. This abuses
the knowledge that OIDs and XIDs are both 32 bits long.
Since nowhere else we have the space necessary to store the longer data
that a cross-partition update would require, I don't see anything else
ATM. (For a moment I thought about abusing combo CIDs, but that doesn't
work because this requires to be persistent and visible from other
backends, neither of which is a quality of combocids.)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
