Hi hackers,
Building on bf279ddd1c, this patch introduces a GUC
'standby_slot_names_from_syncrep' which allows logical failover slots
to wait for changes to have been synchronously replicated before sending
the decoded changes to logical subscribers.
The existing 'standby_slot_names' isn't great
Hi,
> I know about the problem and have seen the original email.
I'm sympathetic to the problem of potential privilege escalation when
executing functions. At the same time I'm not sure if there's that
much of a difference between 'CREATE EXTENSION' vs superusers copying
a series of 'CREATE FUNC
extension
> that does not have the search_path explicitly set in proconfig
If that's the "general" issue you're trying to solve, I would wonder
why we we wouldn't for instance be extending
the functionality to normal CREATE FUNCTION calls (ie, schema qualify
based off s
Hi Ashutosh,
Thanks for clarifying.
> not standalone functions created independently
I'm wondering why we wouldn't want to extend that functionality so
that if users (including superusers) do want to automatically
configure search_path
when they're creating functions it's available.
> The diff
Hi,
Thanks Bertrand for taking a look at the patch.
On Mon, Jun 17, 2024 at 8:19 AM Bertrand Drouvot
wrote:
>
> + int mode = SyncRepWaitMode;
>
> It's set to SyncRepWaitMode and then never change. Worth to get rid of "mode"?
>
I took a deeper look at this with GDB and I think it'
Hi Amit,
Thanks for taking a look.
On Tue, Jun 18, 2024 at 10:34 PM Amit Kapila wrote:
>
>
> The reading indicates when you set 'standby_slot_names_from_syncrep',
> the TPS reduces as compared to when it is not set. It would be better
> to see the data comparing 'standby_slot_names_from_syncrep
Hi,
I took a brief look at the patch.
For a motivation aspect I can see this being useful
synchronous_replicas if you have commit set to flush mode.
So +1 on feature, easier configurability, although thinking about it
more you could probably have the restore script be smarter and provide
non-zero
Hi Shveta,
On Sun, Jul 21, 2024 at 8:42 PM shveta malik wrote:
> > Ah that's a gap. Let me add some logging/warning in a similar fashion.
> > Although I think I'd have the warning be relatively generic (e.g.
> > changes are blocked because
> > they're not synchronously committed)
> >
>
> okay, s
Hi Shveta, Amit,
> > > > ... We should try to
> > > > find out if there is a performance benefit with the use of
> > > > synchronous_standby_names in the normal configurations like the one
> > > > you used in the above tests to prove the value of this patch.
I don't expect there to be a performan
Hi Bertrand,
On Sun, Jul 28, 2024 at 10:00 PM Bertrand Drouvot
wrote:
> Yeah, at the same place as the static lsn[] declaration, something like:
>
> static XLogRecPtr lsn[NUM_SYNC_REP_WAIT_MODE]; /* cached LSNs */
>
> but that may just be a matter of taste.
>
I've updated the patch to ref
Hi Amit,
On Mon, Aug 26, 2024 at 11:00 PM Amit Kapila wrote:
> I wanted a simple test where in the first case you use
> synchronous_standby_names = 'ANY 3 (A,B,C,D,E)' and in the second case
> use standby_slot_names = A_slot, B_slot, C_slot, D_slot, E_slot. You
> can try some variations of it as
Hi Shveta,
Thanks for reviewing it so quickly.
On Thu, Aug 29, 2024 at 2:35 AM shveta malik wrote:
>
> Thanks for the patch. Few comments and queries:
>
> 1)
> + static XLogRecPtr lsn[NUM_SYNC_REP_WAIT_MODE];
>
> We shall name it as 'lsns' as there are multiple.
>
This follows the same na
Hi,
On Thu, Aug 29, 2024 at 6:32 AM Bharath Rupireddy
wrote:
> In synchronous replication setup, until standby finishes fetching WAL
> from the archive, the commits on the primary have to wait which can
> increase the query latency. If the standby can connect to the primary
> as soon as the broke
Hi Shveta,
On Sun, Sep 8, 2024 at 11:16 PM shveta malik wrote:
>
> I was trying to have a look at the patch again, it doesn't apply on
> the head, needs rebase.
>
Rebased with the latest changes.
> Regarding 'mode = SyncRepWaitMode', FWIW, SyncRepWaitForLSN() also
> does in a similar way. It g
Hi Shveta,
Thanks for taking a look at the patch.
> > will leave user no option to unlink failover-enabled logical
> > subscribers from the wait on synchronous standbys.
That's a good point. I'm a bit biased in that I don't think there's a
great reason why someone would
want to replicate logical
Hi Bertrand,
> 1 ===
> ...
> That's worth additional comments in the code.
There's this comment already about caching the value already, not sure
if you prefer something more?
/* Cache values to reduce contention on lock */
> 2 ===
> ...
> Looks like setting initialized to true is missing once
Hi,
On Mon, Sep 16, 2024 at 2:25 AM shveta malik wrote:
> > >
> > > If we don't do something similar, then aren't there chances that we
> > > keep on waiting on the wrong lsn[mode] for the case when mode =
> > > SYNC_REP_WAIT_APPLY while sync-rep-wait infrastructure is updating
> > > different m
Hi,
On Fri, Sep 20, 2024 at 2:44 AM shveta malik wrote:
> > >
> >
> > The difference is that the purpose of 'synchronized_standby_slots' is
> > to mention slot names for which the user expects logical walsenders to
> > wait before sending the logical changes to subscribers. OTOH,
> > 'synchronous
Hi,
Chiming in as one of said providers...
> On Sat, 2025-04-05 at 19:07 -0400, Tom Lane wrote:
> > I took another look at this patch, and I still can't persuade
> > myself that a good case has been made for it. There are too
> > many scenarios where pg_manage_extensions would be a security
> > p
Hi,
Thanks for the quick review.
On Tue, Jul 1, 2025 at 8:16 PM wenhui qiu wrote:
> > Perhaps decide_wal_file_action() could be defined in filemap.c.
>
That's a good point. I updated the patch to reflect that.
> > While this is unrelated to WAL logging, it could also contribute to faster
> >
Hi,
Thanks for the review.
On Sun, Jul 6, 2025 at 7:12 PM wenhui qiu wrote:
>
> Hi
> > Thanks, LGTM.
> I think it's possible to register to https://commitfest.postgresql.org/54,
> https://commitfest.postgresql.org/53 will closed soon
>
I've created the commitfest entry here:
https://commitfest
Hi,
On Wed, Jul 2, 2025 at 6:40 PM Japin Li wrote:
>
> >
>
> Splitting the logs from $PGDATA is definitely better. The question is whether
> it's worth implementing this directly in core or if a prominent note in the
> documentation would suffice.
>
I can work on the documentation update as a se
Hi,
I've attached an updated version of the patch against master with the changes
suggested.
On Tue, Nov 29, 2022 at 10:03 PM Michael Paquier wrote:
>
> On Thu, Oct 06, 2022 at 04:08:45PM +0900, Michael Paquier wrote:
>>
>> There may be something I am missing here, but there is no need to care
23 matches
Mail list logo
