Re: Logical Replica ReorderBuffer Size Accounting Issues - Mailing list pgsql-bugs

From Alex Richman
Subject Re: Logical Replica ReorderBuffer Size Accounting Issues
Date
Msg-id CAMnUB3qVvWazGHxtC1emxEaTnU28N+CznabVRMbqfNQq9kf9fw@mail.gmail.com
Whole thread Raw
In response to Re: Logical Replica ReorderBuffer Size Accounting Issues  (Amit Kapila <amit.kapila16@gmail.com>)
Responses RE: Logical Replica ReorderBuffer Size Accounting Issues  ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>)
List pgsql-bugs

Do you have any sample data to confirm
this? If you can't share sample data, can you let us know the average
tuple size?

I suspect the writes are updates to jsonb columns.  I can correlate bursts of writes of this form to the memory spikes:
UPDATE suspect_table
  SET jsonb_column = jsonb_column || $1,
         updated_at = $2
  WHERE ...

The update being added in $1 is typically a single new field.  The jsonb column is flat string key/value pairs, e.g. lots of {"key": "value", ...}.

The average size of the whole tuple in the suspect table is ~800 bytes (based on 10000 random samples), of which the jsonb column is 80%.

I have been trying to break into a walsender to inspect some tuple bufs directly and compare the ChangeSize vs GetTupleBuf size as you suggest, but it's proving a little tricky - I'll let you know if I have any luck here.

Thanks,
- Alex.
 

pgsql-bugs by date:

Previous
From: Alex Richman
Date:
Subject: Re: Segfault while creating logical replication slots on active DB 14.6-1 + 15.1-1
Next
From: PG Bug reporting form
Date:
Subject: BUG #17738: There is a typo on your website