Andres Freund <and...@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.
There is certainly room to argue that the value of this capability isn't
worth the disk space this solution would eat. But we should have that
argument while the option is still feasible ...
> 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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
