On Sat, Nov 16, 2024 at 03:22:57PM -0500, Andres Freund wrote:
> Hi,
>
> On 2024-08-06 14:10:15 -0500, Justin Pryzby wrote:
> > > > + # The commit that this branch is rebased on. There's no easy way to
> > > > find this.
> > >
> > > I don't think that's true, IIRC I've complained about it befo
Hi,
On 2024-08-06 14:10:15 -0500, Justin Pryzby wrote:
> > > + # The commit that this branch is rebased on. There's no easy way to
> > > find this.
> >
> > I don't think that's true, IIRC I've complained about it before. We can do
> > something like:
>
> cfbot now exposes it, so it'd be trivi
On Tue, Jun 18, 2024 at 02:25:46PM -0700, Andres Freund wrote:
> > > If not, we can just install the binaries distributed by the project, it's
> > > just more work to keep up2date that way.
> >
> > I guess you mean a separate line to copy choco's ccache.exe somewhere.
>
> I was thinking of alte
Hi,
On 2024-06-18 08:36:57 -0500, Justin Pryzby wrote:
> On Fri, Jun 14, 2024 at 08:34:37AM -0700, Andres Freund wrote:
> > Hm. There actually already is the mingw ccache installed. The images for
> > mingw and msvc used to be separate (for startup performance when using
> > containers), but we
On Fri, Jun 14, 2024 at 08:34:37AM -0700, Andres Freund wrote:
> Hm. There actually already is the mingw ccache installed. The images for
> mingw and msvc used to be separate (for startup performance when using
> containers), but we just merged them. So it might be easiest to just
> explicitly
Hi,
On June 14, 2024 8:22:01 AM PDT, Justin Pryzby wrote:
>On Fri, Jun 14, 2024 at 05:36:54PM +0300, Nazir Bilal Yavuz wrote:
>> Hi,
>>
>> On Thu, 13 Jun 2024 at 14:56, Justin Pryzby wrote:
>> >
>> > ccache should be installed in the image rather than re-installed on each
>> > invocation.
>>
On Fri, Jun 14, 2024 at 05:36:54PM +0300, Nazir Bilal Yavuz wrote:
> Hi,
>
> On Thu, 13 Jun 2024 at 14:56, Justin Pryzby wrote:
> >
> > ccache should be installed in the image rather than re-installed on each
> > invocation.
>
> ccache is installed in the Windows VM images now [1]. It can be use
Hi,
On Thu, 13 Jun 2024 at 14:56, Justin Pryzby wrote:
>
> ccache should be installed in the image rather than re-installed on each
> invocation.
ccache is installed in the Windows VM images now [1]. It can be used
as 'set CC=ccache.exe cl.exe' in the Windows CI task.
[1]
https://github.com/an
On Thu, Jun 13, 2024 at 06:56:20AM -0500, Justin Pryzby wrote:
> On Thu, Jun 13, 2024 at 02:38:46PM +0300, Nazir Bilal Yavuz wrote:
>>> I reintroduced the patch for ccache/windows -- v4.10 supports PCH, which
>>> can make the builds 2x faster.
>>
>> I applied 0001 and 0002 to see ccache support on
On Thu, Jun 13, 2024 at 02:38:46PM +0300, Nazir Bilal Yavuz wrote:
> On Wed, 12 Jun 2024 at 16:10, Justin Pryzby wrote:
> > On Fri, Jun 24, 2022 at 08:38:50AM +1200, Thomas Munro wrote:
> > > > I've also sent some patches to Thomas for cfbot to help progress some
> > > > of these
> > > > patches
Hi,
Thanks for working on this!
On Wed, 12 Jun 2024 at 16:10, Justin Pryzby wrote:
>
> On Fri, Jun 24, 2022 at 08:38:50AM +1200, Thomas Munro wrote:
> > > I've also sent some patches to Thomas for cfbot to help progress some of
> > > these
> > > patches (code coverage and documentation upload a
On Fri, Jun 24, 2022 at 08:38:50AM +1200, Thomas Munro wrote:
> > I've also sent some patches to Thomas for cfbot to help progress some of
> > these
> > patches (code coverage and documentation upload as artifacts).
> > https://github.com/justinpryzby/cfbot/commits/master
>
> Thanks, sorry for la
On Mon, Apr 08, 2024 at 05:54:10PM +0300, Andrey M. Borodin wrote:
> Justin, Peter, I can't determine actual status of the CF entry
> [0]. May I ask someone of you to move patch to next CF or close as
> committed?
0002 is the only thing committed as of 21a71648d39f.
I can see the value in 0001, b
> On 19 Feb 2024, at 11:33, Peter Eisentraut wrote:
>
> Ok, I didn't see that my feedback had been addressed. I have committed this
> patch.
Justin, Peter, I can't determine actual status of the CF entry [0]. May I ask
someone of you to move patch to next CF or close as committed?
Thanks!
On 13.02.24 20:10, Justin Pryzby wrote:
On Mon, Mar 13, 2023 at 07:39:52AM +0100, Peter Eisentraut wrote:
On 03.02.23 15:26, Justin Pryzby wrote:
9baf41674ad pg_upgrade: tap test: exercise --link and --clone
This seems like a good idea.
On Wed, Mar 15, 2023 at 10:58:41AM +0100, Peter Eisentra
On Wed, Jan 31, 2024 at 11:59:21AM +0100, Alvaro Herrera wrote:
> On 2024-Jan-31, vignesh C wrote:
>
> > Are we planning to do anything more on this? I was not sure if we
> > should move this to next commitfest or return it.
>
> Well, the patches don't apply anymore since .cirrus.tasks.yml has be
On 2024-Jan-31, vignesh C wrote:
> Are we planning to do anything more on this? I was not sure if we
> should move this to next commitfest or return it.
Well, the patches don't apply anymore since .cirrus.tasks.yml has been
created. However, I'm sure we still want [some of] the improvements
to t
On Thu, 18 Jan 2024 at 06:46, Michael Paquier wrote:
>
> On Wed, Jan 17, 2024 at 05:34:00PM +0530, vignesh C wrote:
> > Are we planning to do anything more in this thread, the thread has
> > been idle for more than 7 months. If nothing more is planned for this,
> > I'm planning to close this commi
On Wed, Jan 17, 2024 at 05:34:00PM +0530, vignesh C wrote:
> Are we planning to do anything more in this thread, the thread has
> been idle for more than 7 months. If nothing more is planned for this,
> I'm planning to close this commitfest entry in this commitfest.
Oops, this went through the cra
On Wed, 12 Jul 2023 at 11:38, Michael Paquier wrote:
>
> On Wed, Jul 12, 2023 at 12:56:17AM -0500, Justin Pryzby wrote:
> > And, since 681d9e462:
> >
> > security is missing from contrib/seg/meson.build
>
> Ugh. Good catch!
Are we planning to do anything more in this thread, the thread has
been
On Wed, Jul 12, 2023 at 12:56:17AM -0500, Justin Pryzby wrote:
> And, since 681d9e462:
>
> security is missing from contrib/seg/meson.build
Ugh. Good catch!
--
Michael
signature.asc
Description: PGP signature
On Tue, Jan 17, 2023 at 11:35:09AM -0600, Justin Pryzby wrote:
> However, this finds two real problems and one false-positive with
> missing regress/isolation tests:
>
> $ for makefile in `find src contrib -name Makefile`; do for testname in `sed
> -r '/^(REGRESS|ISOLATION) =/!d; s///; :l; /$
On 12.04.23 03:05, Justin Pryzby wrote:
The patch is rebased now that meson is updated to avoid the windows
python warnings (thanks Andres).
To keep this moving along, I have committed
[PATCH 3/8] cirrus/freebsd: define ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS
On Wed, Mar 15, 2023 at 04:57:34PM +0100, Peter Eisentraut wrote:
> On 15.03.23 15:56, Justin Pryzby wrote:
> > I'm surprised if there's any question about the merits of making
> > documentation easily available for review. Several people have agreed;
> > one person mailed me privately specificall
On 15.03.23 15:56, Justin Pryzby wrote:
I'm surprised if there's any question about the merits of making
documentation easily available for review. Several people have agreed;
one person mailed me privately specifically to ask how to show HTML docs
on cirrusci.
Anyway, all this stuff is best ad
On Wed, Mar 15, 2023 at 10:58:41AM +0100, Peter Eisentraut wrote:
> On 14.03.23 05:56, Justin Pryzby wrote:
> > I'm soliticing feedback on those patches that I've sent recently - I've
> > elided patches if they have some unresolved issue.
>
> > [PATCH 1/8] cirrus/windows: add compiler_warnings_scr
On 14.03.23 05:56, Justin Pryzby wrote:
I'm soliticing feedback on those patches that I've sent recently - I've
elided patches if they have some unresolved issue.
> [PATCH 1/8] cirrus/windows: add compiler_warnings_script
Needs a better description of what it actually does. (And fewer "I'm
n
On Mon, Mar 13, 2023 at 07:39:52AM +0100, Peter Eisentraut wrote:
> On 03.02.23 15:26, Justin Pryzby wrote:
> > rebased, and re-including a patch to show code coverage of changed
> > files.
>
> This constant flow of patches under one subject doesn't lend itself well to
> the commit fest model of t
On 03.02.23 15:26, Justin Pryzby wrote:
rebased, and re-including a patch to show code coverage of changed
files.
This constant flow of patches under one subject doesn't lend itself well
to the commit fest model of trying to finish things up. I can't quite
tell which of these patches are rea
rebased, and re-including a patch to show code coverage of changed
files.
a5b3e50d922 cirrus/windows: add compiler_warnings_script
4c98dcb0e03 cirrus/freebsd: run with more CPUs+RAM and do not repartition
aaeef938ed4 cirrus/freebsd: define ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS
9baf41674ad pg_u
On Thu, Feb 2, 2023 at 2:12 PM Tom Lane wrote:
> Thomas Munro writes:
> > Some observations:
> > So what should our policy be on when to roll the CI image forward? I
> > guess around New Year/now (~6 months after release) is a good time and
> > we should just do it. Anyone got a reason why we s
Thomas Munro writes:
> Some observations:
> * macOS has a new release every year in June[1]
> * updates cease after three years[1]
> * thus three releases are in support (by that definition) at a time
> * we need an image on Cirrus; 13 appeared ~1 month later[2]
> * we need Homebrew support; 13 a
On Fri, Dec 30, 2022 at 4:59 PM Thomas Munro wrote:
> On Wed, Nov 23, 2022 at 11:57 AM Justin Pryzby wrote:
> > [PATCH 03/10] cirrus/macos: update to macos ventura
>
> I don't know any reason not to push this one too, but it's not time critical.
Some observations:
* macOS has a new release ever
On Tue, Jan 17, 2023 at 11:56:42AM -0800, Andres Freund wrote:
> > $(CF_PGP_TESTS) is missing from contrib/pgcrypto/meson.build
>
> Assume that's the false positive?
Yes
> > I also tried but failed to write something to warn if "meson test" was
> > run with a list of tests but without tmp_instal
Hi,
On 2023-01-17 11:35:09 -0600, Justin Pryzby wrote:
> The autoconf system runs all tap tests in t/*.pl, but meson requires
> enumerating them in ./meson.build.
Yes. It was a mistake that we ever used t/*.pl for make. For one, it means
that make can't control concurrency meaningfully, due to th
The autoconf system runs all tap tests in t/*.pl, but meson requires
enumerating them in ./meson.build.
This checks for and finds no missing tests in the current tree:
$ for pl in `find src contrib -path '*/t/*.pl'`; do base=${pl##*/};
dir=${pl%/*}; meson=${dir%/*}/meson.build; grep "$base" "$me
On Tue, Nov 22, 2022 at 04:57:44PM -0600, Justin Pryzby wrote:
> I shuffled my branch around and sending now the current "docs" patches,
> but I suppose this is waiting on the "convert CompilerWarnings task to
> meson" patch.
In case it's not, here's a version to do that now.
>From 59bbbce620fdf3c
On Mon, Nov 21, 2022 at 02:45:42PM -0800, Andres Freund wrote:
> On 2022-11-13 17:53:04 -0600, Justin Pryzby wrote:
> > > > From: Justin Pryzby
> > > > Date: Tue, 26 Jul 2022 20:30:02 -0500
> > > > Subject: [PATCH 6/8] cirrus/ccache: add explicit cache keys..
> > > >
> > > > Since otherwise, build
On Fri, 30 Dec 2022 at 09:29, Thomas Munro wrote:
>
> On Wed, Nov 23, 2022 at 11:57 AM Justin Pryzby wrote:
> > [PATCH 02/10] cirrus/macos: switch to "macos_instance" / M1..
>
> Duelling patches.
>
> Bilal's patch[1] uses the matrix feature to run the tests on both
> Intel and ARM, which made sen
On Wed, Nov 23, 2022 at 11:57 AM Justin Pryzby wrote:
> [PATCH 02/10] cirrus/macos: switch to "macos_instance" / M1..
Duelling patches.
Bilal's patch[1] uses the matrix feature to run the tests on both
Intel and ARM, which made sense when he proposed it, but according to
Cirrus CI warnings, the
[ resending to -hackers because of list issues ]
On 2022-05-28 Sa 11:37, Justin Pryzby wrote:
> I'm "joining" a bunch of unresolved threads hoping to present them better
> since
> they're related and I'm maintaining them together anyway.
>
> https://www.postgresql.org/message-id/flat/202202192341
On Mon, Nov 21, 2022 at 02:45:42PM -0800, Andres Freund wrote:
> > > > +ninja -C build |tee build/meson-logs/build.txt
> > > > +REM Since pipes lose exit status of the preceding command, rerun
> > > > compilation,
> > > > +REM without the pipe exiting now if it fails, rather than tryin
Hi,
On 2022-11-13 17:53:04 -0600, Justin Pryzby wrote:
> On Fri, Nov 04, 2022 at 06:59:46PM -0700, Andres Freund wrote:
> > > diff --git a/.cirrus.yml b/.cirrus.yml
> > > index 9f2282471a9..99ac09dc679 100644
> > > --- a/.cirrus.yml
> > > +++ b/.cirrus.yml
> > > @@ -451,12 +451,20 @@ task:
> > >
>
Hi,
On 2022-11-19 13:18:54 -0800, Andres Freund wrote:
> I'll try to repost a version of the ubsan/asan patch together with the
> sanitycheck patch and see how that looks.
I just pushed the prerequisite patch making UBSAN_OPTIONS work. Attached
is 1) addition of SanityCheck 2) use of asan and ubs
Hi,
On 2022-11-19 15:45:06 -0600, Justin Pryzby wrote:
> What do you mean "temporarily" ? I think you're implying that the
> Warnings task is fast but (at least right now) it is not.
In the sense that we don't need all CPUs until the whole commit has finished
testing (none of the tasks are the s
On Sat, Nov 19, 2022 at 01:18:54PM -0800, Andres Freund wrote:
> > Also, if CompilerWarnings doesn't depend on Linux, that means those two
> > tasks will normally start and run simultaneously, which means a single
> > branch will use all 8 of the linux CPUs available from cirrus. Is that
> > inten
Hi,
On 2022-11-19 13:18:54 -0800, Andres Freund wrote:
> > Also, if CompilerWarnings doesn't depend on Linux, that means those two
> > tasks will normally start and run simultaneously, which means a single
> > branch will use all 8 of the linux CPUs available from cirrus. Is that
> > intentional?
Hi,
On 2022-11-19 14:22:20 -0600, Justin Pryzby wrote:
> On Sun, Oct 02, 2022 at 01:52:01PM -0700, Andres Freund wrote:
> >
> > +# To avoid unnecessarily spinning up a lot of VMs / containers for entirely
> > +# broken commits, have a very minimal test that all others depend on.
> > +task:
> > +
On Sun, Oct 02, 2022 at 01:52:01PM -0700, Andres Freund wrote:
>
> +# To avoid unnecessarily spinning up a lot of VMs / containers for entirely
> +# broken commits, have a very minimal test that all others depend on.
> +task:
> + name: SanityCheck
Maybe this should be named 00-SanityCheck, so i
On Wed, Nov 16, 2022 at 08:08:32PM -0800, Andres Freund wrote:
> I also don't like my "cores_script". Not quite sure yet how to do that
> more cleanly.
I don't know which is cleaner:
ls /core* && mv /tmp/core* /tmp/cores
find / -maxdepth 1 -type f -name 'core*' -print0 |
xargs -r0 mv -vt
Hi,
On 2022-11-16 21:58:39 -0600, Justin Pryzby wrote:
> On Wed, Nov 16, 2022 at 07:48:14PM -0800, Andres Freund wrote:
> > I've used this a bunch on personal branches, and I think it's the way to
> > go. It doesn't take long, saves a lot of cycles when one pushes something
> > broken. Starts to r
On Wed, Nov 16, 2022 at 07:48:14PM -0800, Andres Freund wrote:
> I've used this a bunch on personal branches, and I think it's the way to
> go. It doesn't take long, saves a lot of cycles when one pushes something
> broken. Starts to runs the CompilerWarnings task after a minimal amount of
> sanity
Hi,
On 2022-10-02 14:54:21 -0700, Andres Freund wrote:
> On 2022-10-02 16:35:06 -0500, Justin Pryzby wrote:
> > On Sun, Oct 02, 2022 at 01:52:01PM -0700, Andres Freund wrote:
> > > On 2022-10-01 18:36:41 -0700, Andres Freund wrote:
> > > > I am wondering if we should instead introduce a new "quick
On Fri, Nov 04, 2022 at 06:59:46PM -0700, Andres Freund wrote:
> Hi,
>
> On 2022-11-04 18:54:12 -0500, Justin Pryzby wrote:
> > Subject: [PATCH 1/8] meson: PROVE is not required
> > Subject: [PATCH 3/8] meson: rename 'main' tasks to 'regress' and 'isolation'
>
> Pushed, thanks for the patches.
T
Hi,
On 2022-11-04 18:54:12 -0500, Justin Pryzby wrote:
> Subject: [PATCH 1/8] meson: PROVE is not required
> Subject: [PATCH 3/8] meson: rename 'main' tasks to 'regress' and 'isolation'
Pushed, thanks for the patches.
> Subject: [PATCH 2/8] meson: other fixes for cygwin
>
> XXX: what about HAVE
On Sat, Sep 10, 2022 at 03:05:42PM -0500, Justin Pryzby wrote:
> On Sun, Aug 28, 2022 at 02:28:02PM -0700, Andres Freund wrote:
> > On 2022-08-28 12:10:29 -0500, Justin Pryzby wrote:
> > > On Sun, Aug 28, 2022 at 09:07:52AM -0700, Andres Freund wrote:
> > > > > --- /dev/null
> > > > > +++ b/src/too
On Sun, Oct 02, 2022 at 02:54:21PM -0700, Andres Freund wrote:
> the clang-only memory sanitizer there (if it works on freebsd)...
Have you looked at this much ? I think it'll require a bunch of
exclusions, right ?
--
Justin
Hi,
On 2022-10-02 16:35:06 -0500, Justin Pryzby wrote:
> On Sun, Oct 02, 2022 at 01:52:01PM -0700, Andres Freund wrote:
> > On 2022-10-01 18:36:41 -0700, Andres Freund wrote:
> > > I am wondering if we should instead introduce a new "quickcheck" task that
> > > just compiles and runs maybe one tes
Hi,
On 2022-10-02 16:35:06 -0500, Justin Pryzby wrote:
> Maybe - that would avoid waiting 4 minutes for a windows instance to
> start in the (hopefully atypical) case of a patch that fails in 1-2
> minutes under linux/freebsd.
>
> If the patch were completely broken, the windows task would take ~
On Sun, Oct 02, 2022 at 01:52:01PM -0700, Andres Freund wrote:
> Hi,
>
> On 2022-10-01 18:36:41 -0700, Andres Freund wrote:
> > I am wondering if we should instead introduce a new "quickcheck" task that
> > just compiles and runs maybe one test and have *all* other tests depend on
> > that. Wasti
Hi,
On 2022-10-01 18:36:41 -0700, Andres Freund wrote:
> I am wondering if we should instead introduce a new "quickcheck" task that
> just compiles and runs maybe one test and have *all* other tests depend on
> that. Wasting a precious available windows instance to just fail to build or
> immedia
Hi,
On 2022-10-01 19:58:01 -0500, Justin Pryzby wrote:
> One other thing is that your -m32 changes caused the linux/meson task to
> take an additional 3+ minutes (total ~8). That's no issue, except that
> the Warnings task depends on the linux/mason task, and itself can take
> up to 15 minutes.
On Sat, Oct 01, 2022 at 05:45:01PM -0700, Andres Freund wrote:
> Hi,
>
> On 2022-09-10 15:05:42 -0500, Justin Pryzby wrote:
> > From 4ed5eb427de4508a4c3422e60891b45c8512814a Mon Sep 17 00:00:00 2001
> > From: Justin Pryzby
> > Date: Sun, 3 Apr 2022 00:10:20 -0500
> > Subject: [PATCH 03/23] cirrus
Hi,
On 2022-09-10 15:05:42 -0500, Justin Pryzby wrote:
> From 4ed5eb427de4508a4c3422e60891b45c8512814a Mon Sep 17 00:00:00 2001
> From: Justin Pryzby
> Date: Sun, 3 Apr 2022 00:10:20 -0500
> Subject: [PATCH 03/23] cirrus/ccache: disable compression and show stats
>
> Since v4.0, ccache enables z
On Fri, Sep 23, 2022 at 9:07 AM Justin Pryzby wrote:
> On Sun, Aug 28, 2022 at 02:28:02PM -0700, Andres Freund wrote:
> > > > > - # Workaround around performance issues due to 32KB block size
> > > > > - repartition_script: src/tools/ci/gcp_freebsd_repartition.sh
> > > > >create_user_script:
Hi,
On 2022-09-22 16:07:02 -0500, Justin Pryzby wrote:
> On Sun, Aug 28, 2022 at 02:28:02PM -0700, Andres Freund wrote:
> > > > > @@ -71,8 +69,6 @@ task:
> > > > > fingerprint_key: ccache/freebsd
> > > > > reupload_on_changes: true
> > > > >
> > > > > - # Workaround around performance i
On Sun, Aug 28, 2022 at 02:28:02PM -0700, Andres Freund wrote:
> > > > @@ -71,8 +69,6 @@ task:
> > > > fingerprint_key: ccache/freebsd
> > > > reupload_on_changes: true
> > > >
> > > > - # Workaround around performance issues due to 32KB block size
> > > > - repartition_script: src/tool
On Sun, Aug 28, 2022 at 02:28:02PM -0700, Andres Freund wrote:
> On 2022-08-28 12:10:29 -0500, Justin Pryzby wrote:
> > On Sun, Aug 28, 2022 at 09:07:52AM -0700, Andres Freund wrote:
> > > > --- /dev/null
> > > > +++ b/src/tools/ci/windows-compiler-warnings
> > >
> > > Wouldn't that be doable as so
Hi,
On 2022-08-28 12:10:29 -0500, Justin Pryzby wrote:
> On Sun, Aug 28, 2022 at 09:07:52AM -0700, Andres Freund wrote:
> > > --- /dev/null
> > > +++ b/src/tools/ci/windows-compiler-warnings
> >
> > Wouldn't that be doable as something like
> > sh -c 'if test -s file; then cat file;exit 1; fi"
> >
On Sun, Aug 28, 2022 at 09:07:52AM -0700, Andres Freund wrote:
> > --- /dev/null
> > +++ b/src/tools/ci/windows-compiler-warnings
>
> Wouldn't that be doable as something like
> sh -c 'if test -s file; then cat file;exit 1; fi"
> inside .cirrus.yml?
I had written it inline in a couple ways, like
Hi,
On 2022-08-28 09:44:47 -0500, Justin Pryzby wrote:
> On Sat, May 28, 2022 at 10:37:41AM -0500, Justin Pryzby wrote:
> > I'm anticipating the need to further re-arrange the patch set - it's not
> > clear
> > which patches should go first. Maybe some patches should be dropped in
> > favour
>
Resending with a problematic address removed...
On Sat, May 28, 2022 at 10:37:41AM -0500, Justin Pryzby wrote:
> I'm anticipating the need to further re-arrange the patch set - it's not clear
> which patches should go first. Maybe some patches should be dropped in favour
> of the meson project.
rebased on b6a5158f9 and 054325c5e
Also, cirrus/freebsd task can run 3x faster with more CPUs.
Subject: [PATCH 21/21] cirrus: run freebsd with more CPUs+RAM
[Resending -- sorry if you receive this twice. Jacob's mail server
has apparently offended the list management software so emails bounce
if he's in CC.]
On Fri, Jun 24, 2022 at 7:23 AM Justin Pryzby wrote:
> Freebsd uploads an artifact 3x smaller than the size ccache reports, because
> its ccach
On Sat, May 28, 2022 at 10:37:41AM -0500, Justin Pryzby wrote:
> I'm "joining" a bunch of unresolved threads hoping to present them better
> since
> they're related and I'm maintaining them together anyway.
This resolves an error with libpq tests in an intermediate commit, probably
caused by reba
I'm "joining" a bunch of unresolved threads hoping to present them better since
they're related and I'm maintaining them together anyway.
https://www.postgresql.org/message-id/flat/20220219234148.GC9008%40telsasoft.com
- set TESTDIR from perl rather than Makefile
https://www.postgresql.org/messag
76 matches
Mail list logo
