On 2023-04-09 Su 08:39, Thomas Munro wrote:
On Sun, Apr 9, 2023 at 11:25 PM Andrew Dunstan wrote:
Didn't seem to make any difference.
Thanks for testing. I think it's COW (and I think that implies also
checksums?) that needs to be turned off, at least based on experiments
here.
On 2023-04-09 Su 09:14, Andrew Dunstan wrote:
On 2023-04-09 Su 08:39, Thomas Munro wrote:
On Sun, Apr 9, 2023 at 11:25 PM Andrew Dunstan wrote:
Didn't seem to make any difference.
Thanks for testing. I think it's COW (and I think that implies also
checksums?) that needs to be
ripts directory). Don't use chocolatey to install meson/ninja - I ran
into issues doing that.
AFAICT meson will use whatever version of VC you have installed,
although I have only been testing with VC2019.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-04-04 Tu 08:22, Andrew Dunstan wrote:
On 2023-04-03 Mo 21:15, Andres Freund wrote:
Hi,
Looks like fairywren is possibly seeing something I saw before and spent many
days looking into:
https://postgr.es/m/20220909235836.lz3igxtkcjb5w7zb%40awork3.anarazel.de
which led me to add the
it's worth replacing "user" with "system_user"? It
is also a keyword but is a less likely choice for the OS user name.
I don't think we can protect against all possible user names. Wouldn't
it be better to run the tests under an OS user with a different name,
like "marmaduke"? ("user" is a truly terrible default user name).
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
tself. And the Fcntl
eval trick that I copied from File::stat, and the perl-critic
suppression that requires?
I think you can probably replace a lot of the magic here by simply saying
if (Fcntl->can("O_DIRECT")) ...
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-04-12 We 10:23, Dagfinn Ilmari Mannsåker wrote:
Andrew Dunstan writes:
On 2023-04-12 We 01:48, Thomas Munro wrote:
On Wed, Apr 12, 2023 at 3:04 PM Thomas Munro wrote:
On Wed, Apr 12, 2023 at 2:56 PM Christoph Berg wrote:
I'm hitting a panic in t_004_io_direct. The bui
nciple.
I agree with you that parsing the pid file shouldn't be hard or
unreasonable.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-04-12 We 12:38, Dagfinn Ilmari Mannsåker wrote:
Andrew Dunstan writes:
On 2023-04-12 We 10:23, Dagfinn Ilmari Mannsåker wrote:
Andrew Dunstan writes:
On 2023-04-12 We 01:48, Thomas Munro wrote:
On Wed, Apr 12, 2023 at 3:04 PM Thomas Munrowrote:
On Wed, Apr 12, 2023 at 2
rew, what's the policy on that?
update_personality.pl lets you update the OS version / compiler version
/ owner-name / owner-email
I am in fact about to perform this exact operation for prion.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
> On Apr 16, 2023, at 12:16 PM, Tom Lane wrote:
>
> Andrew Dunstan writes:
>>> On 2023-04-16 Su 10:18, Tom Lane wrote:
>>> Actually, as long as it's still OpenBSD I think you can keep using
>>> the same animal name ... Andrew, what's the policy
On 2023-04-20 Th 14:12, Peter Geoghegan wrote:
On Thu, Apr 20, 2023 at 10:56 AM Pavel Borisov wrote:
It's much deserved! Congratulations, Nathan, Amit and Masahiko!
Congratulations to all three!
+3
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
ase.
Perhaps we should start with a buildfarm module, which would run
pg_indent --show-diff. That would only need to run on one animal, so a
failure wouldn't send the whole buildfarm red. This would be pretty easy
to do.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-04-22 Sa 08:47, Magnus Hagander wrote:
On Sat, Apr 22, 2023 at 1:42 PM Andrew Dunstan wrote:
On 2023-04-22 Sa 04:50, Michael Paquier wrote:
On Fri, Apr 21, 2023 at 09:58:17AM +0200, Jelte Fennema wrote:
For 2 the upstream thread listed two approaches:
a. Install a pre-receive git
th an example patch
upthread at
<https://www.postgresql.org/message-id/47011581-ddec-1a87-6828-6edfabe6b7b6%40dunslane.net>
I still think that's worth doing.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-04-22 Sa 11:37, Tom Lane wrote:
Andrew Dunstan writes:
On 2023-04-22 Sa 10:39, Tom Lane wrote:
Another obstacle in the way of (1) is that there was some discussion
of changing perltidy version and/or options. But I don't believe
we have a final proposal on that, much less comm
On 2023-04-22 Sa 15:58, Tom Lane wrote:
Andrew Dunstan writes:
On 2023-04-22 Sa 11:37, Tom Lane wrote:
* I see that there's now a 20230309 release, should we consider that
instead?
A test I just ran gave identical results to those from 20221112
Cool, let's use perltidy 202
possibly
spew thousands of diff lines to the terminal.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
end.
I don't think we actually have a rule about it, but the pattern I
described doesn't seem unreasonable.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
opped
It seems more than odd that we get to where the "server stopped" massage
is printed but we get a failure.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-04-26 We 11:30, Tom Lane wrote:
Andrew Dunstan writes:
If I redirect the output to a file (which is what the buildfarm client
actually does), it seems like it completes successfully, but I still get
a non-zero exit:
pgrunner@EC2AMAZ-GCB871B UCRT64 ~/bf
$ /usr/bin/perl -e 'chdir
1, 1,
1, 2, 1,
1, 3, 3, 1,
1, 4, 6, 4, 1,);
#>>>
But that gets old and ugly pretty quickly.
There is a --freeze-newlines option, but it's global. I don't think we
want that.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-04-28 Fr 05:25, Alvaro Herrera wrote:
On 2023-Feb-05, Andrew Dunstan wrote:
So here's a diff made from running perltidy v20221112 with the additional
setting --valign-exclusion-list=", = => || && if unless"
I ran this experimentally with perltidy 20230309,
On 2023-04-28 Fr 14:08, Bruce Momjian wrote:
On Wed, Apr 26, 2023 at 03:44:47PM -0400, Andrew Dunstan wrote:
On 2023-04-26 We 09:27, Tom Lane wrote:
I doubt there's something like that. You can freeze arbitrary blocks of code
like this (from the manual)
#<<< format skippi
On 2023-04-27 Th 18:18, Andres Freund wrote:
Hi,
On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
Still running into this, and I am rather stumped. This is a blocker for
buildfarm support for meson:
Here's a simple illustration of the problem. If I do the identical test with
a non-
On 2023-05-03 We 09:20, Andrew Dunstan wrote:
On 2023-04-27 Th 18:18, Andres Freund wrote:
Hi,
On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
Still running into this, and I am rather stumped. This is a blocker for
buildfarm support for meson:
Here's a simple illustration o
On 2023-05-03 We 14:26, Andres Freund wrote:
Hi,
On 2023-05-03 09:20:28 -0400, Andrew Dunstan wrote:
On 2023-04-27 Th 18:18, Andres Freund wrote:
Hi,
On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
Still running into this, and I am rather stumped. This is a blocker for
buildfarm
On 2023-05-04 Th 02:40, Peter Eisentraut wrote:
On 25.04.23 12:27, Peter Eisentraut wrote:
On 20.11.22 16:10, Andrew Dunstan wrote:
On 2022-11-19 Sa 15:16, Andres Freund wrote:
Hi,
On 2022-11-19 10:56:33 -0500, Andrew Dunstan wrote:
Perhaps we should just export a directory in configure
On 2023-05-04 Th 19:54, Andres Freund wrote:
Hi,
On 2023-05-03 09:20:28 -0400, Andrew Dunstan wrote:
On 2023-04-27 Th 18:18, Andres Freund wrote:
On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
Still running into this, and I am rather stumped. This is a blocker for
buildfarm support for
al(), which tells you how many
bytes it has written?
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
g at Microsoft could arrange such a beast for me to set
up potential buildfarm animal, or else run one themselves.)
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
examples have been seen in the wild.
So I don't think our behaviour is broken or needs fixing. As mentioned
by Greg, this is an example of the adage about being liberal in what you
accept.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-05-13 Sa 04:20, Joel Jacobson wrote:
On Fri, May 12, 2023, at 21:57, Andrew Dunstan wrote:
Maybe this is unexpected by you, but it's not by me. What other sane
interpretation of that data could there be? And what CSV producer
outputs such horrible content? As you've n
On 2023-05-13 Sa 23:11, Greg Stark wrote:
On Sat, 13 May 2023 at 09:46, Tom Lane wrote:
Andrew Dunstan writes:
I could see an argument for a STRICT mode which would disallow partially
quoted fields, although I'd like some evidence that we're dealing with a
real problem here. Is th
On 3/24/22 12:49, Mark Dilger wrote:
>
>> On Mar 17, 2022, at 8:41 AM, Andrew Dunstan wrote:
>>
>> If we abandoned that for this form of GRANT/REVOKE I think we could
>> probably get away with
>>
>>
>> GRANT { SET | ALTER SYSTEM } ON setting_nam
occurs, along the lines of this fragment for nodeFuncs.c. Thoughts?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/src/backend/nodes/nodeFuncs.c b/src/backend/nodes/nodeFuncs.c
index 6f6a1f4ffc..675789d104 100644
--- a/src/backend/nodes/nodeFuncs.c
+++ b/src/backend
On 3/24/22 16:10, Tom Lane wrote:
> Andrew Dunstan writes:
>> As I was tracking down some of these errors in the sql/json patches I
>> noticed that we have a whole lot of them in the code, so working out
>> which one has triggered an error is not as easy as it might
user attempting create (subId=0) [explicit]
>
>
> I don't think this is meson specific...
Even if you use NO_LOCALE=1/ENCODING=UTF8 as the Makefile now does?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
tput.
Duplication of TAP test names has long been something that's annoyed me.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/26/22 07:29, Erik Rijkers wrote:
> Op 25-03-2022 om 21:30 schreef Andrew Dunstan:
>>
>> 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 wee
,
>
> https://cygwin.org/cygwin-ug-net/using-cygwinenv.html
> says "The filename of the executing program and it's Windows process id are
> appended to the command as arguments. "
>
> but nothing about %1 and %2 :(. I those are just "executing program" and
> "Windows process id" respectively?
I don't remember where I got this invocation from. But see for example
<https://stackoverflow.com/questions/320001/using-a-stackdump-from-cygwin-executable>
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/26/22 17:19, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/26/22 15:49, Andres Freund wrote:
>>> One interesting bit in the config is:
>>> [ lack of ]
>>> 'update_process_title = off'
>> I'd forgotten about that. Let me do that fo
s. It
could be left with any old junk. And maybe there's a good case for also
surrounding some of the code in WaitOnLock() with "if (len) ..."
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
e adjust that animal's config.
>
Done.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/24/22 18:54, Andrew Dunstan wrote:
> On 3/5/22 09:35, Andrew Dunstan wrote:
>> On 3/4/22 15:05, Andrew Dunstan wrote:
>>> On 3/4/22 13:13, Erikjan Rijkers wrote:
>>>> Op 04-03-2022 om 17:33 schreef Andrew Dunstan:
>>>>> This set of patches deals
> On Mar 27, 2022, at 7:14 PM, Tom Lane wrote:
>
> I wrote:
>>> Andres Freund writes:
There's also
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jabiru&dt=2022-03-22%2022%3A25%3A26
that started failing with
../../preproc/ecpg --regression -I./../../include -I. -
On 3/27/22 20:50, Andres Freund wrote:
> Hi,
>
> On 2022-03-27 20:21:05 -0400, Andrew Dunstan wrote:
>> Very odd. How did it pick up just this commit and not the following one
>> which was pushed at the same time?
> The first recent failing run was with
> f4fb45d15c S
rd to see how this could be caused by the OS environment. Maybe a
flaky bison/flex? I'm going to be pretty reluctant to revert this based
on this error.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/28/22 09:35, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/27/22 19:14, Tom Lane wrote:
>>> What's worse, I'm unable to replicate the failure on an OpenBSD 7.0
>>> system here. So there's something odd about jabiru's build
>>> e
openbsd7/clang11 instances Tom and I have just
successfully tested on. In the last resort we might need to run ecpg
under a debugger on jabiru to see why it's failing there and not
elsewhere. To set up for that run the buildfarm script with --keepall.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/28/22 14:31, Nikola Ivanov wrote:
> Hi Andreas,
>
> Archive with the files is attached.
That didn't help, there are no differences that matter (just #line
directives as I did a vpath build). :-(
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/28/22 15:48, Greg Stark wrote:
> FYI I think the patch failure in the cfbot is spurious because the
> cfbot got confused by Erik's patch.
The cfbot is likely to be confused until I am finished committing the
SQL/JSON patches. Just disregard it.
cheers
andrew
--
Andrew
can have that discussion that before the next CF, but still after
> code-freeze & immediate mopup.
>
I'd like to get a stake in the ground and then start working on
buildfarm support. Up to now I think it's been a bit too much of a
moving target. Essentially that would mean
> On Mar 28, 2022, at 7:25 PM, Tom Lane wrote:
>
> ... even more baffling: jabiru went green after the IS JSON patch.
>
>
Yeah, bizarre. Let’s see if I can upset that tomorrow with the next patch :-)
cheers
andrew
On 1/21/22 09:59, Andrew Dunstan wrote:
> On 1/21/22 02:47, Michael Paquier wrote:
>> On Tue, Jan 18, 2022 at 06:35:39PM -0500, Andrew Dunstan wrote:
>>> Here's a version that does that and removes some recent bitrot.
>> I have been looking at the full set of f
ivalent of 'cat /dev/tty'. So it's not at all surprising
that it hangs. I don't know of a Windows builtin that is equivalent to cat.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
le bleah. If we have to do that at least we should probably use
`gzip --fast`
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
test
>> script.
> Oh, that must be some non-standard output handling that our test setup
> does. Plain `prove` shows everything on stdout and stderr in verbose
> mode, and only stderr in non-vebose mode:
>
Yes, PostgreSQL::Test::Utils hijacks STDOUT and STDERR (see the INIT
block).
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
missions lookup in the default SET code path seems like
> a pretty important benefit, too. If we force that to happen
> it's going to be a noticeable drag on functions with SET clauses.
>
>
The last point is telling, so +1
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/30/22 01:55, Michael Paquier wrote:
> On Tue, Mar 29, 2022 at 05:56:02PM -0400, Andrew Dunstan wrote:
>> I'm not sure why this item has been moved to the next CF without any
>> discussion I could see on the mailing list. It was always my intention
>> to commit it t
routines.
So -1 on patch 1. I will fix the typo.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
are the settings I'm using in the config's
build_env section:
PG_TEST_USE_UNIX_SOCKETS => 1,
PG_REGRESS_SOCK_DIR =>
'C:/Users/pgrunner/AppData/Local/Temp',
We should probably fix the test though, so it doesn't require Unix
sockets. It should be possible, although I haven't looked yet to see how.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/31/22 11:32, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Mar 31, 2022 at 10:52 AM Andrew Dunstan wrote:
>>> We should probably fix the test though, so it doesn't require Unix
>>> sockets. It should be possible, although I haven't looked yet to
o be done today.
>
> The buildfarm does look rather green at the moment, though, so I'm not
> sure how I know whether this "worked".
You should know when jacana reports next (in the next hour or three), as
it's not set up for Unix sockets.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ut not until after feature freeze.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
orting on SLES
12 (and the one we did have was on s390x, if that matters).
So if this is something that needs support we should address that. After
all, that's exactly what the buildfarm was created for.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
_TABLE patches before feature
freeze (April 7). They depend on this set.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
> On Mar 31, 2022, at 4:47 PM, Greg Stark wrote:
>
> So the last commitfest often runs over and "feature freeze" isn't
> scheduled until April 7. Do committers want to keep the commitfest
> open until then? Or close it now and focus it only on a few pending
> features they're already working
eSQL/Test/SimpleTee.pm. The simplest thing would
just be to add a timestamp, the other things would involve a bit more
bookkeeping. It should also be checked to make sure it doesn't add too
much overhead, although I would be surprised if it did.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/1/22 15:16, Andrew Dunstan wrote:
> On 4/1/22 13:44, Nathan Bossart wrote:
>> On Fri, Apr 01, 2022 at 10:21:50AM -0700, Andres Freund wrote:
>>> right now I am looking at a test added in the shmstats patch that's slow on
>>> CI, on windows only. Unfortuna
On 4/1/22 16:25, Andrew Dunstan wrote:
> On 4/1/22 15:16, Andrew Dunstan wrote:
>> On 4/1/22 13:44, Nathan Bossart wrote:
>>> On Fri, Apr 01, 2022 at 10:21:50AM -0700, Andres Freund wrote:
>>>> right now I am looking at a test added in the shmstats patch that'
sability.
Hmm. Thanks for the report. The code in json_unique_check_key() looks
sane enough., so the issue is probably elsewhere. I'll keep digging.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/2/22 15:40, Andrew Dunstan wrote:
> On 4/2/22 01:25, Jaime Casanova wrote:
>> I got a crash running the below query on the regression database:
>>
>> """
>> select pg_catalog.json_object_agg_unique(10,
>> cast(ref_0.level2_no as
On 4/3/22 20:11, Andres Freund wrote:
> Hi,
>
> On 2022-04-03 18:56:39 -0400, Andrew Dunstan wrote:
>> Haven't found the issue yet :-( It happens on the second call for the
>> partition to json_check_unique_key().
>>
>> Here's a more idiomatic and sel
On 4/3/22 22:46, Andrew Dunstan wrote:
> On 4/3/22 20:11, Andres Freund wrote:
>> Hi,
>>
>> On 2022-04-03 18:56:39 -0400, Andrew Dunstan wrote:
>>> Haven't found the issue yet :-( It happens on the second call for the
>>> partition to json_check_uniqu
ds some rework.
ISTM that it might be a whole lot simpler and comprehensible to generate
the json first without bothering about null values or duplicate keys and
then in the finalizer check for null values to be skipped and duplicate
keys. That way we would need to keep far less s
On 4/4/22 11:43, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 4/3/22 22:46, Andrew Dunstan wrote:
>>> On 4/3/22 20:11, Andres Freund wrote:
>>>> I don't think you're allowed to free stuff in a finalfunc - we might reuse
>>>> the
>
7;t think
> pg_parameter_acl OIDs have any outside use; we wouldn't even have
> them except that we need a way to track their role dependencies
> in pg_shdepend. AFAICS users will only ever be interested in
> looking up a GUC by name. Any objections?
Not from
y.
>>
>> The latter can be caught by wal_consistency_checking - but that's pretty
>> expensive.
>>
>> It seems $subject would have a chance of catching some of these bugs, as well
>> as exposing amcheck to a database with a bit more varied content?
> I thought that Andre
an item he wants to do right at the end of
feature freeze.
The script looks fine, needs a copyright notice and a comment at the top
describing what it does. It seems like something we might need to do
from time to time, as it will be easy to forget to mark variables and we
should periodically run this as a check.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
section. Given that,
there should be no need to specify a --host= setting for configure.
If it's not done already, the shebang line in
/ucrt64/bin/core_perl/prove needs to be modified to use /ucrt64/bin/perl.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/5/22 22:21, Andres Freund wrote:
> Hi,
>
> On 2022-03-27 16:53:57 -0400, Andrew Dunstan wrote:
>> I'm therefore going to commit this series
> The new jsonb_sqljson test is, on my machine, the slowest test in the main
> regression tests:
>
> 4639 ms jsonb_sqlj
On 4/6/22 09:20, Andrew Dunstan wrote:
> On 4/5/22 22:21, Andres Freund wrote:
>> Hi,
>>
>> On 2022-03-27 16:53:57 -0400, Andrew Dunstan wrote:
>>> I'm therefore going to commit this series
>> The new jsonb_sqljson test is, on my machine, the slo
ce if we
could see config.log on failure.)
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/6/22 11:11, Stephen Frost wrote:
> Greetings,
>
> * Andrew Dunstan (and...@dunslane.net) wrote:
>> On 4/6/22 09:20, Andrew Dunstan wrote:
>>> On 4/5/22 22:21, Andres Freund wrote:
>>>> On 2022-03-27 16:53:57 -0400, Andrew Dunstan wrote:
>>>
On 4/6/22 11:33, Andrew Dunstan wrote:
> On 4/6/22 11:11, Stephen Frost wrote:
>> Greetings,
>>
>> * Andrew Dunstan (and...@dunslane.net) wrote:
>>> On 4/6/22 09:20, Andrew Dunstan wrote:
>>>> On 4/5/22 22:21, Andres Freund wrote:
>>>&g
On 4/6/22 12:59, Andres Freund wrote:
> Hi,
>
> On 2022-04-06 11:50:11 -0400, Andrew Dunstan wrote:
>> It does work, but Tom prefers not to have the test at all, so I'll just
>> rip it out.
> If I understand correctly the reason a large table is needed is to test
&
git.postgresql.org/pg/commitdiff/14d3f24fa8a21f8a7e66f1fc60253a1e11410bf3
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
e database.
>
>> "\sc" isn't awful perhaps.
> I think \dG is pretty good. G for GUC.
>
-1 on anything that is based on "GUC", an ancient and now largely
irrelevant acronym. How many developers, let alone users, know what it
stands for?
\dconf seems fine to me
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/6/22 12:34, Andres Freund wrote:
> Hi,
>
> On 2022-04-06 11:03:37 -0400, Andrew Dunstan wrote:
>> On 3/30/22 20:26, Andres Freund wrote:
>>> Could you try using dash to invoke configure here, and whether it makes
>>> configure faster?
>> I got weird f
On 4/7/22 13:10, Andres Freund wrote:
> Hi,
>
> On 2022-04-06 11:03:37 -0400, Andrew Dunstan wrote:
>> On 3/30/22 20:26, Andres Freund wrote:
>>> Could you try using dash to invoke configure here, and whether it makes
>>> configure faster?
>> I got weird f
On 4/7/22 16:48, Andrew Dunstan wrote:
> On 4/7/22 13:10, Andres Freund wrote:
>> Hi,
>>
>> On 2022-04-06 11:03:37 -0400, Andrew Dunstan wrote:
>>> On 3/30/22 20:26, Andres Freund wrote:
>>>> Could you try using dash to invoke configure here, and whet
On 4/2/22 06:57, Andrew Dunstan wrote:
> Here's a version that actually works. It produces traces that look like
> this:
>
>
> andrew@emma:pg_upgrade $ grep '([0-9]*s)'
> tmp_check/log/regress_log_002_pg_upgrade
> [21:55:06](63s) ok 1 - dump before running pg_
then the parenthetical bit is time-since-last-line
>> (also with ms precision)? I think that would more or less satisfy
>> both uses.
> Would work for me...
>
All doable. Time::HiRes gives us a higher resolution timer. I'll post a
new version in a day or two.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/8/22 08:02, Justin Pryzby wrote:
> On Thu, Mar 31, 2022 at 04:25:58PM -0400, Andrew Dunstan wrote:
>> No code chunks left, only a documentation patch which should land
> Documentation review for a6baa4bad.
>
>> Construct a JSON the provided strings:
> a JSON what
On 4/7/22 19:55, Andrew Dunstan wrote:
> On 4/7/22 17:58, Andres Freund wrote:
>> Hi,
>>
>> On 2022-04-07 17:45:09 -0400, Tom Lane wrote:
>>> Andres Freund writes:
>>>> On 2022-04-07 17:21:09 -0400, Tom Lane wrote:
>>>>> I too think that t
On 4/8/22 21:02, Andres Freund wrote:
> Hi,
>
> On 2022-04-08 19:27:58 -0500, Justin Pryzby wrote:
>> On Thu, Apr 07, 2022 at 10:10:21AM -0700, Andres Freund wrote:
>>> On 2022-04-06 11:03:37 -0400, Andrew Dunstan wrote:
>>>> On 3/30/22 20:26, Andres Freund w
On 4/8/22 09:51, Andrew Dunstan wrote:
> On 4/7/22 19:55, Andrew Dunstan wrote:
>> On 4/7/22 17:58, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2022-04-07 17:45:09 -0400, Tom Lane wrote:
>>>> Andres Freund writes:
>>>>> On 2022-04
On 2022-04-08 Fr 08:15, Andrew Dunstan wrote:
> On 4/8/22 08:02, Justin Pryzby wrote:
>> On Thu, Mar 31, 2022 at 04:25:58PM -0400, Andrew Dunstan wrote:
>>> No code chunks left, only a documentation patch which should land
>> Documentation review for a6baa4bad.
>
n't checked that anything that changed in RFC8259 affects us. I
doubt it would but I guess we should double check.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
1001 - 1100 of 2807 matches
Mail list logo
