On Fri, Sep 8, 2023 at 11:59 AM Amit Kapila wrote:
>
> On Fri, Sep 8, 2023 at 10:10 AM Michael Paquier wrote:
> >
> > On Fri, Sep 08, 2023 at 09:14:59AM +0530, Amit Kapila wrote:
> > > On Fri, Sep 8, 2023 at 9:00 AM Zhijie Hou (Fujitsu)
> > > wrote:
> > >>> I
> > >>> mean that doing the latter
On Fri, Sep 8, 2023 at 10:10 AM Michael Paquier wrote:
>
> On Fri, Sep 08, 2023 at 09:14:59AM +0530, Amit Kapila wrote:
> > On Fri, Sep 8, 2023 at 9:00 AM Zhijie Hou (Fujitsu)
> > wrote:
> >>> I
> >>> mean that doing the latter is benefitial for the sake of any patch
> >>> committed and
> >>>
On Fri, Sep 08, 2023 at 11:59:41AM +0530, Amit Kapila wrote:
> I agree with doing something simple. So, to conclude, we agree on two
> things in this thread (a) Use max_slot_wal_keep_size to -1 to start
> postmaster for the old cluster during the upgrade; (b) Have an
> elog(ERROR) to avoid
On Fri, Sep 08, 2023 at 09:14:59AM +0530, Amit Kapila wrote:
> On Fri, Sep 8, 2023 at 9:00 AM Zhijie Hou (Fujitsu)
> wrote:
>>> I
>>> mean that doing the latter is benefitial for the sake of any patch
>>> committed and
>>> as a long-term method to rely on.
>
> What is your worry here? Are you
On Fri, Sep 8, 2023 at 9:00 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Friday, September 8, 2023 10:58 AM Michael Paquier
> wrote:
> >
> > On Fri, Sep 08, 2023 at 08:18:14AM +0530, Amit Kapila wrote:
> > > This validation tries to ensure that we don't have any bugs/issues in
> > > our patch. It may
On Fri, Sep 08, 2023 at 03:30:23AM +, Zhijie Hou (Fujitsu) wrote:
> I feel adding a check at pg_upgrade may not 100% detect the slot invalidation
> if we check by querying the old cluster to get the slot info, because the
> invalidation can happen before the first time we fetch the info or
On Friday, September 8, 2023 10:58 AM Michael Paquier
wrote:
>
> On Fri, Sep 08, 2023 at 08:18:14AM +0530, Amit Kapila wrote:
> > This validation tries to ensure that we don't have any bugs/issues in
> > our patch. It may be a candidate for assert but I feel even if we
> > encounter any bug it
On Fri, Sep 08, 2023 at 08:18:14AM +0530, Amit Kapila wrote:
> This validation tries to ensure that we don't have any bugs/issues in
> our patch. It may be a candidate for assert but I feel even if we
> encounter any bug it is better to fix the bug.
My guess is that an elog-like error is more
On Fri, Sep 8, 2023 at 5:37 AM Michael Paquier wrote:
>
> On Thu, Sep 07, 2023 at 03:33:52PM +0530, Amit Kapila wrote:
> > I think if we just make max_slot_wal_keep_size to -1 that should be
> > sufficient to not let any slots get invalidated during upgrade. Do you
> > have anything else in mind?
On Thu, Sep 07, 2023 at 03:33:52PM +0530, Amit Kapila wrote:
> I think if we just make max_slot_wal_keep_size to -1 that should be
> sufficient to not let any slots get invalidated during upgrade. Do you
> have anything else in mind?
Forcing wal_keep_size while on it may be a good thing.
> If we
On Thu, Sep 7, 2023 at 3:34 PM Amit Kapila wrote:
>
> On Thu, Sep 7, 2023 at 12:55 PM Michael Paquier wrote:
> >
> > (Just dumping what I have in mind while reading the thread.)
> >
> > On Sat, Sep 02, 2023 at 10:08:51AM +0530, Amit Kapila wrote:
> > > During pg_upgrade, we start the server for
On Thu, Sep 7, 2023 at 12:55 PM Michael Paquier wrote:
>
> (Just dumping what I have in mind while reading the thread.)
>
> On Sat, Sep 02, 2023 at 10:08:51AM +0530, Amit Kapila wrote:
> > During pg_upgrade, we start the server for the old cluster which can
> > allow the checkpointer to remove
(Just dumping what I have in mind while reading the thread.)
On Sat, Sep 02, 2023 at 10:08:51AM +0530, Amit Kapila wrote:
> During pg_upgrade, we start the server for the old cluster which can
> allow the checkpointer to remove the WAL files. It has been noticed
> that we do generate certain
On Tue, Sep 5, 2023 at 10:55 AM Amit Kapila wrote:
>
> > Earlier I was thinking that ERRORing out is better so that the user
> > can take necessary action for the invalidated slots and then retry
> > upgrade. But thinking again I could not find what are the advantages
> > of this because if we
On Tue, Sep 5, 2023 at 10:09 AM Dilip Kumar wrote:
>
> On Tue, Sep 5, 2023 at 9:38 AM Amit Kapila wrote:
> >
> > On Mon, Sep 4, 2023 at 4:19 PM Dilip Kumar wrote:
> > >
> > > Said that there is a possibility that some of the slots which got
> > > invalidated even on the previous checkpoint
On Tue, Sep 5, 2023 at 9:38 AM Amit Kapila wrote:
>
> On Mon, Sep 4, 2023 at 4:19 PM Dilip Kumar wrote:
> >
> > Said that there is a possibility that some of the slots which got
> > invalidated even on the previous checkpoint might get the same LSN as
> > the slot which got invalidated later if
On Mon, Sep 4, 2023 at 4:19 PM Dilip Kumar wrote:
>
> Said that there is a possibility that some of the slots which got
> invalidated even on the previous checkpoint might get the same LSN as
> the slot which got invalidated later if there is no activity between
> these two checkpoints. So if we
On Mon, Sep 4, 2023 at 1:41 PM Dilip Kumar wrote:
>
> > > I think we can do better, like we can just read the latest
> > > checkpoint's LSN before starting the old cluster. And now while
> > > checking the slot can't we check if the the slot is invalidated then
> > > their confirmed_flush_lsn >=
On Mon, Sep 4, 2023 at 11:18 AM Amit Kapila wrote:
>
> On Mon, Sep 4, 2023 at 10:33 AM Dilip Kumar wrote:
> >
> > On Mon, Sep 4, 2023 at 8:41 AM Amit Kapila wrote:
> > >
> > > On Sat, Sep 2, 2023 at 6:12 PM Dilip Kumar wrote:
> > > >
> > > > On Sat, Sep 2, 2023 at 10:09 AM Amit Kapila
> > >
On Mon, Sep 4, 2023 at 10:33 AM Dilip Kumar wrote:
>
> On Mon, Sep 4, 2023 at 8:41 AM Amit Kapila wrote:
> >
> > On Sat, Sep 2, 2023 at 6:12 PM Dilip Kumar wrote:
> > >
> > > On Sat, Sep 2, 2023 at 10:09 AM Amit Kapila
> > > wrote:
> > >
> > > > The other possibilities apart from not allowing
On Mon, Sep 4, 2023 at 8:41 AM Amit Kapila wrote:
>
> On Sat, Sep 2, 2023 at 6:12 PM Dilip Kumar wrote:
> >
> > On Sat, Sep 2, 2023 at 10:09 AM Amit Kapila wrote:
> >
> > > The other possibilities apart from not allowing an upgrade in such a
> > > case could be (a) Before starting the old
On Sat, Sep 2, 2023 at 6:12 PM Dilip Kumar wrote:
>
> On Sat, Sep 2, 2023 at 10:09 AM Amit Kapila wrote:
>
> > The other possibilities apart from not allowing an upgrade in such a
> > case could be (a) Before starting the old cluster, we fetch the slots
> > directly from the disk using some tool
On Sat, Sep 2, 2023 at 10:09 AM Amit Kapila wrote:
>
> During pg_upgrade, we start the server for the old cluster which can
> allow the checkpointer to remove the WAL files. It has been noticed
> that we do generate certain types of WAL records (e.g
> XLOG_RUNNING_XACTS, XLOG_CHECKPOINT_ONLINE,
23 matches
Mail list logo
