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,
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 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,
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,
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 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 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 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 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,
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 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 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 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,
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 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
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,
> 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
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
18 matches
Mail list logo
