On Sat, Jun 21, 2025 at 12:57 AM Anne Struble <adstru...@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 and 16.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 create with every query. > Unfortunately, this approach appears to be incompatible with the above fix > because of the change made to the DDL by creating temporary tables. If > queries are issued quickly enough while having a logical replication stream > 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 (outside of 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 messages from 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.
