33.999 UTC [491848:5] FATAL: could not create any TCP/IP
> sockets
> 2021-10-14 02:10:34.000 UTC [491848:6] LOG: database system is shut down
> Bail out! pg_ctl start failed
>
> Looks like a transient/phase of the moon issue to me.
>
>
Bowerbir
On 10/14/21 5:09 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 10/14/21 12:15 AM, Tom Lane wrote:
>>> Looks like a transient/phase of the moon issue to me.
>> Bowerbird is having similar issues, so I don't think this is just a
>> transient.
> Yea
On 10/13/21 7:11 PM, Andrew Dunstan wrote:
> On 10/13/21 5:46 PM, Andres Freund wrote:
>> Hi,
>>
>> On 2021-10-13 16:06:32 -0400, Andrew Dunstan wrote:
>>> If you prep a patch I'll test it.
>> Well, right now I'm wondering if the better fix is to
On 10/14/21 5:52 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Yes, that's been puzzling me too. I've just been staring at it again and
>> nothing jumps out. But maybe we can investigate that offline if this
>> test is deemed not worth keeping.
> As Mark
addressed by creating a view on the original
> table, even perhaps renaming the original table and create a view using
> the old table name.
That's pretty much my feeling. This seems a bit too cute.
I have a little function I use to create a skeleton query on tables with
lots of columns just so I can delete a few and leave the rest, a problem
that would be solved neatly by the EXCEPT proposal and not but the
HIDDEN proposal.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
sed directly. 2) it
> looks like spinning up a separate postgres instance for all module
> tests takes time on Windows which might make the test time longer. If
> we were to have "vcregress installcheckworld", we might have to add
> new code for converting some of the existing functions to not use a
> pre-started pg instance.
>
> IMHO, we can just have "vcregress subscriptioncheck" and let users
> decide which tests they want to run.
>
> I would like to hear more opinions on this.
>
My opinion hasn't changed. There is already a way to spell this and I'm
opposed to adding more such specific tests to vcregress.pl. Every such
addition we make increases the maintenance burden.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 10/18/21 1:41 AM, Bharath Rupireddy wrote:
> On Sat, Oct 16, 2021 at 6:35 PM Andrew Dunstan wrote:
>>> The problems with having "vcregress checkworld" are: 1) required code
>>> modifications are more as the available "vcregress" test functions,
&
On 10/18/21 9:37 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 10/18/21 1:41 AM, Bharath Rupireddy wrote:
>>> Another thing I noticed is that we don't have any mention of
>>> "vcregress taptest" command in the docs [1], if I read the docs
>&g
On 10/15/21 10:46 AM, Andrew Dunstan wrote:
> On 10/14/21 5:52 PM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Yes, that's been puzzling me too. I've just been staring at it again and
>>> nothing jumps out. But maybe we can investigate that offline if this
rst
"EXECUTE 10" command against the portal is counted. At the very least
this is a POLA violation, and it seems to be a bug. Maybe it's
documented somewhere but if so it's not obvious to me.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
gxsdir)/$(subdir)/PostgreSQL/Version.pm'
> [...]
> - rm -f '$(DESTDIR)$(pgxsdir)/$(subdir)/PostgreSQL/Test/PostgresVersion.pm'
> + rm -f '$(DESTDIR)$(pgxsdir)/$(subdir)/PostgreSQL/Version.pm'
right. There are one or two other cosmetic changes too.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 10/20/21 9:02 AM, Laurenz Albe wrote:
> On Tue, 2021-10-19 at 15:24 -0400, Andrew Dunstan wrote:
>> The problem I'm writing about (h/t Simon Riggs for finding it) is
>> illustrated by the following snippet of java:
>>
>> public static void runtest(C
approximation for
count(*).
But something else that gave a fast approximate answer
("count_estimate(*)"?) would be useful to many. Not portable but still
useful, if someone could come up with a reasonable implementation.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 10/20/21 08:40, Andrew Dunstan wrote:
> On 10/19/21 11:22 PM, Michael Paquier wrote:
>> On Tue, Oct 19, 2021 at 10:16:06PM +0200, Erik Rijkers wrote:
>>>> [0001-move-perl-test-modules-to-PostgreSQL-Test-namespace.patch ]
>>>> [0002-move-PostgreSQL-Test-Post
ly (no more than
once every five years, say) unless there's a very good reason. I'm also
not opposed to us making small adjustments to allow us to build old
versions on modern platforms, but if we do that then we should probably
have some buildfarm support for it.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
m status page's
> desire to drop old results that are more than 30 days old. I guess
> you'd just need to force a run at least every 28 days or something.
>
Well, we could do that, or we could modify the way the server does the
status. The table it's based on has
.6M REL9_5_STABLE/pgsql
5.5M REL9_6_STABLE/pgsql
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Windows platform, for example.)
Well, we do build with gcc on Windows :-) But yes, maybe we should make
this a more opt-in process.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
of a
better way to manage it then please let me know. On crake (which is
actually checking out four different repos) the checkout step typically
takes one or two seconds.
Copying the work tree can take a few seconds - to avoid that on
Unix/msys use vpath builds.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 10/25/21 19:12, Justin Pryzby wrote:
> On Mon, Oct 25, 2021 at 11:38:51AM -0400, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 10/25/21 10:23, Tom Lane wrote:
>>>> (Hmmm ... but disk space could
>>>> become a problem, particularly on older m
Maybe
> versions-divisible-by-five would work? Or versions divisible by ten,
> but experience so far suggests that we'll want to move the cutoff more
> often than once every ten years.
>
>
pg_upgrade claims to be able to operate on 8.4, which might be all the
bett
't want to perpetuate the misfeature though, so let's
just bring it to an end.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
to
have a list of users, and we in effect delegate authentication to
pgbouncer.
It would be nice to have + and @ expansion for the usernames in the
ident file, like there is for pg_hba.conf.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
> I personally don’t see that as a dealbreaker.
>
Maybe it would be worth creating a non-core extension for things like
this that we are ripping out? I have no idea how many people might be
using them.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
dict when replication
+ workers will notice the new ownership. Subscriptions created
disabled and
+ only enabled after ownership has been changed will not be subject to
this
+ race condition.
maybe we should disable the subscription before making such a change and
then re-enable
better to implement
a general Makefile-like mechanism for handling FOO=bar type arguments on
the command line, along the lines of the attached.
Thoughts?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
On 11/1/21 21:23, Michael Paquier wrote:
> On Mon, Nov 01, 2021 at 11:33:21AM -0400, Andrew Dunstan wrote:
>> As I mentioned recently at
>> <https://postgr.es/m/5d72f199-dc11-89a8-29d1-f20f9687c...@dunslane.net>,
>> I want to get USE_MODULE_DB working for vcregress.p
be willing to incur
>> *way more* useless log messages than those settings would ever
>> generate if it meant that they could actually find problems when and
>> if they have them.
> I fully agree.
/metoo
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 11/2/21 11:03, Andrew Dunstan wrote:
> On 11/1/21 21:23, Michael Paquier wrote:
>> On Mon, Nov 01, 2021 at 11:33:21AM -0400, Andrew Dunstan wrote:
>>> As I mentioned recently at
>>> <https://postgr.es/m/5d72f199-dc11-89a8-29d1-f20f9687c...@dunslane.net>,
. I think at
least the first set is not in bad shape, but it would benefit from some
fresh eyeballs. Tom Kincaid is trying to arrange some extra resources
for that, so we might well see some progress soon.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
uster uses :Utils, and perl is smart enough not to try to reprocess
the module. Thus the extra cost here is almost certainly very close to zero.
This is a perfectly reasonable piece of boilerplate to use at the top of
a TAP test:
use strict;
use warnings;
use PostgreSQL:Test::Clust
TAP tests that would spit out
the version on the log?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Wouldn't it be better in any case just to add the clang fix for building
plperl rather than globally?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 11/11/21 15:44, Tom Lane wrote:
> Alvaro Herrera writes:
>> On 2021-Nov-11, Andrew Dunstan wrote:
>>> Perhaps we could add a line to one of the TAP tests that would spit out
>>> the version on the log?
>> Maybe have it spit out the version of *all* the module
On 11/12/21 10:05, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 11/11/21 15:44, Tom Lane wrote:
>>> Yeah ... configure is already checking those versions, so maybe we could
>>> make it print them out along the way? I'd been thinking of doing exactly
>>
base is created. Regardless of the specific character set, the
character with code zero (sometimes called NUL) cannot be stored.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
st::More
1.001014
So I agree 0.98 seems like a perfectly reasonable target. You should be
able to drop a replacement on prairiedog quite simply. For jacana I just
unpacked it and pointed PERL5LIB at it.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
talled but not used, alongside 2.7 which is udsed. I will install
the latest and see if that can be made to work.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
m to be a CF item for it but I'm
inclined to commit it in a couple of days time.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
e initially empty. But DBAs would be
able to modify and extend the settings. I agree with Tom that we
shouldn't try to cover all GUCs in the table - any GUC without an entry
can only be updated by a superuser.
To support pg_dump and pg_upgrade, it might be better to have an
enabled/disabled
On 11/16/21 15:08, Mark Dilger wrote:
>
>> On Nov 16, 2021, at 12:06 PM, Andrew Dunstan wrote:
>>
>> There doesn't seem to be a CF item for it but I'm
>> inclined to commit it in a couple of days time.
> https://commitfest.postgresql.org/36/3414/
ve a single ACL array
> for the all privileges on an object. Why wouldn't we do the same thing
> here?
>
Yes, that should work, It seems like a better scheme.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
issions for
the predefined roles are immutable, so only permissions sets for user
defined roles are mutable.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
d of embedding this in the buildfarm client, so much the
better.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 11/17/21 11:07, Mark Dilger wrote:
>
>> On Nov 17, 2021, at 6:31 AM, Andrew Dunstan wrote:
>>
>> Well, I was trying (perhaps not very well) to imagine how to deal with
>> someone modifying the permissions of one of the predefined roles. Say
>> pg_foo has init
On 11/17/21 12:12, Mark Dilger wrote:
>
>> On Nov 17, 2021, at 9:06 AM, Andrew Dunstan wrote:
>>
>> I agree it's not ideal. At the time I suggested a more flexible approach
>> I hadn't really thought about the problems of upgrading. If you can come
>&
On 11/16/21 15:06, Andrew Dunstan wrote:
> On 11/3/21 15:50, Mark Dilger wrote:
>>> On Nov 1, 2021, at 10:58 AM, Mark Dilger
>>> wrote:
>>>
>>> ALTER SUBSCRIPTION..[ENABLE | DISABLE] do not synchronously start or stop
>>> subscription w
On 11/16/21 11:26, Andrew Dunstan wrote:
>
> My other machine with an old python instance is bowerbird. It has python
> 3.4 installed but not used, alongside 2.7 which is udsed. I will install
> the latest and see if that can be made to work.
>
>
bowerbird is now buildin
ll.)
> I bet it's possible to use the ClientAuthentication_hook for this. In
> any case, I agree that it probably belongs server-side so that other
> clients can benefit from this.
>
+1 for a server side solution. The people most likely to benefit from
this are the people least likely to be using psql IMNSHO.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
immediately shorten it to just "replay", eg
> as a part of names in the code, and I feel that that's confusing in
> its own way. Maybe we could run the words together, on the precedent
> of "walreceiver", but I never much liked that name either.
>
>
Maybe something along those lines but using a dash/hyphen would work:
e.g. wal-replayer
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Test::Simple's changelog.
>
>
Yeah, so I think at this stage we're just waiting for you to update
prairiedog and we can make this change.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ch a way that it
generates no redundant updates. However, there is a cost to using it,
and the break even point can be surprisingly high. It should therefore
be used with caution, and after appropriate benchmarks.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
#x27;s been built into postgres since release
8.4. Just be aware that if you use it there is a cost incurred for every
record updated whether or not the record is redundant. If only 12% of
your updates are redundant I suspect it will be a net loss for you, but
as I said above you should benchmark it.
On 11/20/21 11:14, Tom Lane wrote:
> Andrew Dunstan writes:
>> Yeah, so I think at this stage we're just waiting for you to update
>> prairiedog and we can make this change.
> Oh! I was intentionally waiting to do that, with the idea of verifying
> that the ve
-windows/git/wiki/Symbolic-Links>
I haven't yet worked out a way of granting that from the command line,
but if it's working the buildfarm client (as of git tip) will use it on
windows for the workdirs space saving feature.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
fore too long; (2) we have
> zero coverage for older Test::More versions anyway, now that
> all buildfarm members have been updated to work with HEAD.
>
This one seems like a good idea.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ready bind to their own symbols at compile time)? I've seen that for
> replacing buggy functions in closed source things, but that's about it?
>
Which things does it break exactly? I have a case where a library that
is LD_PRELOADed calls PQsetSSLKeyPassHook_OpenSSL() in its constructor
function. I'd be very unhappy if that stopped working (and so would our
client).
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Bsymbolic doesn't have an effect for that symbol.
>
>
>> I have a case where a library that
>> is LD_PRELOADed calls PQsetSSLKeyPassHook_OpenSSL() in its constructor
>> function. I'd be very unhappy if that stopped working (and so would our
>> client).
> Bsymboli
On 11/26/21 04:12, Daniel Gustafsson wrote:
>> On 26 Nov 2021, at 05:45, Tom Lane wrote:
>>> Personally I'm not really in favour of outright disabling the C4101
>>> warning on Windows, because I think it is a useful warning for
>>> Postgres developers on Windows for cases unrelated to the use of
I guess that would mostly be detected by Msys systems
running gcc.
Anyway I don't think it's worth arguing a lot about.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 11/23/21 10:47, Andrew Dunstan wrote:
> On 11/23/21 04:07, Thomas Munro wrote:
>> On Wed, Oct 6, 2021 at 7:10 PM Thomas Munro wrote:
>>> I wonder if for Windows we'd want to switch to real symlinks, since,
>>> as far as I know from some light reading, rep
atch_35_2901.log>. I'm not sure what's not
working for you. I apply them using "patch -p 1 < $patchfile"
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
If we're willing to outright remove it, I don't have any great objection.
> My original two cents was that we shouldn't put effort into improving it;
> but removing it isn't that.
>
>
+1
Let's just remove it. We already know
in explain tests can be fragile. Better use "explain
> (costs off)". If you run "make check" continuously in a loop, you
> should get some failures related to that pretty quickly.
>
Agree about costs off, but I'm fairly dubious of the value of using
EXPLAIN at all here.Nothing in the patch should result in any change
in EXPLAIN output.
I would probably just have a few regression lines that should be sure
to exercise the code path and leave it at that.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
t execute a different
> plan and ensure that the output remains unchanged.
>
If we're going to keep the vacuums in there, do we need to add a wait
barrier like Claudio suggested upthread?
Once we decide on that I propose to commit this.
cheers
andrew
--
Andrew Dunstan
e. Maybe we could get it
> back in there by having some trailing-edge buildfarm member
> contribute typedefs, but that seems like a solution with a rather
> limited half-life.
>
pgindent already has a list of blacklisted typedefs (see lines 121 to 123)
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sun, Mar 25, 2018 at 9:13 PM, David Rowley
wrote:
> On 25 March 2018 at 20:09, David Rowley wrote:
>> On 15 March 2018 at 21:33, Andrew Dunstan
>> wrote:
>>> rebased and mostly indented patch version attached.
>>
>> Thanks. I've attached a version of
available at
<https://buildfarm.postgresql.org/downloads/releases/build-farm-7.tgz>
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sun, Mar 25, 2018 at 11:32 AM, Andrew Dunstan
wrote:
> On Sun, Mar 25, 2018 at 3:55 AM, Tom Lane wrote:
>> I noticed that doing pgindent with the current typedefs list available
>> from the buildfarm caused a lot of havoc in what had been stable code.
>> Looking into
On Mon, Mar 26, 2018 at 6:06 PM, Pavan Deolasee
wrote:
>
>
> On Sun, Mar 25, 2018 at 6:00 AM, Andrew Dunstan
> wrote:
>>
>> On Fri, Mar 23, 2018 at 8:27 PM, Pavan Deolasee
>> wrote:
>> >>
>> >>
>> >> I would probably just hav
is even worse in terms of the amount of syntax space it will
> occupy, again for zero functional benefit.
>
If we were going to do it then we should be consistent about it and
also allow parameter-less function calls to skip the parentheses. But
anyway none of that is currently proposed so let's save the argument
for the time when it is :-)
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
for 10 or 9.6 knowing that
> they still have four years to go, that could be debated, but just for 6
> months there is little benefit.
I am in discussions with Mark, he's going to disable the animals from
building 9.3. (by setting branches_to_build to 'HEAD_PLUS_LATEST4'
inst
On Tue, Mar 27, 2018 at 10:57 AM, Alvaro Herrera
wrote:
> Andrew Dunstan wrote:
>
>> I am in discussions with Mark, he's going to disable the animals from
>> building 9.3. (by setting branches_to_build to 'HEAD_PLUS_LATEST4'
>> instead of 'ALL&#
string_agg(), but not for
> array_agg(). I see a lot of cases where people use that to load it into an
> unordered array/hashmap/set/whatever on the client side, which looses
> ordering *anyway*,and they would definitely benefit from it.
Agreed, I have seen lots of uses of array_agg where the order didn't matter.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
. instead of explaining that we used to have a
spinlock and don't have one any longer, just explain why we don't need
a spinlock.
All the regression and TAP tests pass happily.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Mar 28, 2018 at 8:32 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>>> pgindent already has a list of blacklisted typedefs (see lines 121 to 123)
>
> Oh, so it does.
>
>> Here's a patch to pgindent which I think will do what you want fairly
>> simply
point does not exist in the current WAL, we read forward the previous
> WAL and return the last checkpoint record in that WAL and so on. So in the
> worst case, we might read a WAL segment extra before we find the checkpoint
> record. That's not ideal but not too bad given that only pg
with large WAL segments, which is not appealing either, and
> this even if the checkpoint skip logic has been fixed in v10 with the
> concept of "important" WAL records.
If the system is mostly idle would it really matter that much?
cheers
andrew
--
Andrew Dunstanh
On Wed, Mar 28, 2018 at 5:30 PM, Andres Freund wrote:
> Hi,
>
> On 2018-03-26 09:02:10 +1030, Andrew Dunstan wrote:
>> Thanks for this, all looks good. Here is the consolidate patch
>> rebased. If there are no further comments I propose to commit this in
>> a few day
On Thu, Mar 29, 2018 at 10:19 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On Wed, Mar 28, 2018 at 5:30 PM, Andres Freund wrote:
>>> + /*
>>> +* Missing value for added columns. This is a one element array
>>> which lets
>>> +
On Fri, Mar 30, 2018 at 5:00 AM, Andres Freund wrote:
> Hi,
>
> On 2018-03-29 10:16:23 +1030, Andrew Dunstan wrote:
>> On Wed, Mar 28, 2018 at 5:30 PM, Andres Freund wrote:
>> > Hi,
>> >
>> > On 2018-03-26 09:02:10 +1030, Andrew Dunstan wrote:
>>
On Fri, Mar 30, 2018 at 10:08 AM, Andrew Dunstan
wrote:
> On Fri, Mar 30, 2018 at 5:00 AM, Andres Freund wrote:
[ missing values are loaded in the TupleDesc by RelationBuildTupleDesc ]
>>> > I'm still strongly object to do doing this unconditionally for queries
>>
o the same thing.
Perhaps the "save" part of it needs to be factored out.
In any case, it's quite doable. I can work on that after this gets committed.
Currently we seem to have only two machines doing the cross-version
upgrade checks, which might make it easier to rearrange anyt
(which would be right up against the deadline by my calculation) ,
depending on some other important obligations I have.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sat, Apr 7, 2018 at 1:50 AM, Andres Freund wrote:
> Hi,
>
> On 2018-04-06 21:30:36 +0930, Andrew Dunstan wrote:
>> OK, I think this is now committable.
>
>> The changes are small, fairly isolated in effect, and I think every
>> objection has been met, partl
On Fri, Apr 6, 2018 at 10:00 PM, Peter Eisentraut
wrote:
> On 4/3/18 18:05, Andrew Dunstan wrote:
>> Currently we seem to have only two machines doing the cross-version
>> upgrade checks, which might make it easier to rearrange anything if
>> necessary.
>
> I think w
e
regression set. Clearly we should add something, as Tom has reminded me,
to make sure the code path is exercised.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
substantial. Abbreviated keys might help, but
generally I think I would want to put such logs on a compressed ZFS
drive or some such.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
EL9_6 (older branches don't work
> easily with VS2015, as discussed elsewhere).
>
> If anyone has any specific questions about it or suggestions, please
> feel free to reach out.
>
Good. I notice that it doesn't seem to be running the plpython tests
even though it&#x
arsed in by the input function. In particular, it
assumes that anything like a NaN will be stored as text and not as a
jsonb numeric. I don't think the transform should be doing anything
different from the input function.
There is the routine IsValidJsonNumber that helps - see among others
hstore_io.c for an example use.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ny for rewriting in perl. Do you want to have a go at that? If not I
will.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
(see our docs
for details). It's also possible to use Cmake for extensions, although
this is currently not well documented.
w.r.t. threads and mutexes, you would probably be better off using the
Windows API. See for example what is said here regarding windows
threads vs posix threads: &
ed, if not in
Catalog.pm then in a script which serves both for dup0licate_oids and
unused_oids.
Here is something I cobbled together for the latter approach. It could
probably improve by using Catalog::FindDefinedSymbol()
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
unused_oids.pl
Description: Perl program
o multiple lines, but I don't see an option for that :-(
>
>
Right. Maybe we need a script that at least identifies them for us.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
I hope. See
<https://github.com/PGBuildFarm/client-code/commit/1fc4e81e831fda64d62937de242ecda0ba145901>
bowerbird which is already running that code is running the test you
refer to:
<https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=bowerbird&dt=2019-09-08%2017%3A51%3A19&a
On 9/6/19 3:51 PM, Andrew Dunstan wrote:
> On 9/6/19 2:42 PM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Given your stated intention, I think the simplest way to get it is just
>>> this, without worrying about what the perl modules might do:
>>> -if ($@
em to suggest this is by design. (FSVO
"design")
I tested this on older versions and the change appears to work, so I
propose to apply the attached patch.
This is the last obstacle I have to declaring msys2 fully supportable.
cheers
andrew
--
Andrew Dunstan
On 9/8/19 5:59 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 9/8/19 12:07 PM, Tom Lane wrote:
>>> It looks to me like the reason is that src/tools/msvc/vcregress.pl's
>>> subroutine subdircheck isn't considering the possibility that
>>> subdir
On 9/8/19 6:18 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 9/8/19 5:59 PM, Tom Lane wrote:
>>> Hm. Changing the buildfarm script would be an alternative way to
>>> fix the issue so far as the buildfarm is concerned, but it doesn't
>>> seem l
On 9/9/19 4:48 AM, Peter Eisentraut wrote:
> On 2019-09-09 00:06, Andrew Dunstan wrote:
>> Diagnosing this took quite a lot of time and detective work. For some
>> reason I don't quite understand, when calling the Windows command
>> processor in a modern msys2/WindowsSe
301 - 400 of 2779 matches
Mail list logo
