Hi Rustam,
> Hi Aleksander,
> I have reviewed your patch. It looks good to me.
>
> Kindest regards.
> Rustam Allakov
>
> The new status of this patch is: Ready for Committer
Thanks for testing!
Here is the rebased patch.
--
Best regards,
Aleksander Alekseev
v5-0001-Always-use-long-SLRU-segme
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi Aleksander,
I have reviewed your patch. It looks good to
Hi,
> > Here is an updated patch. The steps to test it manually are as follows.
> >
> > Compile and install PostgreSQL from the REL_17_STABLE branch:
> >
> > [...]
> >
> > As always, your feedback and suggestions are most welcomed.
>
> Rebased.
Rebased.
--
Best regards,
Aleksander Alekseev
From
Hi,
> Here is an updated patch. The steps to test it manually are as follows.
>
> Compile and install PostgreSQL from the REL_17_STABLE branch:
>
> [...]
>
> As always, your feedback and suggestions are most welcomed.
Rebased.
--
Best regards,
Aleksander Alekseev
v3-0001-Always-use-long-SLRU-s
Hi,
> For the record, Michael and I had a brief discussion about this
> offlist and decided to abandon the idea of adding TAP tests, relying
> only on buildfarm. Also I will check if we have a clear error message
> in case when a user forgot to run pg_upgrade and running new slru.c
> with old file
Hi,
> I guess we are going to need either a `pg_writecontoldata` tool or
> `pg_controldata -w` flag. I wonder which option you find more
> attractive, or maybe you have better ideas?
For the record, Michael and I had a brief discussion about this
offlist and decided to abandon the idea of adding
Hi Michael,
> The scans may be quite long as well, actually, which could be a
> bottleneck. Did you measure the runtime with a maximized (still
> realistic) pool of files for these SLRUs in the upgrade time? For
> upgrades, data would be the neck.
Good question.
In theory SLRUs are not suppose
On Tue, Nov 12, 2024 at 05:37:02PM +0300, Aleksander Alekseev wrote:
> Also it occured to me that as a 4th option we could just get rid of
> this check. Users however will pay the price every time they execute
> pg_upgrade so I doubt we are going to do this.
We cannot remove the check, or Nathan w
Hi again,
Just a quick follow-up.
> (*) BTW I noticed a mistake in the commented code. The condition
> should be `>=`, not `<`, i.e:
>
> ```
> if(new_cluster.controldata.cat_ver >= SLRU_SEG_FILENAMES_CHANGE_CAT_VER)
> return;
> ```
The concentration of caffeine in my blood is a bit l
Hi Michael,
Thanks for your feedback!
> Your patch is just doing a rename() of the files from short to long
> names. How about adding a new TAP script in pg_upgrade that creates a
> couple of empty files with short files names in each path that needs
> to do the transfer? Then the test could ru
On Thu, Sep 12, 2024 at 12:33:14PM +0300, Aleksander Alekseev wrote:
> It wouldn't hurt re-checking the segment file names in the TAP test
> but this would mean hardcoding catalog names which as I understand you
> want to avoid. With high probability PG wouldn't start if the
> corresponding piece o
Hi Michael,
> On Wed, Sep 11, 2024 at 04:07:06PM +0300, Aleksander Alekseev wrote:
> > Commit 4ed8f0913bfd introduced long SLRU file names. The proposed
> > patch removes SlruCtl->long_segment_names flag and makes SLRU always
> > use long file names. This simplifies both the code and the API.
> >
On Wed, Sep 11, 2024 at 04:07:06PM +0300, Aleksander Alekseev wrote:
> Commit 4ed8f0913bfd introduced long SLRU file names. The proposed
> patch removes SlruCtl->long_segment_names flag and makes SLRU always
> use long file names. This simplifies both the code and the API.
> Corresponding changes t
Hi,
Commit 4ed8f0913bfd introduced long SLRU file names. The proposed
patch removes SlruCtl->long_segment_names flag and makes SLRU always
use long file names. This simplifies both the code and the API.
Corresponding changes to pg_upgrade are included.
One drawback I see is that technically SLRU
14 matches
Mail list logo
