On 15 April 2016 at 13:30, Andres Freund <and...@anarazel.de> wrote: > On 2016-04-15 13:26:35 +1200, David Rowley wrote: >> On 15 April 2016 at 13:02, Tom Lane <t...@sss.pgh.pa.us> wrote: >> > David Rowley <david.row...@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
disallow_index_on_syscols.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
