On 1 April 2016 at 17:30, Tom Lane <t...@sss.pgh.pa.us> wrote: > David Rowley <david.row...@2ndquadrant.com> writes: >> The attached fixes an error message which is incorrectly using an >> unsigned format specifier instead of a signed one. > > I think that's the tip of the iceberg :-(. For starters, the code > allows ObjectIdAttributeNumber without regard for the fact that the > next line will dump core on a negative attno. Really though, what > astonishes me about this example is that we allow indexes at all on > system columns other than OID. None of the other ones can possibly > have either a use-case or sensible semantics, can they? We certainly > would not stop to update indexes after changing xmax, for example.
ouch. Yeah that's not going to work very well. I guess nobody's tried that with a unique index on an OID column yet then. I've changed the patch around a little to fix the crash. I was a bit worried as logical decoding obviously has not yet been tested with an OID unique index as the replica indentity, so I gave it a quick test to try to give myself a little piece of mind that this won't uncover something else; # create table t (a int) with oids; CREATE TABLE # create unique index t_oid_idx on t(oid); CREATE INDEX # alter table t replica identity using index t_oid_idx; ALTER TABLE # insert into t values(123); INSERT 24593 1 # delete from t; On the receive side: BEGIN 606 table public.t: INSERT: oid[oid]:24593 a[integer]:123 COMMIT 606 BEGIN 607 table public.t: DELETE: oid[oid]:24593 COMMIT 607 -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Description: Binary data
-- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers