Invalid argument: Read time should NOT be specified for serializable isolation level

Hi. I’m having an issue with using serializable transactions. If I try to do a select and an update in the same transaction I get this exception:

XX000: Invalid argument: Read time should NOT be specified for serializable isolation level: { read: { physical: 1667745879514543 } local_limit: { physical: 1667745879523923 } global_limit: { physical: 1667745880014545 } in_txn_limit: { physical: 1667745879815385 } serial_no: 0 }

I found this issue on github with the number 14284
https://github.com/yugabyte/yugabyte-db/issues/14284

Do you know a workaround for this until it gets fixed? Thank you.

@hegdavid96 can you paste the complete queries that you’re doing?

@dorian_yugabyte sure. I made an example:

/* setup */
SET TRANSACTION ISOLATION level serializable;
CREATE TABLE table_aa (
    id uuid NOT NULL
);
ALTER TABLE ONLY table_aa
    ADD CONSTRAINT "PK_table_aa" PRIMARY KEY (id);
   
CREATE TABLE table_bb (
    id uuid NOT NULL,
    prop character(2) NOT NULL
);

ALTER TABLE ONLY table_bb
    ADD CONSTRAINT "PK_table_bb" PRIMARY KEY (id, prop);
ALTER TABLE ONLY table_bb
    ADD CONSTRAINT "FK_table_bb_table_aa_id" FOREIGN KEY (id) REFERENCES public.table_aa(id) ON DELETE CASCADE;

insert INTO public.table_aa (id) VALUES ('00000000-0000-0000-0000-000000000000');
insert INTO public.table_bb (id, prop) VALUES ('00000000-0000-0000-0000-000000000000', 'AA');
insert INTO public.table_bb (id, prop) VALUES ('00000000-0000-0000-0000-000000000000', 'BB');

/* transaction that throws error */
BEGIN TRANSACTION ISOLATION LEVEL serializable;
SELECT t.id
        FROM (
            SELECT a.id
            FROM table_aa AS a
            WHERE a.id = '00000000-0000-0000-0000-000000000000'
            LIMIT 1
        ) AS t
        LEFT JOIN table_bb AS a0 ON t.id = a0.id;
SAVEPOINT "__EFSavePoint";
UPDATE table_aa SET id = '00000000-0000-0000-0000-000000000000' where id = '00000000-0000-0000-0000-000000000000';
commit;

cc @FranckPachot for any alternatives

I’ve put this testcase in the git issue and pinged the engineers