On Mon, May 08, 2023 at 06:04:23PM -0400, Tom Lane wrote: > Andres seems to think it's a problem with aborting a DROP DATABASE. > Adding more data might serve to make the window wider, perhaps. And the odds get indeed much better once I use these two toys: CREATE OR REPLACE FUNCTION create_tables(num_tables int) RETURNS VOID AS $func$ BEGIN FOR i IN 1..num_tables LOOP EXECUTE format(' CREATE TABLE IF NOT EXISTS %I (id int)', 't_' || i); END LOOP; END $func$ LANGUAGE plpgsql; CREATE OR REPLACE FUNCTION drop_tables(num_tables int) RETURNS VOID AS $func$ BEGIN FOR i IN 1..num_tables LOOP EXECUTE format(' DROP TABLE IF EXISTS %I', 't_' || i); END LOOP; END $func$ LANGUAGE plpgsql; And then use this loop with the others I have mentioned upthread (just create origindb and the functions in them): while true; do psql -c 'select create_tables(1000)' origindb > /dev/null 2>&1 ; psql testdb -c "select 1" > /dev/null 2>&1 ; psql -c 'select drop_tables(1000)' origindb > /dev/null 2>&1 ; psql testdb -c "select 1" > /dev/null 2>&1 ; done; On top of that, I have also been able to reproduce the issue on HEAD, and luckily some pg_class file remain around, full of zeros: $ hexdump ./base/199634/1259 0000000 0000 0000 0000 0000 0000 0000 0000 0000 The contents of 2662, though, looked OK. Echoing Alvaro.. Could we, err, revisit the choice of making WAL_LOG the default strategy even for this set of minor releases? FWIW, I've mentioned that this choice was too aggressive in the thread of 8a86618.. -- Michael
Attachment:
signature.asc
Description: PGP signature