On 15 April 2016 at 13:30, Andres Freund <andres@anarazel.de> wrote:
> On 2016-04-15 13:26:35 +1200, David Rowley wrote:
>> On 15 April 2016 at 13:02, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> > David Rowley <david.rowley@2ndquadrant.com> writes:
>> >> I proposed a fix over there, but it didn't go anywhere, probably
>> >> because Tom and Andres discussed just disallowing unique indexes on
>> >> system columns altogether. So, the attached patch does just that, and
>> >> also fixes up the replica identity bugs too, as it's still possible
>> >> that someone could create a unique index on a system column with an
>> >> old version, upgrade, then try to set the replica identity to that
>> >> index. We'd need to handle that correctly, so I fixed that too.
>> >
>> > AFAIR, what we were discussing was disallowing any index on a system
>> > column (other than OID). I do not see why only unique indexes are
>> > problematic for them; the semantic issues are independent of that.
>>
>> I have to admit that my thoughts only considered ctid, which I
>> imagined would have been OK to have an index on. As for the other
>> system columns (apart from OID), I agree.
>
> What'd be the point of indexing ctid, and why would it be correct?
> Wouldn't, hm, HOT break it?
I don't personally see the point. I was just concerned that if there's
a slight chance that it's useful, then someone might have one
somewhere in the wild, and they might have problems restoring pg_dump
backups, once we disallow it.
The attached patch just disallows any index containing a system
column, apart from OID.
Is it worth making some changes to pg_dump to skip such indexes?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
