Re: logical replication out of memory

Hi Pang

The text column is exceptionally large, Your server must be out of memory,
Such a process ran out of memory while handling a large text column update.

I suggest using an S3 bucket for such files, Consider increasing the
memory-related configuration parameters, like work_mem, maintenance_work_mem or
even the server's overall memory allocation if possible.

Or increase the shared buffer size.

If everything doesn't work, use physical replication to cope with it. 😄

in last let me know the datatype your are using for this column.

On Wed, Jul 31, 2024 at 7:18 AM James Pang <jamespang886(at)gmail(dot)com> wrote:

> 2024-07-31 00:01:02.795 UTC:10.240.6.139(33068):repl13801(at)pgpodb:[3603770]:[10-1]:pgreps_13801ERROR:
> out of memory
> 2024-07-31 00:01:02.795 UTC:10.240.6.139(33068):repl13801(at)pgpodb:[3603770]:[11-1]:pgreps_13801DETAIL:
> Cannot enlarge string buffer containing 378355896 bytes by 756711422 more
> bytes.
> 2024-07-31 00:01:02.795 UTC:10.240.6.139(33068):repl13801(at)pgpodb:[3603770]:[12-1]:pgreps_13801CONTEXT:
> slot "pgreps_13801", output plugin "pgoutput", in the change callback,
> associated LSN 3D/318438E0
> 2024-07-31 00:01:02.795 UTC:10.240.6.139(33068):repl13801(at)pgpodb:[3603770]:[13-1]:pgreps_13801STATEMENT:
> START_REPLICATION SLOT "pgreps_13801" LOGICAL 3C/F24C74D0 (proto_version
> '1', publication_names 'pgreps_13801')
>
> We use built-in pgoutput and a client application did an HOT update to a
> column , that data type is "text" and real length is 756711422. But this
> table is NOT on publication list, possible to make logical decoding ignore
> "WAL records belong to tables that's not in publication list" ?
>
> Thanks,
>
> James
>