Hi,
On Wed, Feb 07, 2024 at 12:22:07AM +0530, Bharath Rupireddy wrote:
> On Mon, Feb 5, 2024 at 3:15 PM Bertrand Drouvot
> wrote:
> >
> > I'm not sure I like the fact that "invalidations" and "conflicts" are merged
> > into a single field. I'd vote to
Hi,
On Tue, Feb 06, 2024 at 03:19:11AM +, Zhijie Hou (Fujitsu) wrote:
> On Friday, February 2, 2024 2:03 PM Bertrand Drouvot
> wrote:
> >
> > Hi,
> >
> > On Thu, Feb 01, 2024 at 05:29:15PM +0530, shveta malik wrote:
> > > Attached v75 patch-set.
ed
into a single field. I'd vote to keep conflict_reason as it is and add a new
invalidation_reason (and put "conflict" as value when it is the case). The
reason
is that I think they are 2 different concepts (could be linked though) and that
it would be easier to check for conflicts (means conflict_reason is not NULL).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
re independent changes.
>
> Bertrand, Sawada-San, and others, do you see a problem with such a
> split? Can we go ahead with v75_0001 separately after fixing the open
> comments?
I think that makes sense, specially if we're also creating a user callable
function to sync the slot(s) at wish.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
lict part may need to be explained separately? (I think it's not
possible that they end up being re-created on the standby for this conflict,
they
will be simply removed as it would mean the counterpart one on the primary
does not exist anymore).
[1]:
https://www.postgresql.org/message-id/ZYWdSIeAMQ
Hi,
On Thu, Feb 01, 2024 at 04:12:43PM +0530, Amit Kapila wrote:
> On Thu, Jan 25, 2024 at 11:26 AM Bertrand Drouvot
> wrote:
> >
> > On Wed, Jan 24, 2024 at 04:09:15PM +0530, shveta malik wrote:
> > > On Wed, Jan 24, 2024 at 2:38 PM Bertrand Drouvot
> > >
ublisher could ...
>
> SUGGESTION:
> Otherwise, the slot on the publisher may behave differently from what
> these subscription options say: for example, the slot on the publisher
> could ...
>
As a non native English speaker somehow I have to rely on you for those
sugges
Hi,
On Mon, Jan 29, 2024 at 09:15:57AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Mon, Jan 29, 2024 at 02:35:52PM +0530, Amit Kapila wrote:
> > I think it is better to create a separate patch for two_phase after
> > this patch gets committed.
>
> Yeah, makes sense,
,
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
>From 756886e59afddd09fa6f87ab95af7292ebca3e76 Mon Sep 17 00:00:00 2001
From: Bertrand Drouvot
Date: Tue, 30 Jan 2024 14:48:16 +
Subject: [PATCH v1] Documentatio
Hi,
On Mon, Jan 29, 2024 at 02:35:52PM +0530, Amit Kapila wrote:
> On Mon, Jan 29, 2024 at 2:22 PM Bertrand Drouvot
> wrote:
> > Looking at 0001:
> >
> > + When altering the
> > + > linkend="sql-createsubscription-params-with-slot-name"&
two_phase too? (I mean ensure the slot property matchs the
subscription one).
Or would it be better to create a dedicated patch (outside of this thread) for
the "two_phase" remark? (If so I can take care of it).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS
and it does not seem to be covered).
Remarks,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Thu, Jan 25, 2024 at 03:54:45PM +0530, Amit Kapila wrote:
> On Thu, Jan 25, 2024 at 1:25 PM Bertrand Drouvot
> wrote:
> >
> > On Thu, Jan 25, 2024 at 02:57:30AM +, Zhijie Hou (Fujitsu) wrote:
> > >
> > > Agreed. I split the original 0001 patch int
de stats
> 2) Split index and table stats
Just a quick update on this: I had a chat with Andres at pgconf.eu and we agreed
on the above ordering so that:
1) I started working on relfilenode stats (I hope to be able to provide a POC
patch soon).
2) The CF entry [1] status related to this
lot failover property matches the
+ failover
+ parameter value of the subscription.
What about explaining what would be the consequence of not doing so?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Wed, Jan 24, 2024 at 04:09:15PM +0530, shveta malik wrote:
> On Wed, Jan 24, 2024 at 2:38 PM Bertrand Drouvot
> wrote:
> >
> > I also see Sawada-San's point and I'd vote for "sync_replication_slots".
> > Then for
> > the current feature I think
ues can be on, off, or failover etc.
> >
>
> I see your point. Let us see if others have any suggestions on this.
I also see Sawada-San's point and I'd vote for "sync_replication_slots". Then
for
the current feature I think "failover" and "on" should be the values to turn the
feature on (assuming "on" would mean "all kind of supported slots").
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Tue, Jan 23, 2024 at 02:50:06PM +0900, Michael Paquier wrote:
> On Mon, Jan 22, 2024 at 09:07:45AM +0000, Bertrand Drouvot wrote:
>
> I've rewritten some of that, and applied the patch down to v16.
Thanks!
> > Yeah, I can clearly see how this patch helps from a theoriti
ion if necessary.
Thanks for the warning! I don't think the current code is causing any issues so
given the feedback I've had so far I think I'll withdraw the patch.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Mon, Jan 22, 2024 at 03:54:44PM +0900, Michael Paquier wrote:
> On Fri, Jan 19, 2024 at 09:03:01AM +0000, Bertrand Drouvot wrote:
> > On Fri, Jan 19, 2024 at 09:00:01AM +0300, Alexander Lakhin wrote:
> +# Launch $sql and wait for a new snapshot that has a newer horizon befor
to extending the
replication commands): I think it still gives us the flexibility to switch to
extending the replication commands if we want to in the future.
[1]:
https://www.postgresql.org/message-id/ZZe6sok7IWmhKReU%40ip-10-97-1-34.eu-west-3.compute.internal
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
is a different subject, getting out of scope of the current
> issue.
Agree.
> 15.01.2024 11:49, Bertrand Drouvot wrote:
> > We did a few things in this thread, so to sum up what we've discovered:
> >
> > - a race condition in InvalidatePossiblyObsoleteSlot() (see [1])
> > -
ping 'count(*)=1' gives the benefit that it will straight
> away give us true/false indicating if we are good or not wrt
> primary_slot_name. I feel Assert can be removed and we can simply
> have:
>
> if (!tuplestore_gettupleslot(res->tuplestore, true, false, tupslot))
&g
Hi,
On Thu, Jan 18, 2024 at 04:01:33PM +0100, Magnus Hagander wrote:
> On Mon, Jan 15, 2024 at 11:17 AM Bertrand Drouvot
> > Did you forget to share the new revision (aka v4)? I can only see the
> > "reorder_parallel_worker_bestart.patch" attached.
>
> I did.
n place. I think it's tricky to reproduce as it would need the
slot to advance between the 2 checks.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
>From 4665945cba163bcb4beadc6391ee65c755e566d8 Mon Sep 17 00
restart" is true if one change
enable_syncslot
from on to off.
IMHO, v62-003 is in good shape and could be merged in v62-002 (that would ease
the review). But let's wait to see if others think differently.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
but (3)
> is also okay especially if others also think so.
>
Yeah, I think that (2) would be the "ideal" one but (3) is fine too. I think
that if we think/see that (2) is too "complicated"/long to implement maybe we
could do (3) initially and switch to (2) later. What I mean by that is that I
don't think that not doing (2) should be a blocker.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Fri, Jan 12, 2024 at 05:16:53PM +0100, Magnus Hagander wrote:
> On Thu, Jan 11, 2024 at 5:55 PM Bertrand Drouvot
> wrote:
> >
> > I'm wondering if it would make sense to populate it for parallel workers
> > too.
> > I think it's doable thanks to d95105
Hi,
On Sat, Jan 13, 2024 at 10:05:52AM +0530, Amit Kapila wrote:
> On Fri, Jan 12, 2024 at 12:07 PM Bertrand Drouvot
> wrote:
> > Maybe the "best" approach would be to have a way to detect that a slot has
> > been
> > re-created on the primary (but that wou
predictablity of the test (in
favor of real-world behavior testing)?
[1]:
https://www.postgresql.org/message-id/ZaTjW2Xh%2BTQUCOH0%40ip-10-97-1-34.eu-west-3.compute.internal
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.
7e076-b163-9ba3-4ade-b9fc51a3a8f6%40gmail.com
[2]:
https://www.postgresql.org/message-id/7c025095-5763-17a6-8c80-899b35bd0459%40gmail.com
Looking forward to your feedback,
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://
Hi,
On Fri, Jan 12, 2024 at 02:00:01PM +0300, Alexander Lakhin wrote:
> Hi,
>
> 12.01.2024 10:15, Bertrand Drouvot wrote:
> >
> > For this one, the "good" news is that it looks like that we don’t see the
> > "terminating" message not followed by a
d_current()).
I think that it could be "enough" for our case here, and it's what v5 attached
is
now doing.
Let's give v5 a try? (please apply
v1-0001-Fix-race-condition-in-InvalidatePossiblyObsoleteS.patch
too).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Sou
Hi,
On Fri, Jan 12, 2024 at 03:46:00AM +, Zhijie Hou (Fujitsu) wrote:
> On Thursday, January 11, 2024 11:42 PM Bertrand Drouvot
> wrote:
>
> Hi,
>
> > On Thu, Jan 11, 2024 at 04:22:56PM +0530, Amit Kapila wrote:
> > IIUC, this would be a sync slot (so
Hi,
On Fri, Jan 12, 2024 at 08:42:39AM +0530, Amit Kapila wrote:
> On Thu, Jan 11, 2024 at 9:11 PM Bertrand Drouvot
> wrote:
> >
> > On Thu, Jan 11, 2024 at 04:22:56PM +0530, Amit Kapila wrote:
> > > >
> > > > To close the above race, I could think of
Hi,
On Thu, Jan 11, 2024 at 02:24:58PM +0100, Magnus Hagander wrote:
> On Wed, Jan 10, 2024 at 3:12 PM Bertrand Drouvot
> wrote:
> >
> > If we go the 2 fields way, then what about auth_identity and auth_method
> > then?
>
>
> Here is an updated
restart_lsn is greater than local_slot's
> > restart_lsn but it is a re-created slot with the same name. In that
> > case, I think the other properties like 'two_phase', 'plugin' could be
> > different. So, is simply copying those sufficient or do we need to do
> > something else as well?
> >
>
I'm not sure to follow here. If the remote slot is re-created then it would
be also dropped / re-created locally, or am I missing something?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Thu, Jan 11, 2024 at 01:00:00PM +0300, Alexander Lakhin wrote:
> Hi Bertrand,
>
> 10.01.2024 19:32, Bertrand Drouvot wrote:
> >
> > > is an absent message 'obsolete replication slot "row_removal_activeslot"'
> > Loo
it will be harder to maintain if we are
not using them (means ensure the "direct" overwriting still makes sense over
time).
FWIW, pg_failover_slots also rely on those APIs from what I can see.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Wed, Jan 10, 2024 at 05:00:01PM +0300, Alexander Lakhin wrote:
> 10.01.2024 12:46, Bertrand Drouvot wrote:
>
> > Would it be possible to also send the standby logs?
>
> Yes, please look at the attached logs. This time I've build postgres with
> -DWAL_DEBUG and ran t
Hi,
On Wed, Jan 10, 2024 at 02:59:42PM +0100, Magnus Hagander wrote:
> On Wed, Jan 10, 2024 at 2:56 PM Bertrand Drouvot
> I definitely think it should be the same. If it's not exactly the
> same, then it should be *two* columns, one with auth method and one
> with the name.
>
>
; +
> +
I'm fine with auth_method:identity.
> +S.authname,
What about using system_user as the field name? (because if we keep
auth_method:identity it's not really the authname anyway).
Also, what about adding a test in say 003_peer.pl to check that the value
matches
the SYSTEM_USER one?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
he same (23
and 24).
That is even more weird as those tests should be the 24 and 25 ones.
Would it be possible to also send the standby logs?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
ty once you begin using the
> patch posted on [2], mentioned by Bertrand?
Alexander, pleae find attached v3 which is more or less a rebased version of it.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
>From 0
Hi,
On Mon, Jan 08, 2024 at 04:02:12PM -0600, Nathan Bossart wrote:
> Sorry for the noise. I spent some more time tidying this up for commit,
> which I am hoping to do in the next day or two.
Thanks! v6 looks good to me.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RD
Hi,
On Sat, Jan 06, 2024 at 10:18:52AM -0600, Nathan Bossart wrote:
> On Sat, Jan 06, 2024 at 09:03:52AM +0000, Bertrand Drouvot wrote:
> > Sorry, I missed this in my first review, but instead of:
> >
> > - input: files('../../backend/storage/lmgr/lwlocknames.txt'),
due to [1]
(means something holding global xmin).
BTW, I think we should resume working on [1] and having it fixed in all the
cases.
[1]:
https://www.postgresql.org/message-id/d40d015f-03a4-1cf2-6c1f-2b9aca860762%40gmail.com
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open S
Hi,
On Fri, Jan 05, 2024 at 11:46:20AM -0600, Nathan Bossart wrote:
> On Fri, Jan 05, 2024 at 10:42:03AM -0600, Nathan Bossart wrote:
> > On Fri, Jan 05, 2024 at 07:39:39AM +, Bertrand Drouvot wrote:
> >> + die "lists of predefined LWL
Hi,
On Fri, Jan 05, 2024 at 10:00:53AM +0530, Amit Kapila wrote:
> On Fri, Jan 5, 2024 at 8:59 AM shveta malik wrote:
> >
> > On Thu, Jan 4, 2024 at 7:24 PM Bertrand Drouvot
> > wrote:
> > >
> > > 4 ===
> > >
> > > Lookin
Hi,
On Fri, Jan 05, 2024 at 12:11:44AM -0600, Nathan Bossart wrote:
> On Wed, Jan 03, 2024 at 07:59:45AM +0000, Bertrand Drouvot wrote:
> > +1 to add a test and put in a place that would produce failures at build
> > time.
> > I think that having the test in the script that
at does make sense, but what do you think about creating dedicated
libpqslotsyncwrkr_connect
and slotsyncwrkr_connect (instead of using the libpqrcv_connect /
walrcv_connect ones)?
That way we could make use of slotsyncwrkr_connect() in ReplSlotSyncWorkerMain()
as I think it's confusing to use "rcv" functions while the process using them is
not of backend type walreceiver.
I'm not sure that worth the extra complexity though, what do you think?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
ecide to add a new GUC (for
> dbname) for slotsync worker.
>
I think that as long as enable_syncslot is off then there is no need to add the
dbname in primary_conninfo (means there is no need to change an existing
primary_conninfo
for the ones that don't use the sync slot feature).
So g
g, which might be kind of
> > nice, too.
>
> Yeah, I think that would be better.
+1 to add a test and put in a place that would produce failures at build time.
I think that having the test in the script that generates the header file is
more
appropriate (as building the documentat
Hi,
On Wed, Jan 03, 2024 at 08:53:44AM +0530, Amit Kapila wrote:
> On Wed, Jan 3, 2024 at 7:10 AM Michael Paquier wrote:
> >
> > On Tue, Jan 02, 2024 at 02:07:58PM +, Bertrand Drouvot wrote:
> > > + wal_level_insufficient means that the
> >
out the need to
refer
to the documentation) and that the fact that it is "insufficient" is more or
less
implicit.
Basically I think that with "primary_wal_level" one would need to refer to the
doc
less frequently than with "wal_level_insufficient".
But again, that's a Nit so feel f
eplacing the existing boolean
> with a text.
Same here, I'd vote to avoid 2 columns having the same "meaning".
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
the standby starts, the "synced" slots will be invalidated and later
removed but not re-created on the next sync-cycle (because they don't exist
anymore on the primary).
Worth to reword a bit that part?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
e numerical value for a C enum. So it has to
> > be
> > converted to something SQL representable.
> >
>
> We can return int2 value from the function pg_get_replication_slots()
> and then use that to display a string in the view
> pg_replication_slots.
Yeah, and in
lication can be resumed after a
failover. Should we add a few words about possible lag? (see [1])
[1]:
https://www.postgresql.org/message-id/CAA4eK1KihniOK21mEVYtSOHRQiGNyToUmENWp7hPbH_PMsqzkA%40mail.gmail.com
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
show the flag when !isCatalogRel, but I cannot get
> > excited about that either because that would require one to do more
> > cross-checks with the core code when looking at WAL dumps.
>
> Thank you for the comments. Agreed.
>
> I've just pushed, bf6260b39.
>
Thanks!
--
Be
Hi,
New wording works for me, thanks!
Bertrand
Le sam. 8 avr. 2023, 08:26, Andres Freund a écrit :
> Hi,
>
> On 2023-04-07 11:12:26 -0700, Andres Freund wrote:
> > +
> > +
> > + confl_active_logicalslot
> bigint
> > +
> > +
> > + Number of active logical
Hello Guys,
As you mentioned Oracle like active session history sampling in this
thread, I just want to let you know that I am working on a brand new
extension to provide this feature.
You can find the extension here: https://github.com/pgsentinel/pgsentinel
Basically, you could see it as
201 - 262 of 262 matches
Mail list logo