> On 24 Oct 2023, at 22:34, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> I went ahead and applied this on master, thanks for review! Now to see if
>> there will be any noticeable difference in resource usage.
>
> I think that tools like Coverity are likely to whine about your
> use of
Daniel Gustafsson writes:
> I went ahead and applied this on master, thanks for review! Now to see if
> there will be any noticeable difference in resource usage.
I think that tools like Coverity are likely to whine about your
use of sprintf instead of snprintf. Sure, it's perfectly safe,
but
> On 13 Sep 2023, at 01:49, Andres Freund wrote:
> My patch increased user/sys time a bit (likely due to a higher number of
> futile psql forks), but Daniel's doesn't. And it does show a nice overall wall
> clock time saving.
I went ahead and applied this on master, thanks for review! Now to
> On 13 Sep 2023, at 01:49, Andres Freund wrote:
> On 2023-08-30 10:57:10 +0200, Daniel Gustafsson wrote:
>>> On 28 Aug 2023, at 14:32, Daniel Gustafsson wrote:
>>
>>> Attached is a patch with a quick PoC for using PQPing instead of using psql
>>> for
>>> connection checks in pg_regress.
>>
Hi,
On 2023-08-30 10:57:10 +0200, Daniel Gustafsson wrote:
> > On 28 Aug 2023, at 14:32, Daniel Gustafsson wrote:
>
> > Attached is a patch with a quick PoC for using PQPing instead of using psql
> > for
> > connection checks in pg_regress.
>
> The attached v2 fixes a silly mistake which led
> On 28 Aug 2023, at 14:32, Daniel Gustafsson wrote:
> Attached is a patch with a quick PoC for using PQPing instead of using psql
> for
> connection checks in pg_regress.
The attached v2 fixes a silly mistake which led to a compiler warning.
--
Daniel Gustafsson
> On 23 Aug 2023, at 23:12, Daniel Gustafsson wrote:
>
>> On 23 Aug 2023, at 23:02, Tom Lane wrote:
>>
>> Daniel Gustafsson writes:
>>> On 23 Aug 2023, at 21:22, Andres Freund wrote:
I think there's more effective ways to make this cheaper. The basic thing
would be to use libpq
Hi,
On 2023-08-22 23:58:33 -0700, Andres Freund wrote:
> To make that possible, we need to make the compute resources for CI
> configurable on a per-repository basis. After experimenting with a bunch of
> ways to do that, I got stuck on that for a while. But since today we have
> sufficient
Hi,
On Thu, 24 Aug 2023 at 00:48, Andres Freund wrote:
> > v3-0008-ci-switch-tasks-to-debugoptimized-build.patch:
> > Just thinking of possible optimizations and thought can't we create
> > something like 'buildtype: xxx' to override default buildtype using
> > .cirrus.star? This could be better
On 24.08.23 00:56, Andres Freund wrote:
Hi,
On 2023-08-23 18:32:26 -0400, Tom Lane wrote:
Andres Freund writes:
There are other potential uses for libpq in pg_regress though - I'd e.g. like
to have a "monitoring" session open, which we could use to detect that the
server crashed (by waiting
Hi,
On 2023-08-23 18:32:26 -0400, Tom Lane wrote:
> Andres Freund writes:
> > There are other potential uses for libpq in pg_regress though - I'd e.g.
> > like
> > to have a "monitoring" session open, which we could use to detect that the
> > server crashed (by waiting for the FD to be become
Andres Freund writes:
> On 2023-08-23 17:55:53 -0400, Tom Lane wrote:
>> The trouble with that approach is that in "make installcheck", we
>> don't really want to assume we know what the installed libpq's default
>> connection parameters are. So we don't explicitly know where that
>> libpq will
Hi,
On 2023-08-23 17:55:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-08-23 17:02:51 -0400, Tom Lane wrote:
> >> ... unless we hit problems with, say, a different default port number or
> >> socket path compiled into one copy vs. the other? That seems like it's
> >> probably a
Andres Freund writes:
> On 2023-08-23 17:02:51 -0400, Tom Lane wrote:
>> ... unless we hit problems with, say, a different default port number or
>> socket path compiled into one copy vs. the other? That seems like it's
>> probably a "so don't do that" case, though.
> If we were to find such a
Hi,
On 2023-08-23 23:55:15 +0300, Nazir Bilal Yavuz wrote:
> On Wed, 23 Aug 2023 at 09:58, Andres Freund wrote:
> > I'm hoping to push this fairly soon, as I'll be on vacation the last week of
> > August. I'll be online intermittently though, if there are issues, I can
> > react
> > (very
Hi,
On 2023-08-23 17:02:51 -0400, Tom Lane wrote:
> Daniel Gustafsson writes:
> > On 23 Aug 2023, at 21:22, Andres Freund wrote:
> >> I think there's more effective ways to make this cheaper. The basic thing
> >> would be to use libpq instead of forking of psql to make a connection
> >> check.
> On 23 Aug 2023, at 23:02, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> On 23 Aug 2023, at 21:22, Andres Freund wrote:
>>> I think there's more effective ways to make this cheaper. The basic thing
>>> would be to use libpq instead of forking of psql to make a connection
>>> check.
>
>> I
Daniel Gustafsson writes:
> On 23 Aug 2023, at 21:22, Andres Freund wrote:
>> I think there's more effective ways to make this cheaper. The basic thing
>> would be to use libpq instead of forking of psql to make a connection
>> check.
> I had it in my head that not using libpq in pg_regress was
Hi,
Thanks for the patch!
On Wed, 23 Aug 2023 at 09:58, Andres Freund wrote:
> I'm hoping to push this fairly soon, as I'll be on vacation the last week of
> August. I'll be online intermittently though, if there are issues, I can react
> (very limited connectivity for middday Aug 29th - midday
> On 23 Aug 2023, at 21:22, Andres Freund wrote:
> On 2023-08-23 14:48:26 +0200, Daniel Gustafsson wrote:
>> I'll do another pass, but below are a few small comments so far.
>>
>> I don't know Windows to know the implications, but should the below file have
>> some sort of warning about not
Hi,
On 2023-08-23 14:48:26 +0200, Daniel Gustafsson wrote:
> > On 23 Aug 2023, at 08:58, Andres Freund wrote:
>
> > I'm hoping to push this fairly soon, as I'll be on vacation the last week of
> > August. I'll be online intermittently though, if there are issues, I can
> > react
> > (very
> On 23 Aug 2023, at 08:58, Andres Freund wrote:
> I'm hoping to push this fairly soon, as I'll be on vacation the last week of
> August. I'll be online intermittently though, if there are issues, I can react
> (very limited connectivity for middday Aug 29th - midday Aug 31th though). I'd
>
Hi,
On 2023-08-07 19:15:41 -0700, Andres Freund wrote:
> As some of you might have seen when running CI, cirrus-ci is restricting how
> much CI cycles everyone can use for free (announcement at [1]). This takes
> effect September 1st.
>
> This obviously has consequences both for individual users
On Tue, Aug 08, 2023 at 07:59:55PM -0700, Andres Freund wrote:
> On 2023-08-08 22:29:50 -0400, Robert Treat wrote:
> 3) using ~350 USD / mo in GCP costs for windows, linux, freebsd (*)
> > The other likely option would be to seek out cloud credits
> I tried to start that progress within
Hello
So pginfra had a little chat about this. Firstly, there's consensus
that it makes sense for pginfra to help out with some persistent workers
in our existing VM system; however there are some aspects that need
some further discussion, to avoid destabilizing the rest of the
infrastructure.
On Wed, Aug 9, 2023 at 3:26 AM Andres Freund wrote:
>
> > > 6) Disable write cache flushes on windows
> > >
> > > It's a bit ugly to do this without using the UI... Shaves off
> about 30s
> > > from the tests.
> >
> > A brief comment would be nice: "We don't care about persistence over
Hi,
On 2023-08-08 22:29:50 -0400, Robert Treat wrote:
> In case it's helpful, from an SPI oriented perspective, $7K/month is
> probably an order of magnitude more than what we can sustain, so I
> don't see a way to make that work without some kind of additional
> magic that includes other
On Tue, Aug 8, 2023 at 9:26 PM Andres Freund wrote:
>
> Hi,
>
> On 2023-08-08 11:58:25 +0300, Heikki Linnakangas wrote:
> > On 08/08/2023 05:15, Andres Freund wrote:
> > > With the improvements detailed below, cirrus' free CI would last
> > > about ~65 runs / month.
> >
> > I think that's plenty.
Hi,
On 2023-08-08 11:58:25 +0300, Heikki Linnakangas wrote:
> On 08/08/2023 05:15, Andres Freund wrote:
> > With the improvements detailed below, cirrus' free CI would last
> > about ~65 runs / month.
>
> I think that's plenty.
Not so sure, I would regularly exceed it, I think. But it definitely
Hi,
On 2023-08-08 18:34:58 +0200, Alvaro Herrera wrote:
> On 2023-Aug-08, Andres Freund wrote:
>
> > Given the cost of macos, it seems like it'd be by far the most of affordable
> > to just buy 1-2 mac minis (2x ~660USD) and stick them in a shelf somewhere,
> > as
> > persistent runners. Cirrus
On 2023-Aug-08, Andres Freund wrote:
> Given the cost of macos, it seems like it'd be by far the most of affordable
> to just buy 1-2 mac minis (2x ~660USD) and stick them in a shelf somewhere, as
> persistent runners. Cirrus has builtin macos virtualization support - but can
> only host two VMs
On Tue Aug 8, 2023 at 10:38 AM CDT, Andres Freund wrote:
Hi,
On 2023-08-08 10:25:52 -0500, Tristan Partin wrote:
> On Mon Aug 7, 2023 at 9:15 PM CDT, Andres Freund wrote:
> > FWIW: with the patches applied, the "credit costs" in cirrus CI are roughly
> > like the following (depends on caching
Hi,
On 2023-08-08 10:25:52 -0500, Tristan Partin wrote:
> On Mon Aug 7, 2023 at 9:15 PM CDT, Andres Freund wrote:
> > FWIW: with the patches applied, the "credit costs" in cirrus CI are roughly
> > like the following (depends on caching etc):
> >
> > task costs in credits
> > linux-sanity:
On Mon Aug 7, 2023 at 9:15 PM CDT, Andres Freund wrote:
FWIW: with the patches applied, the "credit costs" in cirrus CI are roughly
like the following (depends on caching etc):
task costs in credits
linux-sanity: 0.01
linux-compiler-warnings: 0.05
linux-meson: 0.07
Hi,
On 2023-08-08 16:28:49 +0200, Peter Eisentraut wrote:
> On 08.08.23 04:15, Andres Freund wrote:
> > Potential paths forward for cfbot, in addition to the above:
> >
> > - Pay for compute / ask the various cloud providers to grant us compute
> >credits. At least some of the cloud providers
On 08.08.23 04:15, Andres Freund wrote:
Potential paths forward for individual CI:
- migrate wholesale to another CI provider
- split CI tasks across different CI providers, rely on github et al
displaying the CI status for different platforms
- give up
With the proposed optimizations,
On 08/08/2023 05:15, Andres Freund wrote:
IMO, for the individual user case it's important to use CI for "free", without
a whole lot of complexity. Which imo rules approaches like providing
$cloud_provider compute accounts, that's too much setup work.
+1
With the improvements detailed below,
Hi,
On 2023-08-07 19:15:41 -0700, Andres Freund wrote:
> The set of free CI providers has shrunk since we chose cirrus, as have the
> "free" resources provided. I started, quite incomplete as of now, wiki page at
> [4].
Oops, as Thomas just noticed, I left off that link:
[4]
Hi,
As some of you might have seen when running CI, cirrus-ci is restricting how
much CI cycles everyone can use for free (announcement at [1]). This takes
effect September 1st.
This obviously has consequences both for individual users of CI as well as
cfbot.
The first thing I think we should
39 matches
Mail list logo
