mp and restore. This admittedly comes at the performance cost
of doing a catalog lookup, but there is precedent for this in
e.g. hashrange and hashtext.
I look forward to your feedback on this, thank you!
Sincerely,
Andrew J Repp (VMware)
v1-0001-Change-enum-hashing-to-consider-enumsortorder.patch
Description: Binary data
Those are excellent points.
We will investigate adjusting pg_dump behavior,
as this is primarily a dump+restore issue.
Thank you!
-Andrew J Repp (VMware)
On Tue, Jan 24, 2023, at 9:56 PM, Tom Lane wrote:
> Andrew writes:
> > I have discovered a bug in one usage of enums. If a table
:Spec->rel2abs(dirname($0));
is completely wrong for vpaths, since that will place it in the source
tree, not the build tree.
Last, and for no explained reason that I can see, the patch undoes
commit f4ce6c4d3a, but only for msvc builds. Even if that's justified it
appears to have no relev
t; Unless I'm missing something important here.
Looks OK. Now we require a sufficiently modern Test::More we could have
made it a subtest if necessary.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
;
I'm pretty sure all my Windows machines with buildfarm animals are
sufficiently modern except the XP machine, which only builds release 10
nowadays.
What's involved in moving to require Unix socket support?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
line 5.
> #
> # Failed test 'died: blorb at /tmp/die_pg_utils.pl line 5.
> # '
> # at /home/andres/src/postgresql/src/test/perl/PostgreSQL/Test/Utils.pm
> line 235.
> 1..2
> # Looks like your test exited with 25 just after 2.
>
>
> The latter output doesn't confuse with stuff about plans and exit codes. But
> contains redundant messages (whatever) and it doesn't seem particularly clean
> to hijack a "test number".
>
I'll be surprised if we can't come up with something cleaner than that.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2/22/22 15:54, Andres Freund wrote:
> On 2022-02-22 15:10:30 -0500, Andrew Dunstan wrote:
>> I'll be surprised if we can't come up with something cleaner than that.
> Suggestions?
If we just have the sig handler actions as:
diag("died: $_[0]");
done_
itbucket.org/adunstan/row_to_csv
Closed forms of discrete builtin ranges:
https://bitbucket.org/adunstan/pg-closed-ranges
FDW to generate random data:
https://bitbucket.org/adunstan/rotfang-fdw
Comparison ops for JSON:
https://bitbucket.org/adunstan/jsoncmp
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
tad smarter. Perhaps by lifting the
> code in src/bin/psql/command.c:do_edit() to src/port/path.c or such?
>
+1 for doing that.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2/23/22 11:40, Andres Freund wrote:
> Hi,
>
> On 2022-02-23 08:43:38 -0500, Andrew Dunstan wrote:
>> On 2/22/22 15:54, Andres Freund wrote:
>>> On 2022-02-22 15:10:30 -0500, Andrew Dunstan wrote:
>>>> I'll be surprised if we can't come up wit
n the regression
> suite. I see that libpq has an installcheck recipe that compiles a test
> executable for URI parsing; should I add a simple test alongside that?
Create a TAP tests that calls a small client?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
est, with the test in
> t/001_uri.pl. But we should at least get rid of the test/...
>
> Perhaps we should just rename src/test/modules/libpq_pipeline to
> src/test/modules/libpq and move uri-regress in there as well?
WFM
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2/23/22 16:16, Andres Freund wrote:
> Hi,
>
> On 2022-02-23 15:57:08 -0500, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 2/23/22 15:30, Andres Freund wrote:
>>>> Perhaps we should just rename src/test/modules/libpq_pipeline to
>>>> src/tes
e under src/interfaces/libpq/test/t,
> which isn't what you said. I have no great objection to moving
> src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
> though, as long as the buildfarm will cope.
>
>
It won't without some adjustment.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
to me material for release 16, so there's plenty
of time to get it right.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2/24/22 20:17, Justin Pryzby wrote:
> On Mon, Feb 21, 2022 at 07:00:54AM -0500, Andrew Dunstan wrote:
>> On 2/19/22 18:53, Justin Pryzby wrote:
>>> On Sat, Feb 19, 2022 at 05:41:49PM -0600, Justin Pryzby wrote:
>>>> I rebased and fixed the check-guc script to
ines they don't understand.
The Node TAP setup produces output like this, so perl is hardly alone
here. See <https://node-tap.org/docs/api/subtests/>
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2/25/22 11:41, Andres Freund wrote:
> Hi,
>
> On 2022-02-25 09:43:20 -0500, Andrew Dunstan wrote:
>> AIUI TAP consumers are supposed to ignore lines they don't understand.
> Are they?
>
> In http://testanything.org/tap-version-13-specification.html there'
On 2/25/22 19:27, Andres Freund wrote:
> Hi,
>
> Andrew, CCIng you both because you might be interested in the CI bit, and
> because you might know the answer.
>
>
>
>> 2- src/pl/plpython/Makefile looks under "C:/Windows/system32/" for
>> PYTHONDLL.
ssible. The installation of
libpq_pipeline.exe is apparently what has led Justin Pryzby to think
it's OK to undo the effect of commit f4ce6c4d3a on vcregress.pl.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
WFM. After all, it's taken several years for this to surface. Is it
based on actual field experience?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2/24/22 07:19, Andrew Dunstan wrote:
> On 2/23/22 20:52, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> On 23.02.22 23:58, Tom Lane wrote:
>>>> Peter Eisentraut writes:
>>>>> libpq TAP tests should be in src/interfaces/libpq/t/.
>>>>
ddle of a session. Maybe it should be an initdb option instead of a GUC?
>
>
So far my efforts have not borne fruit. Here's why:
andrew=# set sql_json = jsonb;
SET
andrew=# create table abc (x text, y json);
CREATE TABLE
andrew=# \d abc
Table "pub
On 3/1/22 16:41, Andrew Dunstan wrote:
> On 2/1/22 14:11,I wrote:
>> 2. The new GUC "sql_json" is a bit of a worry. I understand what it's
>> trying to do, but I'm trying to convince myself it's not going to be a
>> fruitful source of error
: 'C:\\prog\\python310',
'exec_prefix': 'C:\\prog\\python310',
'installed_base': 'C:\\prog\\python310',
'installed_platbase': 'C:\\prog\\python310',
'platbase': 'C:\\prog\\python310',
'platlibdir':
is right.
>
>
Yeah, I haven't found a way to make it stop doing that :-(
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
the impression nobody
> cares about this, otherwise it would've been included 5-10 years ago.
>
> Only 0001 should be reviewed for pg15 - the others are optional/future work.
I don't see why patch 5 shouldn't be applied forthwith.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/4/22 13:13, Erikjan Rijkers wrote:
> Op 04-03-2022 om 17:33 schreef Andrew Dunstan:
>>
>
>> This set of patches deals with items 1..7 above, but not yet the ERROR
>> ON ERROR issue. It also makes some message cleanups, but there is more
>> to come in that
missions services are needed to run a service as a user or such.
SeServiceLogonRight is what the user needs to run the service.
To manage it (e.g. stop or start it) they need some extra permissions,
see for example <http://get-carbon.org/Grant-ServicePermission.html>
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
such cases you
might want something like "required_auth=cert,scram-sha-256"? Or do we
need a way of specifying the combination?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
e might improve the buildfarm's testing
of upgraded indexes generally.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
>> Fixed that.
> Hm. Now crake failed in XversionUpgrade-REL9_2_STABLE-HEAD:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2022-03-08%2018%3A47%3A22
>
> except that the log doesn't actually indicate any problem? Andrew, any hint?
>
That was a snaf
On 3/6/22 17:33, Andres Freund wrote:
> Hi,
>
> On 2022-03-06 07:46:04 -0500, Andrew Dunstan wrote:
>> This is an area not currently touched by the buildfarm's cross version
>> upgrade testing, which basically compares a pre-upgrade and post-upgrade
>> dump of the
On 3/10/22 10:53, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/6/22 17:33, Andres Freund wrote:
>>> A sequence of
>>> pg_upgrade; amcheck; upgrade all extensions; amcheck;
>>> would make sense.
>> See
>> &l
On 2/9/22 08:22, Himanshu Upadhyaya wrote:
> On Wed, Feb 2, 2022 at 12:44 AM Andrew Dunstan wrote:
>>
>> rebased with some review comments attended to.
> I am in process of reviewing these patches, initially, have started
> with 0002-JSON_TABLE-v55.patch.
> Tested many
lp_db1;",Cursorpos:"NULL",File_location:"dropdb,
>> dbcommands.c:841",Application_name:"NULL",Backend_type:"client
>> backend",Leader_PID:"0",Query_id:"0"
> CSV format is well documented
> (https
', but that seems
like overkill to solve what is in effect a cosmetic problem.
Generally I think this is now in fairly good shape, I've played with it
and it seems to do what I expect in every case, and the things I found
surprising are gone.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/16/22 14:47, Tom Lane wrote:
> Andrew Dunstan writes:
>> Generally I think this is now in fairly good shape, I've played with it
>> and it seems to do what I expect in every case, and the things I found
>> surprising are gone.
> Stepping back a bit ... do we re
if we could get away with s/configuration parameter/setting/g in the docs.
>
>
I don't think we need to fix that here though. If you can live with
SETTING for now I will undertake to fix the docs post-feature-freeze if
necessary.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
I was just looking again at the grammar, and the only reason we need
this keyword at all AFAICS is to disambiguate ALL [PRIVILEGES] cases.
If we abandoned that for this form of GRANT/REVOKE I think we could
probably get away with
GRANT { SET | ALTER SYSTEM } ON setting_name ...
I haven't tried it, so I could be all wrong.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
> behavior without realizing we've done so. A refactoring of the core code
> might cause hooks to be called in a different order, something which isn't
> necessarily wrong, but should not be done unknowingly.
>
Yes, and in any case we've added test code after feature freeze in the past.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
e tests harder to follow, as
> we expect a root cert to *not* be set locally. Keeping the behavior
> documented in each individual string would be better, even if that
> duplicates more the keys in those final strings.
>
> Another thing that Horiguchi-san has pointed out upthread (?)
ity and
I'm happy to see us adopting something like it).
ISTM we should have a name that conveys that we are *converting* a
replica or equivalent to a subscriber.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
cuum ... FAILED 3463 ms
>>
>> I'll try to come up with the perl needed to see the regression.diffs
>> next time...
> Here's my proposed change to achieve that.
I think that's OK.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ange where compressing won't
> help anymore.
>
> And sure, any limit may be hit by somebody. But 1MB across the whole email
> seems pretty low these days.
>
Of course we could get complaints no matter what level we set the limit
at. I think raising it to 2Mb would be a reasonabl
that issue I think patch 1 is basically ok, but we should fix the
comments in objectaccess.c. Rather than "It is [the] entrypoint ..." we
should have something like "Oid variant entrypoint ..." and "Name
variant entrypoint ...", and also fix the function names in the comments.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/21/22 15:57, Mark Dilger wrote:
>> On Mar 18, 2022, at 3:04 PM, Andrew Dunstan wrote:
>>
>> I haven't looked at it in detail, but regarding the test code I'm not
>> sure why there's a .control file, since this isn't a loadable extension,
>&
01 has anything to do with that... Are you on a
> Mac? Did it look like this recent failure from CI?
Probably not connected. It's working fine for me on Ubuntu/
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
;
>
> We are waiting too :)
I'm planning on pushing the functions patch set this week and json-table
next week.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/21/22 19:08, Mark Dilger wrote:
>
>> On Mar 21, 2022, at 1:30 PM, Andrew Dunstan wrote:
>>
>> To the best of my knowledge .control files are only used by extensions,
>> not by other modules. They are only referenced in
>> src/backend/commands/extension.c
On 3/22/22 10:53, Alvaro Herrera wrote:
> On 2022-Mar-22, Andrew Dunstan wrote:
>
>> I'm planning on pushing the functions patch set this week and json-table
>> next week.
> I think it'd be a good idea to push the patches one by one and let a day
> between e
On 3/22/22 10:55, Daniel Gustafsson wrote:
>> On 22 Mar 2022, at 16:31, Andrew Dunstan wrote:
>> I'm planning on pushing the functions patch set this week and json-table
>> next week.
> My comments from 30827b3c-edf6-4d41-bbf1-298181874...@yesql.se are yet to be
> a
On 3/22/22 11:26, Mark Dilger wrote:
>
>> On Mar 22, 2022, at 8:14 AM, Julien Rouhaud wrote:
>>
>> Hi,
>>
>> On Tue, Mar 22, 2022 at 10:41:05AM -0400, Andrew Dunstan wrote:
>>> Pushed with slight adjustments - the LOAD was unnecessary as was the
>&
On 3/22/22 12:02, Tom Lane wrote:
> Andrew Dunstan writes:
>> That seems quite weird. I'm not sure how it's getting loaded at all if
>> not via shared_preload_libraries
> Some other animals are showing this:
>
> diff -U3
> /home/postgres/pgsql/src
I only suggested removing the error check in _PG_init, not
> changing the way the test works.
>
>
Mark and I discussed this offline, and decided there was no requirement
for the module to be preloaded. Do you have a different opinion?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/22/22 13:08, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/22/22 12:58, Tom Lane wrote:
>>> I only suggested removing the error check in _PG_init, not
>>> changing the way the test works.
>> Mark and I discussed this offline, and decided there was no re
On 3/22/22 14:01, Tom Lane wrote:
> Andrew Dunstan writes:
>> OK, I have pushed that.
> It seems like you could remove the NO_INSTALLCHECK restriction
> too. You already removed the comment defending it, and it
> seems to work fine as an installcheck now if I remove that
&g
On 3/22/22 11:27, Andrew Dunstan wrote:
> On 3/22/22 10:53, Alvaro Herrera wrote:
>> On 2022-Mar-22, Andrew Dunstan wrote:
>>
>>> I'm planning on pushing the functions patch set this week and json-table
>>> next week.
>> I think it'd be a good
On 3/5/22 09:39, Andrew Dunstan wrote:
>
> here's a new set of patches, omitting the GUC patch and with the
> beginnings of some message cleanup - there's more work to do there.
>
>
>
> This patchset restores the RETURNING clause for JSON() and JSON_SCALAR()
>
On 3/22/22 18:18, Tom Lane wrote:
> Andrew Dunstan writes:
>> Fixed
> Now that we got past the hard failures, we can see that the test
> falls over with (some?) non-default encodings, as for instance
> here:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=
trying to get work done.
> Please revert.
>
>
reverted.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/22/22 20:07, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/22/22 18:18, Tom Lane wrote:
>>> Now, if our attitude to the OAT hooks is that we are going to
>>> sprinkle some at random and whether they are useful is someone
>>> else's problem, then
er
(manual or buildfarm) users would be nice. Luckily crake isn't building
with ICU.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
o the Makefile shouldn't have an EXTENSION
entry, and there shouldn't be a .control file
. it doesn't need to be preloaded so there is no requirement for a
special config, nor for corresponding REGRESS_OPTS and NO_INSTALLCHECK
lines in the Makefile.
Here's a patch to fix those
On 3/22/22 20:11, Andrew Dunstan wrote:
> On 3/22/22 20:07, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 3/22/22 18:18, Tom Lane wrote:
>>>> Now, if our attitude to the OAT hooks is that we are going to
>>>> sprinkle some at random and whether they
ith CPPFLAGS=-DCOPY_PARSE_PLAN_TREES. To be on the
safe side I took ccache out of the equation.
Can you give me any more details?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/23/22 15:49, Andrew Dunstan wrote:
> On 3/23/22 08:24, Justin Pryzby wrote:
>> At least 0002-SQL-JSON-constructors-v64.patch has an issue with nodes,
>> per COPY_PARSE_PLAN_TREES.
>>
>> +ERROR: unrecognized node type: 157
>
>
> I just tried to repro
ture, and there will be no way to analyze such requests in a
> principled way.
>
>
>
Also, should this be an extension? I'm dubious about including such
marginal uses in the core code unless there's a really good case for it.
cheers
andrew
On 12/2/20 12:48 AM, Pavel Stehule wrote:
>
>
> st 2. 12. 2020 v 0:05 odesílatel Andrew Dunstan <mailto:and...@dunslane.net>> napsal:
>
>
> On 11/30/20 8:14 AM, Peter Eisentraut wrote:
> > On 2020-11-29 18:36, Pavel Stehule wrote:
> >>
&g
On 12/2/20 5:13 PM, Thomas Munro wrote:
>
> I'm experimenting with Github's built in CI. All other ideas welcome.
I'd look very closely at gitlab.
cheers
andrew
ase go ahead and move the remaining open patches, or
>> else re-open the CF if that's possible.
>>
>> regards, tom lane
>
> Oh, I wasn't aware of that. Thank you for the reminder.
>
> Now all patches are moved to the next CF.
>
Maybe this needs to be added to the instructions for CF managers so the
workflow is clear.
cheers
andrew
ou just have to push it to a branch there and look at the
> Actions tab on the web page for the results.
>
Awesome. That's a pretty big bang for the buck.
cheers
andrew
rhaps we should put one style or the other in a comment. I take Tom's
point, but after the number of bits shifted gets above some number I
have trouble remembering which bit it is, and while of course I can work
it out, it can be a very minor nuisance.
cheers
andrew
>
>
> note "now current_logfiles = $new_current_logfiles";
>
>
>
Oops, looks like that slipped off my radar somehow, I'll see about
backpatching it right away.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
aces, but only when I put together
> a pretty baroque procedure that involved using combinations of \gset,
> \o, and \!. All of the same things \gsetenv could do were doable with
> those, just less convenient, so I drafted up a patch in the hope that
> fewer others would find themselves jump
the buildfarm code, but then any TAP tests that want it will likewise
need to live there.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 12/17/20 7:55 PM, Michael Paquier wrote:
> On Thu, Dec 17, 2020 at 04:37:54PM -0500, Andrew Dunstan wrote:
>> The proposed module would look something like this:
>>
>> [...]
>>
>> use parent PostgresNode;
>>
>> sub get_new_node
>>
sking the OS in many cases will work, e.g. on my linux
machine:
ls -l /proc/{postmasterpid}/fd/1
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 12/19/20 11:19 AM, Andrew Dunstan wrote:
>
>
> This turns out to be remarkably short, with the use of a little eval magic.
>
> Give the attached, this test program works just fine:
>
> #!/bin/perl
> use PostgresNodePath;
> $ENV{PG_REGRESS} =
>
by not adding
non-strict deserialize opcodes to adjust_bailout; anyone have any
preferences?
--
Andrew (irc:RhodiumToad)
o an unlikely character like ^A, the escape
character to '\', and the delimiter to TAB, COPY in CSV mode will give
you something pretty close in many cases. Embedded newlines will still
give you trouble.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
it's past EOL.
It seems reasonable to want to institutionalize this knowledge. I'll see
if I can extract it into one or two perl scripts suitable for inclusion
in core code.
I'll try to fix the test for the latest breakage shortly.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 12/30/20 4:28 PM, Andrew Dunstan wrote:
>
> I'll try to fix the test for the latest breakage shortly.
See
<https://github.com/PGBuildFarm/client-code/commit/fa86d0b1bc7a8d7b9f15b1da8b8e43f4d3a08e2b>
I'm going to get a new release out before next Thursday come hell o
rongly to look for other solutions.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 1/4/21 11:15 AM, Isaac Morland wrote:
> On Mon, 4 Jan 2021 at 10:12, Andrew Dunstan <mailto:and...@dunslane.net>> wrote:
>
>
> On 1/1/21 11:44 AM, Tom Lane wrote:
> > Isaac Morland <mailto:isaac.morl...@gmail.com>> writes:
> >
containing binary files such as cryptographic keys?), but then it
> wouldn't accept ye olde context diffs.
>
>
I would try 'git apply' and fall back on 'patch' if it fails.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
re might be other environment settings needed - see drongo's config on the
buildfarm. LMK how you get on.
Constructing an image where you don't have to do that every build would be
super nice.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
l via "choco install patch". But unless you're developing
on Windows you would not need to bother about that at all. And if you
are developing on Windows, just produce your patches using "git diff" or
"git format-patch" just like on Unix.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 1/5/21 7:18 AM, Andrew Dunstan wrote:
> On 1/4/21 10:58 PM, Thomas Munro wrote:
>> Hi,
>>
>> My new favourite CI is Cirrus CI, because it has 4 operating systems,
>> generous enough quotas to handle 250+ branches in a single account,
>> and publi
t; be determined. at src/tools/msvc/Mkvcbuild.pm line 92.
>
> That's from https://cirrus-ci.com/task/5842523031601152. I guess PATH
> is wrong or nmake it not present, but it's so painful to do a test
> cycle that I gave up for today...
Hmm, weird. I'll play some more
On 1/6/21 12:36 AM, Andrew Dunstan wrote:
> On 1/5/21 11:19 PM, Thomas Munro wrote:
>> Thanks! I hacked on this a bit more and got as far as:
>>
>> C:\Users\ContainerAdministrator\AppData\Local\Temp\cirrus-ci-build>call
>> perl buildsetup.pl
>> Unable to
ey actually removed this less than a
month ago:
<https://github.com/cirruslabs/docker-images-windows/commit/6777ec66b76747a88f61252f9027f70d23fcc4ce>
I have identified the specific missing component as
Microsoft.VisualStudio.Component.VC.CLI.Support - I will submit a PR to
add it back in.
che
query?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
It's actually very easy, but it's something I usually reserve for people
who are very unresponsive to emails. As noted, disabling the crontab
entry on the client side is a preferable solution.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
speculating, but maybe there is a case for allowing running
a trigger as the table owner, as part of the trigger creation. Certainly
we're a very long way past the time when we could reasonably change the
default.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ere's an error. That's a major part of
the reason the buildfarm runs a much finer grained set of steps.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2/17/21 3:42 PM, Thomas Munro wrote:
> On Thu, Feb 18, 2021 at 9:18 AM Andrew Dunstan wrote:
>> On 2/17/21 11:06 AM, Tom Lane wrote:
>>> Peter Smith writes:
>>>> I saw that one of our commitfest entries (32/2914) is recently
>>>> reporting a fail
On 2/18/21 11:01 AM, Andrew Dunstan wrote:
> On 2/17/21 3:42 PM, Thomas Munro wrote:
>> On Thu, Feb 18, 2021 at 9:18 AM Andrew Dunstan wrote:
>>> On 2/17/21 11:06 AM, Tom Lane wrote:
>>>> Peter Smith writes:
>>>>> I saw that one of our commitfest en
On 2/21/21 9:28 PM, Thomas Munro wrote:
> On Sat, Feb 20, 2021 at 3:54 AM Andrew Dunstan wrote:
>> here's a very small and simple (and possibly naive) POC patch that
>> demonstrates this and seems to do the right thing.
> As a small variation that might be more paralle
On 2/21/21 10:34 PM, Andres Freund wrote:
> Hi,
>
> On 2021-02-17 15:18:02 -0500, Andrew Dunstan wrote:
>> yeah. The cfbot runs check-world which makes it difficult for it to know
>> which log files to show when there's an error. That's a major part of
>>
1 - 100 of 3317 matches
Mail list logo
