Simple way to simulate a bug in logical replication

From: Avi Weinberg <AviW(at)gilat(dot)com>
To: pgsql-generallists(dot)postgresql(dot)org <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Simple way to simulate a bug in logical replication
Date: 2024-03-12 15:16:00
Message-ID: DB9PR07MB71802D2D027CB45157274A1FCB2B2@DB9PR07MB7180.eurprd07.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi All,

I think I hit a bug in logical replication in version 15.2. I sync two tables of size 305MB but pg_stat_progress_copy shows that 5GB as bytes_processed and the sync takes forever.
Is this a bug? If so, what can I do with this scenario?

Thanks

Create a dummy table

CREATE TABLE example_table (
id SERIAL PRIMARY KEY,
binary_data BYTEA
);

Create a function that inserts a row of few MB into the table
CREATE OR REPLACE FUNCTION generate_large_data()
RETURNS BYTEA AS $$
DECLARE
large_data BYTEA;
BEGIN
large_data := decode(repeat('DEADBEEF', 102400000), 'hex');
RETURN large_data;
END;
$$ LANGUAGE plpgsql;

I Inserted this sample row 112 times
INSERT INTO example_table (binary_data) VALUES (generate_large_data());

Checked that table size
SELECT pg_size_pretty(pg_total_relation_size('example_table'));
The table size was 305MB

I added this table to logical replication (and another table called example_table1 that had similar structure and data.
I run the following command
select * from pg_stat_progress_copy

I got that bytes_processed for each of the tables is over 5GB

"pid","datid","datname","relid","command","type","bytes_processed","bytes_total","tuples_processed","tuples_excluded","pg_size_pretty"
599,16384,"aaa_db",19833,"COPY FROM","CALLBACK","5898403943","0","13","0","5625 MB"
597,16384,"aa_db",19824,"COPY FROM","CALLBACK","5898403938","0","13","0","5625 MB"

IMPORTANT - This email and any attachments is intended for the above named addressee(s), and may contain information which is confidential or privileged. If you are not the intended recipient, please inform the sender immediately and delete this email: you should not copy or use this e-mail for any purpose nor disclose its contents to any person.

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Johnson 2024-03-12 15:30:45 Re: Simple way to simulate a bug in logical replication
Previous Message Adrian Klaver 2024-03-12 14:58:29 Re: could not open file "global/pg_filenode.map": Operation not permitted