Drop database command will raise "wrong tuple length" if pg_database tuple contains toast attribute. - Mailing list pgsql-hackers

From Ayush Tiwari
Subject Drop database command will raise "wrong tuple length" if pg_database tuple contains toast attribute.
Date
Msg-id CAJTYsWWNkCt+-UnMhg=BiCD3Mh8c2JdHLofPxsW3m2dkDFw8RA@mail.gmail.com
Whole thread Raw
Responses Re: Drop database command will raise "wrong tuple length" if pg_database tuple contains toast attribute.
List pgsql-hackers
Hi hackers,

We encountered an issue lately, that if the database grants too many roles `datacl` is toasted, following which, the drop database command will fail with error "wrong tuple length".

To reproduce the issue, please follow below steps:

CREATE DATABASE test;

-- create helper function
CREATE OR REPLACE FUNCTION data_tuple() returns text as $body$
declare
          mycounter int;
begin
          for mycounter in select i from generate_series(1,2000) i loop
                    execute 'CREATE ROLE aaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbb ' || mycounter;
                    execute 'GRANT ALL ON DATABASE test to aaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbb ' || mycounter;
          end loop;
          return 'ok';
end;
$body$ language plpgsql volatile strict; 

-- create roles and grant on the database.
SELECT data_tuple(); 

-- drop database command, this will result in "wrong tuple length" error.
DROP DATABASE test;

The root cause of this behaviour is that the HeapTuple in dropdb function fetches a copy of pg_database tuple from system cache.
But the system cache flattens any toast attributes, which cause the length check to fail in heap_inplace_update.

A patch for this issue is attached to the mail, the solution is to change the logic to fetch the tuple by directly scanning pg_database rather than using the catcache.

Regards,
Ayush




Attachment

pgsql-hackers by date:

Previous
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Conflict detection and logging in logical replication
Next
From: Bertrand Drouvot
Date:
Subject: Re: Restart pg_usleep when interrupted