On Mon, Aug 01, 2022 at 01:04:39AM +0300, Anton A. Melnikov wrote:
> I looked at this thread and tried to apply some changes from it in practice.
> And found one strange error and describe it in a comment here:
> https://www.postgresql.org/message-id/cc7e961a-d5ad-8c6d-574b-478aacc11cf7%40inbox.ru
Hello!
On 06.07.2022 08:58, Michael Paquier wrote:
That's the kind of things I already proposed on this thread, aimed at
improving the coverage, and this takes care of more issues than what's
proposed here:
https://www.postgresql.org/message-id/flat/Yox1ME99GhAemMq1(at)paquier(dot)xyz
I'll
On Tue, Jul 05, 2022 at 02:08:24PM -0500, Justin Pryzby wrote:
> ..since it tries to apply all the *.patch files to the master branch, one
> after
> another. For branches other than master, I suggest to name the patches *.txt
> or similar. Or, just focus for now on allowing upgrades *to*
On Tue, Jul 05, 2022 at 09:01:49AM +0300, Anton A. Melnikov wrote:
> On 01.07.2022 20:07, Justin Pryzby wrote:
> > It's silly to say that v9.2 will be supported potentially for a handful more
> > years, but that the upgrade-testing script itself doesn't support that, so
> > developers each have to
Hello!
On 01.07.2022 20:07, Justin Pryzby wrote:
Would you add this to to the (next) CF ?
Yes, i've put it on september CF.
It's silly to say that v9.2 will be supported potentially for a handful more
years, but that the upgrade-testing script itself doesn't support that, so
developers each
Would you add this to to the (next) CF ?
It's silly to say that v9.2 will be supported potentially for a handful more
years, but that the upgrade-testing script itself doesn't support that, so
developers each have to reinvent its fixups.
See also 20220122183749.go23...@telsasoft.com, where I
Hello!
On 02.06.2022 23:57, Andrew Dunstan wrote:
1. There is no mention of why there's a change w.r.t. Cygwin and
permissions checks. Maybe it's ok, but it seems off topic and is
certainly not referred to in the patch submission.
Thanks for the comments!
It was my error to change w.r.t.
On 2022-06-01 We 21:37, Michael Paquier wrote:
> On Thu, Jun 02, 2022 at 04:22:52AM +0300, Anton A. Melnikov wrote:
>> Found out that test for pg_upgrade (test.sh for 11-14 and 002_pg_upgrade.pl
>> for 15+) doesn't work from 10th versions to higher ones due to incompatible
>> options for initdb
On Thu, Jun 02, 2022 at 12:36:30AM -0400, Tom Lane wrote:
> The buildfarm animals that test cross-version upgrades are not
> unhappy, so please be more specific about what problem you
> are trying to solve.
Anton is complaining about the case where you try to use the in-core
upgrade tests with a
"Anton A. Melnikov" writes:
> Found out that test for pg_upgrade (test.sh for 11-14 and
> 002_pg_upgrade.pl for 15+) doesn't work from 10th versions to higher
> ones due to incompatible options for initdb and default PGDATA permissions.
The buildfarm animals that test cross-version upgrades
On Thu, Jun 02, 2022 at 04:22:52AM +0300, Anton A. Melnikov wrote:
> Found out that test for pg_upgrade (test.sh for 11-14 and 002_pg_upgrade.pl
> for 15+) doesn't work from 10th versions to higher ones due to incompatible
> options for initdb and default PGDATA permissions.
Yeah, there are still
Hello!
Found out that test for pg_upgrade (test.sh for 11-14 and
002_pg_upgrade.pl for 15+) doesn't work from 10th versions to higher
ones due to incompatible options for initdb and default PGDATA permissions.
Here are the patches that may solve this problem.
Would be glad to your comments
12 matches
Mail list logo
