Re: set TESTDIR from perl rather than Makefile

: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

Re: Using Test::More test functions for pg_rewind

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

Re: making pg_regress less noisy by removing boilerplate

; 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

Re: bailing out in tap tests nearly always a bad idea

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

Re: bailing out in tap tests nearly always a bad idea

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_

Re: List of all* PostgreSQL EXTENSIONs in the world

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

Re: making pg_regress less noisy by removing boilerplate

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

Re: bailing out in tap tests nearly always a bad idea

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

Re: [PATCH] Enable SSL library detection via PQsslAttribute

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

Re: convert libpq uri-regress tests to tap test

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

Re: convert libpq uri-regress tests to tap test

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

Re: convert libpq uri-regress tests to tap test

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

Re: Proposal: Support custom authentication methods using hooks

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

Re: set TESTDIR from perl rather than Makefile

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

Re: Readd use of TAP subtests

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

Re: Readd use of TAP subtests

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'

Re: Mingw task for Cirrus CI

th python. So it might just be bitrot. There certainly was a time when python from python.org used to install its DLL in the system32 directory, so I imagine that's why it's there. I'm very glad to see that's no longer the case. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

MSVC build system installs extra executables

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

Re: Overflow of attmissingval is not handled gracefully

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

Re: convert libpq uri-regress tests to tap test

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/. >>>>

Re: SQL/JSON: functions

g. This is certainly severable from the rest of these patches. I'm not sure how severable it is from the SQL/JSON Table patches. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

Re: SQL/JSON: functions

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

Re: Mingw task for Cirrus CI

: 'C:\\prog\\python310',  'exec_prefix': 'C:\\prog\\python310',  'installed_base': 'C:\\prog\\python310',  'installed_platbase': 'C:\\prog\\python310',  'platbase': 'C:\\prog\\python310',  'platlibdir': 

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

is right. > > Yeah, I haven't found a way to make it stop doing that :-( cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

Re: wal_compression=zstd

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

Re: SQL/JSON: JSON_TABLE

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

Re: Regression tests failures on Windows Server 2019 - on master at commit # d816f366b

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

Re: [PoC] Let libpq reject unexpected authentication requests

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

Re: ltree_gist indexes broken after pg_upgrade from 12 to 13

e might improve the buildfarm's testing of upgraded indexes generally. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

Re: Time to drop plpython2?

u on my part, as I was adding extension upgrade / amcheck testing. It's fixed now, so please disregard this one. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

Re: ltree_gist indexes broken after pg_upgrade from 12 to 13

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

Re: ltree_gist indexes broken after pg_upgrade from 12 to 13

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

Re: SQL/JSON: JSON_TABLE

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

Re: Change the csv log to 'key:value' to facilitate the user to understanding and processing of logs

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

Re: Granting SET and ALTER SYSTE privileges for GUCs

', 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

Re: Granting SET and ALTER SYSTE privileges for GUCs

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

Re: Granting SET and ALTER SYSTE privileges for GUCs

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

Re: Granting SET and ALTER SYSTE privileges for GUCs

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

Re: New Object Access Type hooks

> 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

Re: Out-of-tree certificate interferes ssltest

is 003, > where it is also possible to trigger failures once the environment is > hijacked. The attached allows the full test suite to pass without > issues on my side. LGTM cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

Re: speed up a logical replica setup

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

Re: A test for replay of regression tests

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

Re: Problem with moderation of messages with patched attached.

e experiment. If no observable evil ensues then leave it that way. If it does then roll it back. I agree that plain uncompressed patches are easier to deal with in general. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

Re: New Object Access Type hooks

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

Re: New Object Access Type hooks

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, >&

Re: New Object Access Type hooks

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

Re: SQL/JSON: JSON_TABLE

; > > 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

Re: New Object Access Type hooks

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

Re: SQL/JSON: JSON_TABLE

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

Re: SQL/JSON: JSON_TABLE

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

Re: New Object Access Type hooks

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 >&

Re: New Object Access Type hooks

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

Re: New Object Access Type hooks

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

Re: New Object Access Type hooks

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

Re: New Object Access Type hooks

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

Re: SQL/JSON: JSON_TABLE

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

Re: SQL/JSON: functions

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() >

Re: New Object Access Type hooks

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=

Re: SQL/JSON: functions

trying to get work done. > Please revert. > > reverted. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

Re: New Object Access Type hooks

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

Re: cpluspluscheck vs ICU

er (manual or buildfarm) users would be nice. Luckily crake isn't building with ICU. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

clean up test_rls_hooks module

things. cheers andrew [1] https://postgr.es/m/47f87a0e-c0e5-43a6-89f6-d403f2b45...@enterprisedb.com -- Andrew Dunstan EDB: https://www.enterprisedb.com From 21f316d29881c3294f8d0b1bc2f0dde8eec38c2d Mon Sep 17 00:00:00 2001 From: Andrew Dunstan Date: Wed, 23 Mar 2022 08:49:07 -0400 Subject: [

Re: New Object Access Type hooks

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

Re: SQL/JSON: functions

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

Re: SQL/JSON: functions

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

Re: proposal: unescape_text function

On 11/30/20 8:14 AM, Peter Eisentraut wrote: > On 2020-11-29 18:36, Pavel Stehule wrote: >> >>     I don't really get the point of this function.  There is AFAICT no >>     function to produce this escaped format, and it's not a recognized >>     interchange format.  So under what circumstances w

Re: proposal: unescape_text function

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

Re: Commitfest 2020-11 is closed

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

Re: Commitfest 2020-11 is closed

On 12/3/20 4:54 AM, Anastasia Lubennikova wrote: > On 02.12.2020 23:59, Tom Lane wrote: >> Anastasia Lubennikova writes: >>> Commitfest 2020-11 is officially closed now. >>> Many thanks to everyone who participated by posting patches, reviewing >>> them, committing and sharing ideas in discussio

Re: Github Actions (CI)

On 12/3/20 1:33 AM, Thomas Munro wrote: > Hi hackers, > > I'm looking for more horsepower for testing commitfest entries > automatically, and today I tried out $SUBJECT. The attached is a > rudimentary first attempt, for show-and-tell. If you have a Github > account, you just have to push it to

Re: Change definitions of bitmap flags to bit-shifting style

On 12/6/20 11:44 AM, James Coleman wrote: > On Sun, Dec 6, 2020 at 1:25 AM Michael Paquier > wrote: > > On Sat, Dec 05, 2020 at 10:31:09PM -0300, Alvaro Herrera wrote: > > The hexadecimal representation is more natural to me than > bit-shifting, > > so

Re: TAP tests aren't using the magic words for Windows file access

  > >     > 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

Re: \gsetenv

ing through the hoops I did to > get that set up. Does this help? andrew=# select 'abc'::text as foo \gset andrew=# \setenv FOO :foo andrew=# \! echo $FOO abc andrew=# cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

multi-install PostgresNode

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

Re: multi-install PostgresNode

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 >>

Re: how to find log

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

Re: multi-install PostgresNode

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} = >

Re: proposal - support tsv output format for psql

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

Re: Buildfarm's cross-version-upgrade tests

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

Re: Buildfarm's cross-version-upgrade tests

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

Re: Safety/validity of resetting permissions by updating system tables

rongly to look for other solutions. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

Re: Safety/validity of resetting permissions by updating system tables

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: > >

Re: Context diffs

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: Cirrus CI (Windows help wanted)

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

Re: Context diffs

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

Re: Cirrus CI (Windows help wanted)

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

Re: Cirrus CI (Windows help wanted)

tomorrow and see what I can find. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

Re: Cirrus CI (Windows help wanted)

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

Re: Cirrus CI (Windows help wanted)

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

Re: WIP: System Versioned Temporal Table

query? cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

Re: PG vs LLVM 12 on seawasp, next round

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

Re: Trigger execution role

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

Re: Finding cause of test fails on the cfbot site

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

Re: Finding cause of test fails on the cfbot site

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

Re: Finding cause of test fails on the cfbot site

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

Re: Finding cause of test fails on the cfbot site

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

Re: Finding cause of test fails on the cfbot site

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 >>

Re: Allow matching whole DN from a client certificate

On 2/26/21 2:55 PM, Jacob Champion wrote: > On Sat, 2021-01-30 at 16:18 -0500, Andrew Dunstan wrote: >> Making incremental additions to the certificate set easier wouldn't be a >> bad thing. >> >> I wonder if we should really be setting 1 as the serial number, t

Re: Why does the BF sometimes not dump regression.diffs?

hine I control runs from a git checkout, which clearly is later than REL_11 even though that's what the version string says. Commit 13d2143 fixed this. It was included in Release 12. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

Re: buildfarm windows checks / tap tests on windows

somewhat less painful. +1 > > > This makes it even clearer to me that we really need a builtin > testrunner that runs tests efficiently *and* debuggable on windows. > "show me the code" :-) cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

  1   2   3   4   5   6   7   8   9   10   >