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
