On 2014-08-29 13:29:19 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-08-29 13:15:16 -0400, Tom Lane wrote:
> >> 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.
>
> > Not pretty, but we could set t_ctid to some 'magic' value when switching
> > partitions. Everything chasing ctid chains could then error out when
> > hitting a invisible row with such a t_ctid.
>
> An actual fix would presumably involve adding a partition number to the
> ctid chain field in tuples in partitioned tables. The reason I bring it
> up now is that we'd have to commit to doing that (or at least leaving room
> for it) in the first implementation, if we don't want to have an on-disk
> compatibility break.
Right. Just adding it unconditionally doesn't sound feasible to me. Our
per-row overhead is already too large. And it doesn't sound fun to have
the first-class partitions use a different heap tuple format than plain
relations.
What we could do is to add some sort of 'jump' tuple when moving a tuple
from one relation to another. So, when updating a tuple between
partitions we add another in the old partition with xmin_jump =
xmax_jump = xmax_old and have the jump tuple's content point to the new
relation.
Far from pretty, but it'd only matter overhead wise when used.
> > The usecases for doing such
> > updates really are more maintenance style commands, so it's possibly not
> > too bad from a usability POV :(
>
> I'm afraid that might just be wishful thinking.
I admit that you might very well be right there :(
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
