On 10/26/2017 12:12 AM, Michael Paquier wrote:
> On Wed, Oct 25, 2017 at 5:24 AM, Andrew Dunstan wrote:
>> Process variadic arguments consistently in json functions
>>
>> json_build_object and json_build_array and the jsonb equivalents did not
>> correctly process
On 10/22/2017 04:35 PM, Michael Paquier wrote:
> On Mon, Oct 23, 2017 at 1:44 AM, Andrew Dunstan
> wrote:
>
>> here's a patch that works that way, based on Michael's code.
> Patch not attached :)
> I still have a patch half-cooked, that I can send if necess
On 10/22/2017 12:11 PM, Andrew Dunstan wrote:
>
> On 10/21/2017 07:33 PM, Michael Paquier wrote:
>> On Sun, Oct 22, 2017 at 1:43 AM, Tom Lane wrote:
>>> I don't think collecting all the arguments is particularly special ---
>>> format() or concat() for ins
On 10/13/2017 08:09 AM, Thomas Munro wrote:
> On Fri, Oct 13, 2017 at 1:42 PM, Andrew Dunstan
> wrote:
>> Well, as you can see here the appveyor.yml file can live outside the
>> tree that's being built.
> Here's a Wiki page where I hope we can collect how-to info
Not everyone has cpanminus installed either. My approach in the
buildfarm code is to lean over backwards in order to avoid non-standard
modules. For the problem at hand we use cp/xcopy, but the tree being
copied is stable so we don't run into the disappearing/changing file
problem.
chee
On 10/12/2017 06:46 PM, Thomas Munro wrote:
> On Fri, Oct 13, 2017 at 10:57 AM, Andrew Dunstan
> wrote:
>> Actually, that didn't take too long.
>>
>> No testing yet, but this runs a build successfully:
>> <https://gist.github.com/adunstan/7f18e5db33bb2d73
On 10/12/2017 04:14 PM, Andrew Dunstan wrote:
>
> On 10/11/2017 11:04 PM, Thomas Munro wrote:
>> Hi hackers,
>>
>> I don't use Windows myself, but I'd rather avoid submitting patches
>> that fail to build, build with horrible warnings or blow up on th
;m taking a look.
A couple of things not in their pre-built images that we'll need are
flex and bison. We might be able to overcome that with chocolatey, which
is installed, haven't tested yet.
getting a working appveyor.yml will take a little while, though.
cheers
andrew
--
Andrew Dun
On 09/27/2017 02:52 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> At this stage on reflection I agree it should be pulled :-(
> That seems to be the consensus, so I'll go make it happen.
>
>> I'm not happy about the idea of marking an input function as not
On 10/03/2017 04:43 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2017-10-03 16:34:38 -0400, Andrew Dunstan wrote:
>>> AFAICT at a quick glance these are only used in a couple of files. Maybe
>>> the defs need to be floated off to a different header with more li
nce these are only used in a couple of files. Maybe
the defs need to be floated off to a different header with more limited
inclusion?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent vi
On Mon, Oct 2, 2017 at 8:00 PM, Alexander Korotkov
wrote:
> What happen if exactly this "continue" fires?
>
>> if (GistFollowRight(stack->page))
>> {
>> if (!xlocked)
>> {
>> LockBuffer(stack->buffer, GIST_UNLOCK);
>> LockBuffer(stack->buffer, GIST_EXCLUSIVE);
>> xlocked = true;
>> /* someone migh
Hi, Alexander!
Thanks for looking into the patch!
On Thu, Sep 28, 2017 at 3:59 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
>
>
> In gistdoinsert() you do CheckForSerializableConflictIn() only if page
> wasn't exclusively locked before (xlocked is false).
>
> if (!xlocked)
>> {
>>
On 10/01/2017 04:48 PM, Andres Freund wrote:
> On 2017-10-01 16:42:44 -0400, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 09/30/2017 10:32 PM, Andres Freund wrote:
>>>> Heh. I'm inclined to take it out. We could add a --use-the-force-luke
>>>&g
On 09/30/2017 10:32 PM, Andres Freund wrote:
> Hi,
>
> On 2017-09-30 22:28:39 -0400, Andrew Dunstan wrote:
>>>> But even after fixing that, there unfortunately is:
>>>>
>>>> static void
>>>> set_sig(char *signame)
>>>&g
fixes up properly with DROPs as the first
> options.
>
>
I assume the proposal is to allow changing to a different server using
the same FDW. I can see all sorts of odd things happening if we allow
changing to a server of a different FDW.
cheers
andrew
--
Andrew Dunstan
On 09/29/2017 01:10 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 09/28/2017 05:44 PM, Tom Lane wrote:
>>> Assuming that that's going to happen for v11, I'm inclined to leave the
>>> optimization problem until the dust settles around CaseTestExpr.
&g
I'm Ok with it as long as we don't forget to revisit this.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-ha
so there would be less danger of a PL
just treating it as an unconstrained base type as it might do if it saw
TYPEFUNC_COMPOSITE.
Maybe I'm wrong, but I have a strong suspicion that of we leave it like
this now we'll regret it in the future.
cheers
andrew
--
Andrew Dunstan
e what or
> how to benchmark.
>
>
Some case where we only expect the current code to produce a single
ArrayCoerceExpr, I guess. say doing text[] -> int[] ?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Rem
On 09/28/2017 12:29 PM, Andrew Dunstan wrote:
> The new crash-recovery check is failing pretty reliably on jacana. It's
> already excluded on MSVC machines, so I'm inclined to exclude it on Msys
> as well.
>
>
Sorry, I meant crash-restart
cheers
andrew
--
Andrew Dun
The new crash-recovery check is failing pretty reliably on jacana. It's
already excluded on MSVC machines, so I'm inclined to exclude it on Msys
as well.
Thoughts?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support,
behavior
> we want for that case. So I don't want to create a precedent for that
> here.
>
> Thoughts?
>
This is a pretty nice patch, and very small indeed all things
considered. From a code point of view I have no criticism, although
maybe we need to be a bit more emphatic in the he
orward, as is patch 3. Patch 2 is fairly
complex, but it still does the one thing stated above - there's just a
lot of housekeeping that goes along with that. I couldn't see any
obvious problems with the implementation.
I wonder if we need to do any benchmarking to assure ourselves th
On 09/27/2017 06:05 AM, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>> doc: first draft of Postgres 10 release notes
> I noticed that this item
>
> +
> +
> +Reduce locking required for adding values to enum types (Andrew Dunstan,
> +Tom Lane)
> +
> +
> +
&g
On 09/26/2017 06:04 PM, Andrew Dunstan wrote:
>
> On 09/26/2017 05:45 PM, Stephen Frost wrote:
>> I've not been following along very closely- are we sure that ripping
>> this out won't be worse than dealing with it in-place? Will pulling it
>> out also
o AFAIK - the function signatures weren't changed.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
back to "revert the whole feature, go back to 9.6
> behavior".
>
> Thoughts?
I think I would mark enum_in and friends as parallel-restricted. Yes I
know it would involve a cat version bump, so I'll understand if that's
not acceptable, but it seems to me the best
On 09/25/2017 01:34 PM, David E. Wheeler wrote:
> On Sep 25, 2017, at 10:55, Andrew Dunstan
> wrote:
>
>> Let's ask a couple of users who I think are or have been actually
>> hurting on this point. Christophe and David, any opinions?
> If I understand the issue c
> 11+, general purpose, do something that is, indeed, more general,
> i.e., that supports high-performance scenarios too?
>
>
>
A general purpose lower bandwidth plugin might one supporting Protocol
Buffers. The downside is that unlike json it's not self-contained, you
need
On 09/25/2017 10:42 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 09/25/2017 10:14 AM, Tom Lane wrote:
>>> Oh ... I did not think we were on the same page, because your patch
>>> didn't include removal of the same-transaction heuristic. It'd be
>&g
On 09/25/2017 10:14 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 09/24/2017 07:06 PM, Tom Lane wrote:
>>> So I think we should just stop with the blacklist test for v10,
>>> and then see if we still get complaints (and exactly what they're
>>>
t;
>
Thanks, committed and backpatched to 9.6 It would be nice to get
buildfarm members going supporting VS2015 and VS2017
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-h
where we were in previous releases, and ahead of
> where we'd be if we end up reverting the patch altogether.
>
>
That's pretty much what I was saying.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DB
On 09/24/2017 04:37 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> OK, here's the finished patch. It has a pretty small footprint all
>> things considered, and I think it guarantees that nothing that could be
>> done in this area in 9.6 will be forbidden. That's
On 09/23/2017 06:06 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> OK, I think I'm convinced. Here's is the WIP code I put together for the
>> blacklist. I'm was looking for a place to put the init call, but since
>> it's possibly not going anywhere I
On 09/23/2017 03:52 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 09/23/2017 02:00 PM, Tom Lane wrote:
>>> So I'm back to not being sure about the path forward. Maybe it would be
>>> all right to say "the value added by ADD VALUE can't be used in
On 09/23/2017 02:00 PM, Tom Lane wrote:
> I wrote:
>> Andrew Dunstan writes:
>>> I see what you're saying, but my idea was slightly different. We would
>>> only add to the hashtable I had in mind at the bottom AddEnumLabel().
>>> Any other value, whethe
On 09/23/2017 11:16 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>
>>> The immediate question is do we care to design/implement such a thing
>>> post-RC1. I'd have to vote "no". I think the most prudent thing to
>>> do is revert 15bc038
On 09/22/2017 11:19 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 09/22/2017 05:46 PM, Tom Lane wrote:
>>> I'm not sure if that qualifies as a stop-ship problem, but it ain't
>>> good, for sure. We need to look at whether we should revert 15bc038f9
der if we wouldn't be better
doing this more directly, keeping a per-transaction hash of unsafe enum
values (which will almost always be empty). It might even speed up the
check.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Su
-vs
>
>
That page also says:
Microsoft Visual Studio Build Tools 2017
Also installs on Windows Server 2008 R2 SP1
So I'm inclined to adjust the documentation accordingly.
cheers
andrew
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development
On 09/21/2017 09:41 PM, Andres Freund wrote:
> On 2017-09-21 09:30:31 -0400, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> The speed of memset is hardly going to be the dominating factor in a
>>> 'CREATE DATABASE' command, so we could certainly afford to
nts
> to V141, when I create a sample project with VS 2017 and the version
> number is inline with nmake version also.
>
>
>
I was about to commit this after a good bit of testing when I noticed this:
+ Building with Visual Studio 2017 is
supported
+ dow
On 09/21/2017 02:53 AM, Haribabu Kommi wrote:
>
>
> On Thu, Sep 21, 2017 at 12:26 PM, Andrew Dunstan
> <mailto:andrew.duns...@2ndquadrant.com>> wrote:
>
>
>
> On 09/20/2017 08:18 PM, Andrew Dunstan wrote:
> >
> > On 09/20/2017 07:5
On 09/20/2017 08:18 PM, Andrew Dunstan wrote:
>
> On 09/20/2017 07:54 PM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> It's also warning that it will copy 16 bytes to a 13 byte structure at
>>> lines 518, 1293 and 1294 of src/backend/commands/dbcommands.c. I
On 09/20/2017 07:54 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> It's also warning that it will copy 16 bytes to a 13 byte structure at
>> lines 518, 1293 and 1294 of src/backend/commands/dbcommands.c. I haven't
>> seen any ill effects of this so far
On 09/20/2017 07:32 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 09/20/2017 06:13 PM, Michael Paquier wrote:
>>> Those are around for some time, see here:
>>> https://www.postgresql.org/message-id/CAB7nPqTkW=b_1jvvywd_g0wrkot+4ufqjggrv8osqbuzzxg...@mail.gmail.co
On 09/20/2017 06:13 PM, Michael Paquier wrote:
> On Thu, Sep 21, 2017 at 7:08 AM, Andrew Dunstan
> wrote:
>> First, it warns about a couple of unused variables at lines 4553 and
>> 4673 of src/backend/optimizer/path/costsize.c. I think we can do a
>> little rearrangemen
is possibly amiss on this compiler with the MemSet macros.
The regression tests are currently failing on my test platform (Windows
Server 2016) because it says it can't change permissions on the
testtablespace directory. I have no idea what's going on there, still
investigating.
sistent fix would seem
to be to make all the affected functions return NULL, which probably
requires factoring out a bunch of close_*_internal functions and
replacing the DirectFunctionCall usage.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
d module, don't fail if not installed.
> eval { use Carp::Always; }
>
> Comments?
>
Or maybe Devel::Confess ?
In an eval you need a 'require' rather than a 'use', AFAIK.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Develop
On 09/19/2017 02:47 PM, Andrew Dunstan wrote:
>
> On 09/19/2017 11:11 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> This seems to have upset a number or animals in the buildfarm.
>> Actually, after looking closer, my advice is just to drop the new
>> test
On 09/19/2017 11:11 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> This seems to have upset a number or animals in the buildfarm.
> Actually, after looking closer, my advice is just to drop the new
> test cases involving accented letters. It surprises me not in the
> leas
On 09/19/2017 08:35 AM, Andrew Dunstan wrote:
> Add citext_pattern_ops for citext contrib module
>
> This is similar to text_pattern_ops.
>
This seems to have upset a number or animals in the buildfarm.
I could create a third output file, but I am seriously questioning the
point
en_US. If you don't
> satisfy both of those cases, the buildfarm will not like you.
>
>
I'm about to pick this one up - I will handle the expected file issue.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Develop
t build
will be very useful on its own, especially if there are links to the
failure reports. When we are satisfied that we're not getting
significant numbers of false negatives over a significant period we can
talk about automating CF state changes. I agree this is nice work.
cheers
andrew
--
On 09/11/2017 01:58 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 09/08/2017 09:40 AM, Tom Lane wrote:
>>> Like you, I'm a bit worried about the code for extracting an exit
>>> status from IPC::Run::run. We'll have to keep an eye on the buildfarm
&
> status from IPC::Run::run. We'll have to keep an eye on the buildfarm
> for a bit. If there's any trouble, I'd be inclined to drop it down
> to just success/fail rather than checking the exact exit code.
>
>
bowerbird seems to have been made unhappy
n commit
>> 18ce3a4ab22d2984f8540ab480979c851dae5338 which I think should be
>> corrected with something like the attached, though I'm not sure if
>> it's possible to reach it.
Thomas> Adding Kevin and Andrew G. Thoughts on whether this is a
Thomas> defec
On 08/07/2017 04:20 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 08/07/2017 04:07 PM, Tom Lane wrote:
>>> Sorry, I was imprecise. What I'm suggesting is that you drop the
>>> runtime PATH-foolery and instead put this in configure's environm
On 08/07/2017 04:07 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 08/07/2017 03:36 PM, Tom Lane wrote:
>>> My goodness, that's ugly. Is it really better than injecting
>>> "PROVE=prove"? (I'd suggest saying that to configure, not make,
>&
On 08/07/2017 03:36 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 08/07/2017 03:21 PM, Tom Lane wrote:
>>> I'm confused. AFAIK, that commit did not change which "prove" would
>>> be used --- at least not unless you change PATH between co
On 08/07/2017 03:21 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 07/31/2017 01:02 PM, Tom Lane wrote:
>>> Record full paths of programs sought by "configure".
>> The problem with this commit, as jacana is demonstrating, is that on
>> Msys it finds
ve needs to run with the perl from
the MSys DTK that understands MSys virtualized paths. I have a hack that will
allow the buildfarm to overcome the difficulty, (essentially it passes
'PROVE=prove' to make) but that's fairly ugly and certainly non-intuitive for
someone
On 07/31/2017 06:54 PM, Tom Lane wrote:
> but could we do something like
> my $pflags = "PROVE_FLAGS='" . ($ENV{PROVE_FLAGS} || "--timer") . "'";
>
> to allow overriding this choice from the buildfarm config?
>
>
I have co
On 07/28/2017 08:22 AM, Andrew Dunstan wrote:
>
> On 07/27/2017 11:58 PM, Tom Lane wrote:
>> I kinda suspect we're not actively testing non-MULTIPLICITY builds
>> either. The 5.8.7 test I just ran was with a non-MULTIPLICITY build,
>> so the case doesn't seem
cal animals we can ask the owners to
apply a fairly simple patch.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
hing exists)
We haven't used PERL_IMPLICIT_CONTEXT to date, and without ill effect.
For example. it's in the ExtUtils::Embed::ccopts for the perl that
jacana and bowerbird happily build and test against.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreS
setjmp*
> ...
> ...
>
> 651 #define times PerlProc_times
> 652 #define waitPerlProc_wait
> 653 *#define setjmp PerlProc_setjmp
>
> *
What is the minimal set of extra defines required
On 07/26/2017 11:12 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>
>>> I still find this pretty ugly :-(.
>> I'm open to alternative suggestions. But I don't want to spend a heck of
>> a lot of time on this.
> Well, let's at least do the temp
On 07/26/2017 09:33 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>
>> The latter fact makes me
>> theorize that the problem arises from the fairly ancient perl that Msys
>> provides, and which we need to use to run prove so the TAP tests
>> understand the enviro
On 07/25/2017 02:45 PM, Andrew Dunstan wrote:
>> Anyway, if we believe that it broke with f13ea95f9, hen it's plausible
>> that CMD.EXE has been sharing pg_ctl's stdout/stderr all along, and we
>> just had not noticed before. Could you check what happens if we
&
On 07/25/2017 01:41 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 07/25/2017 11:25 AM, Tom Lane wrote:
>>> Oh. So when was the last time it worked? And why do the buildfarm
>>> archives contain apparently-successful log_stage entries for pg_ctl-check
>>
opts rather than ccflags?
> I was looking at the current code which fetches ldopts, and analogizing.
> Don't know the difference between ccflags and ccopts.
>
>
per docs:
ccopts()
This function combines "perl_inc()", "ccflags()"
On 07/25/2017 11:25 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 07/25/2017 11:11 AM, Tom Lane wrote:
>>> What I'm on about is that jacana still succeeds entirely, more than half
>>> the time. If this is a handle-duplication problem, how could it ever
>
On 07/25/2017 11:11 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 07/24/2017 09:33 PM, Tom Lane wrote:
>>> Seems like the TAP test should fail every time, if this is a full
>>> description. But maybe it's part of the answer, so it seems worth
>>>
Utils::Embed -e ccopts
>
> on one of the affected installations, and compare that to the problematic
> field(s).
-s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS
-DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fwrapv
-fno-strict-aliasing -mms-bitfields -I&q
de two flavors of command_like, one
that uses files it then slurps in and one that uses direct scalars and
EOF detection.
cheers
andrew
>
> A bit of googling Microsoft's documentation suggests that maybe all
> we have to do is pass CreateProcessAsUser's bInheritHandles param
On 07/25/2017 08:58 AM, Amit Kapila wrote:
>
> I think the real question is where do we go from here. Ashutosh has
> proposed a patch up-thread based on a suggestion from Andrew, but it
> is not clear if we want to go there as that seems to be bypassing
> handshake mechanism.
IPC::Run isn't detecting the
exit properly. The workaround I have found to work is to redirect
command_like's output instead to a couple of files and then slurp in
those files and delete them. A bit hacky, I know, so I'm open to other
suggestions.
cheers
andrew
--
Andrew Duns
t;
>
It would be nice if we could teach yhe load mechanism to expand a a
version escape in the MODULE_PATHNAME. e.g.
MODULE_PATHNAME = '$libdir/foo-$version'
cheers
andtrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hear objections I'll prepare a patch along those lines.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On 07/13/2017 10:36 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 07/13/2017 08:08 AM, Ashutosh Sharma wrote:
>>> -dVAR; dXSBOOTARGSAPIVERCHK;
>>> +dVAR; dXSBOOTARGSNOVERCHK;
>> Good job hunting this down!
>> One suggestion I saw in a little
HK;
> +dVAR; dXSBOOTARGSNOVERCHK;
>
> I need to further investigate, but let me know if you have any ideas.
Good job hunting this down!
One suggestion I saw in a little googling was that we add this to the XS
file after the inclusion of XSUB.h:
#undef dXSBOOTARGSAPIVERCHK
#define
gt;
>
Yeah, I have this on one of my Windows boxes, and haven't had time to
get to the bottom of it yet ;-(
Latest versions of ActivePerl don't ship with library descriptor files,
either, which is unpleasant.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadr
On 07/11/2017 12:44 PM, Tom Lane wrote:
>
> Can anyone think of a reason not to pursue that?
>
>
I'm all for it.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Ser
>>>>> "Andrew" == Andrew Gierth writes:
>>>>> "Thomas" == Thomas Munro writes:
Thomas> Here it is. Added to open items.
Andrew> On it.
Committed.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hack
>>>>> "Thomas" == Thomas Munro writes:
Thomas> Here it is. Added to open items.
On it.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Commits pushed.
Unless I broke the buildfarm again (which I'll check up on later), or
some new issue arises with the fixes, this should close all 3 related
items for transition tables.
--
Andrew.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
y. If I do not hear from you by 2017-06-28 06:00 UTC,
Noah> I will transfer this item to release management team ownership
Noah> without further notice.
Sorry for the lack of updates. I need to sleep now, but I will send a
proper status update by 1800 UTC (1900 BST) today (28th).
--
A
On 06/26/2017 10:45 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 06/23/2017 07:47 AM, Andrew Dunstan wrote:
>>> Rerunning with some different settings to see if I can get separate cores.
>> Numerous attempts to get core dumps following methods suggested in
>&g
On 06/26/2017 10:36 AM, Amit Kapila wrote:
> On Fri, Jun 23, 2017 at 9:12 AM, Andrew Dunstan
> wrote:
>>
>> On 06/22/2017 10:24 AM, Tom Lane wrote:
>>> Andrew Dunstan writes:
>>>> Please let me know if there are tests I can run. I missed your earlier
&
On 06/23/2017 07:47 AM, Andrew Dunstan wrote:
>
> On 06/23/2017 12:11 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 06/22/2017 10:24 AM, Tom Lane wrote:
>>>> That earlier request is still valid. Also, if you can reproduce the
>>>> symptom th
s anyway. I expect to have this wrapped up
by 23:59 BST on the 24th.
--
Andrew.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 06/23/2017 12:11 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 06/22/2017 10:24 AM, Tom Lane wrote:
>>> That earlier request is still valid. Also, if you can reproduce the
>>> symptom that lorikeet just showed and get a stack trace from the
>>> (hypo
On 06/22/2017 10:24 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Please let me know if there are tests I can run. I missed your earlier
>> request in this thread, sorry about that.
> That earlier request is still valid. Also, if you can reproduce the
> symptom that lor
tests I can run. I missed your earlier
request in this thread, sorry about that.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
On 06/21/2017 02:25 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 06/21/2017 11:30 AM, Tom Lane wrote:
>>> Andrew Dunstan writes:
>>>> Unfortunately this seems precluded by the use of the non-standard
>>>> "err.h". It looks like that
On 06/21/2017 11:30 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Unfortunately this seems precluded by the use of the non-standard
>> "err.h". It looks like that will trip us up on mingw also.
> Hm, why? Doesn't the -I search path get the right thing?
>
1 - 100 of 10152 matches
Mail list logo
