Re: Synchronizing slots from primary to standby
| От | shveta malik |
|---|---|
| Тема | Re: Synchronizing slots from primary to standby |
| Дата | |
| Msg-id | CAJpy0uDyVz-6uMDWONQLRaX9iWdWKBF2QS=UrFysKP3+e4oe_A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Synchronizing slots from primary to standby (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
| Ответы |
Re: Synchronizing slots from primary to standby
|
| Список | pgsql-hackers |
On Wed, Feb 28, 2024 at 1:33 PM Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote: > > Hi, > A few comments: Thanks for reviewing. > > 1 === > > + * used to run normal SQL queries > > s/run normal SQL/run SQL/ ? > > As mentioned up-thread I don't like that much the idea of creating such a test > but if we do then here are my comments: > > 2 === > > +CREATE FUNCTION myschema.myintne(bigint, int) > > Should we explain why 'bigint, int' is important here (instead of > 'int, int')? > > 3 === > > +# stage of syncing newly created slots. If the worker was not prepared > +# to handle such attacks, it would have failed during > > Worth to mention the underlying check / function that would get an "unexpected" > result? > > Except for the above (nit) comments the patch looks good to me. Here is the patch which addresses the above comments. Also optimized the test a little bit. Now we use pg_sync_replication_slots() function instead of worker to test the operator-redirection using search-patch. This has been done to simplify the test case and reduce the added time. thanks Shveta
Вложения
В списке pgsql-hackers по дате отправления: