On 10/26/2017 12:12 AM, Michael Paquier wrote:
> On Wed, Oct 25, 2017 at 5:24 AM, Andrew Dunstan <and...@dunslane.net> wrote:
>> Process variadic arguments consistently in json functions
>>
>> json_build_object and json_build_array and the jsonb equivalents did not
&g
On 10/22/2017 04:35 PM, Michael Paquier wrote:
> On Mon, Oct 23, 2017 at 1:44 AM, Andrew Dunstan
> <andrew.duns...@2ndquadrant.com> wrote:
>
>> here's a patch that works that way, based on Michael's code.
> Patch not attached :)
> I still have a patch half-cooked, t
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 <t...@sss.pgh.pa.us> wrote:
>>> I don't think collecting all the arguments is particularly special ---
>>> for
On 10/13/2017 08:09 AM, Thomas Munro wrote:
> On Fri, Oct 13, 2017 at 1:42 PM, Andrew Dunstan
> <andrew.duns...@2ndquadrant.com> 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 wher
>
>
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.
cheers
On 10/12/2017 06:46 PM, Thomas Munro wrote:
> On Fri, Oct 13, 2017 at 10:57 AM, Andrew Dunstan
> <andrew.duns...@2ndquadrant.com> wrote:
>> Actually, that didn't take too long.
>>
>> No testing yet, but this runs a build successfully:
>&g
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 that
>
k.
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 Dunstanhttps
On 09/27/2017 02:52 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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 o
On 10/03/2017 04:43 PM, Tom Lane wrote:
> Andres Freund <and...@anarazel.de> 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 d
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 via pgsql-hackers mail
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);
>>
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 <andrew.duns...@2ndquadrant.com> writes:
>>> On 09/30/2017 10:32 PM, Andres Freund wrote:
>>>> Heh. I'm inclined to take it out. We could add a --us
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
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 <andrew.duns...@2ndquadrant.com> 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 sett
'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-hackers@postgresql.org)
To make
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 Dunstanhttps://
> 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, Remote DBA, T
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 Dunstan
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, Remote DBA
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 header file comments
about the unwisdom of using get_expr_result_tupdesc().
I do think that treating a function returning a domain-over-composite
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 that the
changes to ArrayCoerceExpr don't have a significant performance impa
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 require a
unction 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 your subscription:
htt
ure, 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 of a bad bunch of choices.
Second choice migh
On 09/25/2017 01:34 PM, David E. Wheeler wrote:
> On Sep 25, 2017, at 10:55, Andrew Dunstan <andrew.duns...@2ndquadrant.com>
> 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?
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 the message definitions to interpret the
On 09/25/2017 10:42 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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
On 09/25/2017 10:14 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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 e
.
>
>
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
ere 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 DBA, Training & Se
On 09/24/2017 04:37 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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.
On 09/23/2017 06:06 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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 n
On 09/23/2017 03:52 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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
On 09/23/2017 02:00 PM, Tom Lane wrote:
> I wrote:
>> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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().
&
On 09/23/2017 11:16 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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
>>
On 09/22/2017 11:19 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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 w
g 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 Support, Remote DBA, Training & Services
--
Sent via pgsql-hacke
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, 24x7 Support, Remote DBA, Tr
On 09/21/2017 09:41 PM, Andres Freund wrote:
> On 2017-09-21 09:30:31 -0400, Tom Lane wrote:
>> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>>> The speed of memset is hardly going to be the dominating factor in a
>>> 'CREATE DATABASE' command, so we
ersion is still points
> 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
On 09/21/2017 02:53 AM, Haribabu Kommi wrote:
>
>
> On Thu, Sep 21, 2017 at 12:26 PM, Andrew Dunstan
> <andrew.duns...@2ndquadrant.com
> <mailto:andrew.duns...@2ndquadrant.com>> wrote:
>
>
>
> On 09/20/2017 08:18 PM, Andrew Dunstan wrote:
>
On 09/20/2017 08:18 PM, Andrew Dunstan wrote:
>
> On 09/20/2017 07:54 PM, Tom Lane wrote:
>> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>>> It's also warning that it will copy 16 bytes to a 13 byte structure at
>>> lines 518, 1293 and 1294 of
On 09/20/2017 07:54 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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
On 09/20/2017 07:32 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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_1j
On 09/20/2017 06:13 PM, Michael Paquier wrote:
> On Thu, Sep 21, 2017 at 7:08 AM, Andrew Dunstan
> <andrew.duns...@2ndquadrant.com> wrote:
>> First, it warns about a couple of unused variables at lines 4553 and
>> 4673 of src/backend/optimizer/path/costsize.c. I thi
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.
cheers
andrew
--
Andrew Dunstan
d 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@postgresql.org)
To make changes t
ot 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 Development, 24x7 Support, Remote DBA, Training & Ser
On 09/19/2017 02:47 PM, Andrew Dunstan wrote:
>
> On 09/19/2017 11:11 AM, Tom Lane wrote:
>> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>>> This seems to have upset a number or animals in the buildfarm.
>> Actually, after looking closer, my advic
On 09/19/2017 11:11 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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 lett
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
t_1.out matches the results in 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.2ndQuadr
and what doesn'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.
chee
On 09/11/2017 01:58 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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 hav
cting an exit
> 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.
cheers
gt;> [...]
>>
>> That revealed a defect in 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 whet
On 08/07/2017 04:20 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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 pu
On 08/07/2017 04:07 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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
On 08/07/2017 03:36 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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
On 08/07/2017 03:21 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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 demonstratin
o 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 running an MSys build and
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 committed th
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 acti
e 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)
To make changes to your s
uch a
thing 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
PostgreSQL Develop
def getlogin
> 520*#undef setjmp*
> ...
> ...
>
> 651 #define times PerlProc_times
> 652 #define waitPerlProc_wait
> 653 *#define setjmp PerlProc_setjmp
>
> *
What is the
On 07/26/2017 11:12 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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 l
On 07/26/2017 09:33 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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
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
>> ch
On 07/25/2017 01:41 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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 l
to the problematic
>>> field(s).
>> Why ccopts 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 com
On 07/25/2017 11:25 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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-dupli
On 07/25/2017 11:11 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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
>
> perl -MExtUtils::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
-f
ike, 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 parameter
> as FALSE not TRUE i
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.
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 Dunstanhttps://www
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
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 changes to
On 07/13/2017 10:36 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>> On 07/13/2017 08:08 AM, Ashutosh Sharma wrote:
>>> -dVAR; dXSBOOTARGSAPIVERCHK;
>>> +dVAR; dXSBOOTARGSNOVERCHK;
>> Good job hunting this down!
>&
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 dXSBOOTARGSAPIVERCHK
ra box - and we have no problems on Linux, only on
> Windows.
>
>
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
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 & Services
>>>>> "Andrew" == Andrew Gierth <and...@tao11.riddles.org.uk> writes:
>>>>> "Thomas" == Thomas Munro <thomas.mu...@enterprisedb.com> writes:
Thomas> Here it is. Added to open items.
Andrew> On it.
Committed.
--
Andre
>>>>> "Thomas" == Thomas Munro <thomas.mu...@enterprisedb.com> 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:
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 your
then reply
Noah> immediately. 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
On 06/26/2017 10:45 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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 dum
On 06/26/2017 10:36 AM, Amit Kapila wrote:
> On Fri, Jun 23, 2017 at 9:12 AM, Andrew Dunstan
> <andrew.duns...@2ndquadrant.com> wrote:
>>
>> On 06/22/2017 10:24 AM, Tom Lane wrote:
>>> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>>>>
On 06/23/2017 07:47 AM, Andrew Dunstan wrote:
>
> On 06/23/2017 12:11 AM, Tom Lane wrote:
>> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>>> On 06/22/2017 10:24 AM, Tom Lane wrote:
>>>> That earlier request is still valid. Also, if you can r
sonal matter delayed things 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 <andrew.duns...@2ndquadrant.com> 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
On 06/22/2017 10:24 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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. Al
ed 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@postgresql.org)
To make
On 06/21/2017 02:25 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>> On 06/21/2017 11:30 AM, Tom Lane wrote:
>>> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>>>> Unfortunately this seems precluded by the use
On 06/21/2017 11:30 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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
1 - 100 of 9987 matches
Mail list logo