On Thu, Jun 20, 2024 at 2:35 AM Euler Taveira wrote:
>
> I will open new threads soon if you don't.
>
Okay, thanks. I'll wait for you to start new threads and then we can
discuss the respective problems in those threads.
--
With Regards,
Amit Kapila.
On Wed, Jun 19, 2024, at 12:51 AM, Amit Kapila wrote:
> Ideally, invalidated slots shouldn't create any problems but it is
> better that we discuss this also as a separate problem in new thread.
Ok.
> > Do you have any other scenarios in mind?
> >
>
> No, so we have three issues to discuss (a) s
On Tue, Jun 18, 2024 at 11:55 PM Amit Kapila wrote:
> We can close the open item pointing to this thread.
Done, and for the record I also asked for the thread to be split, back
on May 22.
IMHO, we shouldn't add open items pointing to general complaints like
the one that started this thread. Open
On Tue, Jun 18, 2024 at 12:13 PM Peter Eisentraut wrote:
>
> On 18.06.24 05:59, Amit Kapila wrote:
> >> 1. After promotion, the pre-existing replication objects should be
> >> removed (either optionally or always), otherwise, it can lead to a new
> >> subscriber not being able to restart or gettin
On Tue, Jun 18, 2024 at 12:41 PM Euler Taveira wrote:
>
> On Tue, Jun 18, 2024, at 12:59 AM, Amit Kapila wrote:
>
> On Mon, May 20, 2024 at 12:12 PM Amit Kapila wrote:
> >
> > On Sun, May 19, 2024 at 11:20 PM Euler Taveira wrote:
> > >
> > > On Sun, May 19, 2024, at 2:30 PM, Tom Lane wrote:
> >
On Tue, Jun 18, 2024, at 12:59 AM, Amit Kapila wrote:
> On Mon, May 20, 2024 at 12:12 PM Amit Kapila wrote:
> >
> > On Sun, May 19, 2024 at 11:20 PM Euler Taveira wrote:
> > >
> > > On Sun, May 19, 2024, at 2:30 PM, Tom Lane wrote:
> > >
> > > I'm fairly disturbed about the readiness of pg_create
On 18.06.24 05:59, Amit Kapila wrote:
1. After promotion, the pre-existing replication objects should be
removed (either optionally or always), otherwise, it can lead to a new
subscriber not being able to restart or getting some unwarranted data.
[1][2].
2. Retaining synced slots on new subscrib
On Mon, May 20, 2024 at 12:12 PM Amit Kapila wrote:
>
> On Sun, May 19, 2024 at 11:20 PM Euler Taveira wrote:
> >
> > On Sun, May 19, 2024, at 2:30 PM, Tom Lane wrote:
> >
> > I'm fairly disturbed about the readiness of pg_createsubscriber.
> > The 040_pg_createsubscriber.pl TAP test is moderatel
On Thu, May 23, 2024 at 4:40 AM Amit Kapila wrote:
> Sorry, for the wrong link. See [1] for the correct link for --dry-run
> related suggestion:
>
> [1]
> https://www.postgresql.org/message-id/CAA4eK1J2fAvsJ2HihbWJ_GxETd6sdqSMrZdCVJEutRZRpm1MEQ%40mail.gmail.com
Yeah, those should definitely be f
On Wed, May 22, 2024 at 8:02 PM Robert Haas wrote:
>
> On Mon, May 20, 2024 at 2:42 AM Amit Kapila wrote:
> > Just to summarize, apart from BF failures for which we had some
> > discussion, I could recall the following open points:
> >
> > 1. After promotion, the pre-existing replication objects
Dear Amit, Robert,
> So, we have the following options: (a) by default drop the
> pre-existing subscriptions, (b) by default disable the pre-existing
> subscriptions, and add a Note in the docs that users can take
> necessary actions to enable or drop them. Now, we can even think of
> providing a
On Wed, May 22, 2024 at 8:00 PM Robert Haas wrote:
>
> On Wed, May 22, 2024 at 9:52 AM Robert Haas wrote:
> > Another option that we should at least consider is "do nothing". In a
> > case like the one Shlok describes, how are we supposed to know what
> > the right thing to do is? Is it unreasona
On Mon, May 20, 2024 at 2:42 AM Amit Kapila wrote:
> Just to summarize, apart from BF failures for which we had some
> discussion, I could recall the following open points:
>
> 1. After promotion, the pre-existing replication objects should be
> removed (either optionally or always), otherwise, it
On Wed, May 22, 2024 at 9:52 AM Robert Haas wrote:
> Another option that we should at least consider is "do nothing". In a
> case like the one Shlok describes, how are we supposed to know what
> the right thing to do is? Is it unreasonable to say that if the user
> doesn't want those publications
On Wed, May 22, 2024 at 7:42 AM Amit Kapila wrote:
> So, what shall we do about such cases? I think by default we can
> remove all pre-existing subscriptions and publications on the promoted
> standby or instead we can remove them based on some switch. If we want
> to go with this idea then we mi
On Wed, May 22, 2024 at 2:45 PM Shlok Kyal wrote:
>
> > Just to summarize, apart from BF failures for which we had some
> > discussion, I could recall the following open points:
> >
> > 1. After promotion, the pre-existing replication objects should be
> > removed (either optionally or always), ot
> Just to summarize, apart from BF failures for which we had some
> discussion, I could recall the following open points:
>
> 1. After promotion, the pre-existing replication objects should be
> removed (either optionally or always), otherwise, it can lead to a new
> subscriber not being able to re
On Sun, May 19, 2024 at 02:49:22PM -0300, Euler Taveira wrote:
> My bad. :( I'll post patches soon to address all of the points.
Please note that I have added an open item pointing at this thread.
--
Michael
signature.asc
Description: PGP signature
On Sun, May 19, 2024 at 11:20 PM Euler Taveira wrote:
>
> On Sun, May 19, 2024, at 2:30 PM, Tom Lane wrote:
>
> I'm fairly disturbed about the readiness of pg_createsubscriber.
> The 040_pg_createsubscriber.pl TAP test is moderately unstable
> in the buildfarm [1], and there are various unaddresse
On Sun, May 19, 2024, at 2:30 PM, Tom Lane wrote:
> I'm fairly disturbed about the readiness of pg_createsubscriber.
> The 040_pg_createsubscriber.pl TAP test is moderately unstable
> in the buildfarm [1], and there are various unaddressed complaints
> at the end of the patch thread (pretty much ev
I'm fairly disturbed about the readiness of pg_createsubscriber.
The 040_pg_createsubscriber.pl TAP test is moderately unstable
in the buildfarm [1], and there are various unaddressed complaints
at the end of the patch thread (pretty much everything below [2]).
I guess this is good enough to start
21 matches
Mail list logo
