Re: Memory allocation error DDL invalidation (seen with 15.13 & 16.9) - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Memory allocation error DDL invalidation (seen with 15.13 & 16.9)
Date
Msg-id CAA4eK1LMrdaLYjFuDa9TKk1SP49La7nZKu9fOy3qO3PbK1Y4vg@mail.gmail.com
Whole thread Raw
List pgsql-hackers
On Sat, Jun 21, 2025 at 12:57 AM Anne Struble <adstruble@dayzero.io> wrote:
>
> Hello,
> I'm writing in regards to a fix made in the last release of Postgresql (specifically, I've looked at versions 15.13
and16.9). The fix in question is: 
> Fix data loss in logical replication
> This is the change set:
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=9f21be08e
> I did find this related thread in pgsql-bugs:
https://www.postgresql.org/message-id/CAA4eK1L7CA-A%3DVMn8fiugZ%2BCRt%2Bwz473Adrx3nxq8Ougu%3DO2kQ%40mail.gmail.com.
>
> In our implementation of row level security (which is relatively complex) we rely heavily on temporary tables that we
createwith every query. Unfortunately, this approach appears to be incompatible with the above fix because of the
changemade to the DDL by creating temporary tables. If queries are issued quickly enough while having a logical
replicationstream open, executing: 
> SELECT * FROM pg_logical_slot_get_changes('slot_name', null,null)
> will result in a memory allocation error (maybe related to above bug?):
> ERROR:  invalid memory alloc request size 1086094000
>

We have pushed a fix for this. See
d87d07b7ad3b782cb74566cd771ecdb2823adf6a. If possible, can you once
test the fix?

> Time: 17449.051 ms (00:17.449)
> Additionally, note that executing pg_logical_slot_get_changes is quite slow (17s above). Steps for reproducing
(outsideof our environment) and system information are at bottom. 
>
> Would it be possible for postgres to exclude temporary table creation from DDL changes that send "invalidation
messagesfrom catalog-modifying transactions to all concurrent in-progress transactions."? 
>

Oh, this is an interesting idea to investigate. However, even if
something on these lines is feasible, we may want to just have it for
HEAD, but the first thing is to try to come up with a patch. If you or
someone else can come up with a patch, I'll try to help with the
review.

>
Or will we need to reimplement our approach to RLS?
>

I think you can wait for a few weeks to see if someone can come up
with a patch to improve this area.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Minor patch; missing comment update in worker.c
Next
From: Amit Kapila
Date:
Subject: Re: Conflict detection for update_deleted in logical replication