[HACKERS] Re: [COMMITTERS] pgsql: Respect TEMP_CONFIG when running contrib regression tests.

On 02/26/2016 10:59 PM, Robert Haas wrote: On Sat, Feb 27, 2016 at 9:00 AM, Andrew Dunstan wrote: Sure. Saving three lines of Makefile duplication is hardly a world-shattering event, so I thought there might be some other purpose. But I'm not against saving three lines of duplic

[HACKERS] Re: [COMMITTERS] pgsql: Respect TEMP_CONFIG when running contrib regression tests.

On 02/27/2016 09:25 AM, Robert Haas wrote: On Sat, Feb 27, 2016 at 7:08 PM, Andrew Dunstan wrote: What I had in mind was something like the attached. In testing this seems to do the right thing, and the nice part is that it will be picked up by the buildfarm in the one case that's rel

Re: [HACKERS] Re: [COMMITTERS] pgsql: Respect TEMP_CONFIG when running contrib regression tests.

On 02/27/2016 01:24 PM, John Gorman wrote: On Sat, Feb 27, 2016 at 9:25 AM, Robert Haas <mailto:robertmh...@gmail.com>> wrote: On Sat, Feb 27, 2016 at 7:08 PM, Andrew Dunstan mailto:and...@dunslane.net>> wrote: > Perhaps what we need to do is modify pg_reg

Re: [HACKERS] Equivalent of --enable-tap-tests in MSVC scripts

On 03/01/2016 08:00 AM, Michael Paquier wrote: Hi all, As of now the MSVC scripts control if TAP tests are enabled or not using a boolean flag as $config->{tap_tests}. However, this flag is just taken into account in vcregress.pl, with the following issues: 1) config_default.pl does not list t

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/03/2016 09:02 AM, Michael Paquier wrote: Hi all, Microsoft provides a set of VMs that one can use for testing and Windows 10 is in the set: https://dev.windows.com/en-us/microsoft-edge/tools/vms/windows/ I have grabbed one and installed the community version of Visual Studio 2015 so I th

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/05/2016 12:46 AM, Tom Lane wrote: Michael Paquier writes: On Sat, Mar 5, 2016 at 1:41 PM, Petr Jelinek wrote: I vote for just using sed considering we need flex and bison anyway. OK cool, we could go with something else than sed to generate probes.h but that seems sensible considerin

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/05/2016 01:31 PM, Michael Paquier wrote: On Sat, Mar 5, 2016 at 11:34 PM, Andrew Dunstan wrote: Here is a translation into perl of the sed script, courtesy of the s2p incarnation of psed: <https://gist.github.com/adunstan/d61b1261a4b91496bdc6> The sed script appears to have been

Re: [HACKERS] Allowing to run a buildfarm animal under valgrind

On 03/07/2016 08:39 PM, Andres Freund wrote: Hi, I'm setting up a buildfarm animal that runs under valgrind. Unfortunately there's not really any good solution to force make check et al. to start postgres wrapped in valgrind. For now I've resorted to adding something like sub replace_postgre

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/08/2016 08:32 AM, Michael Paquier wrote: On Mon, Mar 7, 2016 at 10:40 PM, Michael Paquier wrote: On Sun, Mar 6, 2016 at 5:55 AM, Andrew Dunstan wrote: On 03/05/2016 01:31 PM, Michael Paquier wrote: On Sat, Mar 5, 2016 at 11:34 PM, Andrew Dunstan wrote: Here is a translation into

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/08/2016 10:43 AM, Tom Lane wrote: Andrew Dunstan writes: Do we already have a hard dependency on perl for all non-Windows builds? I know it's been discussed but I don't recall. If so, back to what version? I think the policy is we require perl for building from a git pull, b

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/08/2016 11:17 AM, Tom Lane wrote: On the whole, I'd rather that this patch left the non-Windows side alone. OK, that's why I raised the issue. We'll do it that way. As I noted upthread, the sed script has been very stable so the overhead of having to maintain two scripts is pretty mi

Re: [HACKERS] Alter or rename enum value

On 03/09/2016 09:56 AM, Matthias Kurz wrote: Hi! Right now it is not possible to rename an enum value. Are there plans to implement this anytime soon? I had a bit of a discussion on the IRC channel and it seems it shouldn't be that hard to implement this. Again, I am talking about renaming t

Re: [HACKERS] Alter or rename enum value

On 03/09/2016 11:07 AM, Tom Lane wrote: Andrew Dunstan writes: On 03/09/2016 09:56 AM, Matthias Kurz wrote: Right now it is not possible to rename an enum value. Are there plans to implement this anytime soon? I don't know of any plans, but it would be a useful thing. I agree it wou

[HACKERS] enums and indexing

Currently we don't have a way to create a GIN index on an array of enums, or to use an enum field in a GIST index, so it can't be used in an exclusion constraint, among other things. I'd like to work on fixing that if possible. Are there any insuperable barriers? If not, what do we need to do?

Re: [HACKERS] Perl's newSViv() versus 64-bit ints?

On 03/11/2016 06:49 PM, Tom Lane wrote: Anybody know what will happen when passing a uint64 to newSViv()? A perl IV is guaranteed large enough to hold a pointer, if that's any help. But for an unsigned value you might be better off calling newSVuv() cheers andre

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/08/2016 07:40 PM, Michael Paquier wrote: On Wed, Mar 9, 2016 at 1:07 AM, Andrew Dunstan wrote: Michael's patch proposes to replace the use of sed to generate probes.h with the perl equivalent everywhere. That has the advantage that we keep to one script to generate probes.h, b

Re: [HACKERS] btree_gin and btree_gist for enums

On 03/18/2016 09:54 AM, Robert Haas wrote: On Thu, Mar 17, 2016 at 11:21 AM, Andrew Dunstan wrote: On 03/17/2016 06:44 AM, Andrew Dunstan wrote: Here is a patch to add enum support to btree_gin and btree_gist. I didn't include distance operations, as I didn't think it terribly

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/20/2016 12:02 AM, Michael Paquier wrote: On Sun, Mar 20, 2016 at 8:06 AM, Andrew Dunstan wrote: Still to do: the non-perl pieces. The patch to address locales is the sensitive part. The patch from Petr is taking the correct approach though I think that we had better simplify it a bit

Re: [HACKERS] btree_gin and btree_gist for enums

On 03/24/2016 12:40 PM, Matt Wilmas wrote: It would be *really* nice to have this in 9.6. It seems it's simply filling out functionality that should already be there, right? An oversight/bug fix so it works "as advertised?" :-) I think that would be stretching the process a bit far. I'

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/25/2016 08:31 AM, Michael Paquier wrote: On Fri, Mar 25, 2016 at 9:09 PM, Robert Haas wrote: On Thu, Mar 24, 2016 at 1:07 PM, Petr Jelinek wrote: On 24/03/16 17:28, Robert Haas wrote: On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier wrote: - 0001 fixes the global declarations of TI

Re: [HACKERS] Alter or rename enum value

On 03/25/2016 04:13 AM, Matthias Kurz wrote: Hopefully at the commitfest at least the transaction limitation will/could be tackled - that would help us a lot already. I don't believe anyone knows how to do that safely. Enums pose special problems here exactly because unlike all other ty

Re: [HACKERS] btree_gin and btree_gist for enums

On 03/24/2016 12:40 PM, Matt Wilmas wrote: (I notice the btree_gin docs don't mention "numeric," but it works.) Numeric does work - we have regression tests to prove it, do we should fix the docs. But I'm also curious to know why apparently we don't have distance operator support for nume

Re: [HACKERS] Alter or rename enum value

On 03/25/2016 03:22 PM, Christophe Pettus wrote: On Mar 25, 2016, at 11:50 AM, Andrew Dunstan wrote: I don't believe anyone knows how to do that safely. The core issue, for me, is that not being able to modify enum values in a transaction breaks a very wide variety of database migr

Re: [HACKERS] Alter or rename enum value

On 03/26/2016 12:35 AM, David G. Johnston wrote: On Friday, March 25, 2016, Andrew Dunstan <mailto:and...@dunslane.net>> wrote: On 03/25/2016 04:13 AM, Matthias Kurz wrote: Hopefully at the commitfest at least the transaction limitation will/could be tackl

Re: [HACKERS] Alter or rename enum value

On 03/26/2016 10:25 AM, Tom Lane wrote: Andrew Dunstan writes: We don't have the luxury of being able to redesign this as a green fields development. I'm not actually convinced that we need to do anything. SQL already has a perfectly good mechanism for enforcing that a column con

Re: [HACKERS] Alter or rename enum value

On 03/27/2016 12:43 AM, Christophe Pettus wrote: On Mar 26, 2016, at 7:40 AM, Andrew Dunstan wrote: It would be nice if we could find a less broad brush approach to dealing with the issue. I don't know how doable this is, but could we use the existing mechanism of marking an index in

Re: [HACKERS] raw output from copy

On 03/28/2016 06:26 PM, Tom Lane wrote: Pavel Stehule writes: [ copy-raw-format-20160227-03.patch ] I looked at this patch. I'm having a hard time accepting that it has a use-case large enough to justify it, and here's the reason: it's a protocol break. Conveniently omitting to update prot

Re: [HACKERS] raw output from copy

On 03/28/2016 11:18 PM, Pavel Stehule wrote: Anyway this is certainly not committable as-is, so I'm setting it back to Waiting on Author. But the fact that both libpq and ecpg would need updates makes me question whether we can safely pretend that

Re: [HACKERS] Alter or rename enum value

On 03/27/2016 10:20 AM, Tom Lane wrote: Andrew Dunstan writes: The more I think about this the more I bump up against the fact that almost anything we do might want to do to ameliorate the situation is going to be rolled back. The only approach I can think of that doesn't suffer from th

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/29/2016 08:48 PM, Michael Paquier wrote: On Wed, Mar 30, 2016 at 12:45 AM, Robert Haas wrote: On Tue, Mar 29, 2016 at 11:31 AM, Petr Jelinek wrote: I have machine ready, waiting for animal name and secret. Great! Nice. Thanks. It will obviously fail until we push the 0002 and 0004

Re: [HACKERS] [postgresSQL] [bug] Two or more different types of constraints with same name creates ambiguity while drooping.

On 03/30/2016 10:21 AM, Tom Lane wrote: Amit Langote writes: On 2016/03/30 15:16, Harshal Dhumal wrote: If we create two different type of constrains (lets say primary key and foreign key) on same table with same name (lets say 'key' ) then its shows same drop query for both constrains. I h

Re: [HACKERS] pgindent-polluted commits

On 01/13/2016 12:13 PM, Tom Lane wrote: Simon Riggs writes: On 13 January 2016 at 14:48, Noah Misch wrote: I've noticed commits, from a few of you, carrying pgindent changes to lines the patch would not otherwise change. Could we review again why this matters? Basically this is trading of

Re: [HACKERS] SET syntax in INSERT

On 01/14/2016 03:00 PM, Marko Tiikkaja wrote: On 2016-01-14 20:50, Vitaly Burovoy wrote: On 1/14/16, Tom Lane wrote: Assume a table with an int-array column, and consider INSERT INTO foo SET arraycol[2] = 7, arraycol[4] = 11; Right part is a column name, not an expression. Isn't it? So "a

Re: [HACKERS] Removing service-related code in pg_ctl for Cygwin

On 01/14/2016 12:38 AM, Michael Paquier wrote: Hi all, Beginning a new thread seems more adapted regarding $subject but that's mentioned here as well: http://www.postgresql.org/message-id/CAB7nPqQXghm_SdB5iniupz1atzMxk=95gv9a8ocdo83sxcn...@mail.gmail.com It happens based on some investigation

Re: [HACKERS] Removing service-related code in pg_ctl for Cygwin

On 01/18/2016 12:38 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: I think we can be a bit more adventurous and remove all the Cygwin-specific code. See attached patch, which builds fine on buildfarm cockatiel. Hopefully you also tested that it builds under MSVC :-) Why would I? This

Re: [HACKERS] Removing service-related code in pg_ctl for Cygwin

On 01/18/2016 03:46 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: On 01/18/2016 12:38 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: I think we can be a bit more adventurous and remove all the Cygwin-specific code. See attached patch, which builds fine on buildfarm cockatiel

Re: [HACKERS] system mingw not recognized

On 01/18/2016 04:11 PM, Igal @ Lucee.org wrote: I posted the error in the docs to pgsql-d...@postgresql.org If it's possible to update it myself via git, or if it should be reported elsewhere -- please advise. 1. Please don't top-post on the PostgreSQL lists. See

[HACKERS] Buildfarm server move

People, Apologies for the late notice. Tomorrow, January 18th, at 4.00 pm US East Coast time (UT - 5.0) we will be moving the buildfarm server from its current home at CommandPrompt, where we have been ever since we started, to a machine that is part of the standard core infrastructure. In do

Re: [HACKERS] Buildfarm server move

On 01/18/2016 05:20 PM, Andrew Dunstan wrote: People, Apologies for the late notice. Tomorrow, January 18th, at 4.00 pm US East Coast time (UT - 5.0) we will be moving the buildfarm server from its current home at CommandPrompt, where we have been ever since we started, to a machine that

Re: [HACKERS] make error - libpqdll.def No such file or directory

On 01/19/2016 01:08 PM, Igal @ Lucee.org wrote: On 1/17/2016 8:17 PM, Igal @ Lucee.org wrote: On 1/17/2016 3:24 PM, Igal @ Lucee.org wrote: When running make I encounter the following error: gcc.exe: error: libpqdll.def: No such file or directory /home/Admin/sources/postgresql-9.5.0/src/Make

Re: [HACKERS] make error - libpqdll.def No such file or directory

On 01/19/2016 02:01 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: jacana does VPATH builds with pretty much this setup all the time. See for example <http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=jacana&dt=2016-01-19%2013%3A00%3A09> Yes, it builds a tree *once*, then d

[HACKERS] Buildfarm server move complete

The buildfarm server move is complete. Thanks to all who helped, especially Stephen Frost. There might be some small performance regressions which we'll be digging into. Next step: move the mailing lists off pgfoundry. The new lists have been set up I will be working on that migration next

Re: [HACKERS] Template for commit messages

On 01/28/2016 09:57 AM, Robert Haas wrote: On Thu, Jan 28, 2016 at 9:52 AM, Tom Lane wrote: Robert Haas writes: On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra wrote: Why can't we do both? That is, have a free-form text with the nuances, and then Reviewed-By listing the main reviewers? The

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On 02/05/2016 08:49 PM, Tom Lane wrote: Yeah, I agree that a GUC for this is quite unappetizing. Agreed. One idea would be to build a hashtable to aid with duplicate detection (perhaps only once the pending-notify list gets long). Another thought is that it's already the case that duplic

Re: [HACKERS] proposal: schema PL session variables

On 02/08/2016 03:16 AM, Pavel Stehule wrote: Hi On Russian PgConf I had a talk with Oleg about missing features in PLpgSQL, that can complicates a migrations from Oracle to PostgreSQL. Currently I see only one blocker - missing protected session variables. PL/SQL has package variables with

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/08/2016 02:15 PM, Tom Lane wrote: Of late, by far the majority of the random-noise failures we see in the buildfarm have come from failure to shut down the postmaster in a reasonable timeframe. An example is this current failure on hornet: http://buildfarm.postgresql.org/cgi-bin/show_st

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/08/2016 10:55 PM, Tom Lane wrote: Noah Misch writes: On Mon, Feb 08, 2016 at 02:15:48PM -0500, Tom Lane wrote: We've seen variants on this theme on half a dozen machines just in the past week --- and it seems to mostly happen in 9.5 and HEAD, which is fishy. It has been affecting only

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/09/2016 03:05 PM, Tom Lane wrote: I wrote: In any case, we should proceed with fixing things so that buildfarm owners can specify a higher shutdown timeout for especially slow critters. I looked into doing this as I suggested yesterday, namely modifying the buildfarm scripts, and soon d

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/09/2016 05:53 PM, Tom Lane wrote: Andrew, I wonder if I could prevail on you to make axolotl run "make check" on HEAD in src/interfaces/ecpg/ until it fails, so that we can see if the logging I added tells anything useful about this. Will do. cheers andre

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/09/2016 06:46 PM, Andrew Dunstan wrote: On 02/09/2016 05:53 PM, Tom Lane wrote: Andrew, I wonder if I could prevail on you to make axolotl run "make check" on HEAD in src/interfaces/ecpg/ until it fails, so that we can see if the logging I added tells anything useful

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/09/2016 07:49 PM, Tom Lane wrote: Andrew Dunstan writes: So running it's not running with fsync off or using the ramdisk for stats_temp_directory. Of course, that doesn't explain why we're not seeing it on branches earlier than 9.5, but it could explain why we're o

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/09/2016 08:49 PM, Tom Lane wrote: Andrew Dunstan writes: On 02/09/2016 07:49 PM, Tom Lane wrote: However, I'd already noted from some other digging in the buildfarm logs that axolotl's speed seems to vary tremendously. I do not know what else you typically run on that har

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/09/2016 10:27 PM, Tom Lane wrote: Noah Misch writes: On Tue, Feb 09, 2016 at 10:02:17PM -0500, Tom Lane wrote: I wonder if it's worth sticking some instrumentation into stats collector shutdown? I wouldn't be surprised if the collector got backlogged during the main phase of testing a

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/09/2016 11:21 PM, Andrew Dunstan wrote: The idea I was toying with is that previous filesystem activity (making the temp install, the server's never-fsync'd writes, etc) has built up a bunch of dirty kernel buffers, and at some point the kernel goes nuts writing all that

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/10/2016 12:53 PM, Tom Lane wrote: Andrew Dunstan writes: Yeah. It's faintly possible that a kernel upgrade will help. Another data point. I have another RPi2B that is running Debian Wheezy rather than the Fedora remix. I'm running the same test on it we ran yesterday on a

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On 02/15/2016 07:57 PM, Tom Lane wrote: Noah Misch writes: On Mon, Feb 15, 2016 at 07:31:40PM -0500, Robert Haas wrote: Oh, crap. I didn't realize that TEMP_CONFIG didn't affect the contrib test suites. Is there any reason for that, or is it just kinda where we ended up? To my knowledge,

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/17/2016 05:14 PM, Tom Lane wrote: Peter Eisentraut writes: On 2/17/16 12:15 PM, Joe Conway wrote: Ok, removed the documentation on the function pg_config() and pushed. I still have my serious doubts about this, especially not even requiring superuser access for this information. Coul

[HACKERS] Release 4.17 of the PostgreSQL Buildfarm client

I have just cut release 4.17 of the PostgreSQL Buildfarm client. It is available at . Changes of note: * use PGCTLTIMEOUT instead of hardcoded timeout settings * shipped config file is renamed to build-farm.conf.sample to avoid over

Re: [HACKERS] [PATCH] Alter or rename enum value

On 09/06/2016 02:30 PM, Tom Lane wrote: Robert Haas writes: On Mon, Sep 5, 2016 at 11:40 PM, Tom Lane wrote: ... And again, it's hard to get excited about having these options for RENAME VALUE when no one has felt a need for them yet in RENAME COLUMN. I'm especially dubious about IF NOT EX

Re: [HACKERS] [PATCH] pgpassfile connection option

On 09/22/2016 10:44 AM, Julian Markwort wrote: Hello psql-hackers! We thought it would be advantageous to be able to specify a 'custom' pgpassfile within the connection string along the lines of the existing parameters sslkey and sslcert. Which is exactly what this very compact patch does.

[HACKERS] pg_upgrade vs user created range type extension

I have just encountered an apparent bug in pg_upgrade (or possibly pg_dump). To recreate, install the cranges extension - which can be obtained via "git clone https://bitbucket.org/adunstan/pg-closed-ranges.git"; - for both 9.4 and 9.5. Create a fresh 9.4 instance, create a database and in i

Re: [HACKERS] pg_upgrade vs user created range type extension

On 09/22/2016 07:33 PM, Tom Lane wrote: Andrew Dunstan writes: I have just encountered an apparent bug in pg_upgrade (or possibly pg_dump). Hmm, it sort of looks like pg_dump believes it should dump the range's constructor function in binary-upgrade mode, while the backend is creatin

Re: [HACKERS] pg_upgrade vs user created range type extension

On 09/23/2016 11:55 AM, Tom Lane wrote: Andrew Dunstan writes: On 09/22/2016 07:33 PM, Tom Lane wrote: If that diagnosis is correct, we should either change pg_dump to not dump that function, or change CREATE TYPE AS RANGE to not auto-create the constructor functions in binary-upgrade mode

Re: [HACKERS] datetime.h defines like PM conflict with external libraries

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

Re: [HACKERS] datetime.h defines like PM conflict with external libraries

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

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

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

Re: [HACKERS] Continuous integration on Windows?

;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

Re: [HACKERS] Continuous integration on Windows?

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

Re: [HACKERS] Continuous integration on Windows?

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

Re: [HACKERS] Still another race condition in recovery TAP tests

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

Re: [HACKERS] Continuous integration on Windows?

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

[HACKERS] Re: [BUGS] BUG #14849: jsonb_build_object doesn't like VARIADIC calls very much

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

[HACKERS] Re: [BUGS] BUG #14849: jsonb_build_object doesn't like VARIADIC calls very much

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

[HACKERS] Re: [COMMITTERS] pgsql: Process variadic arguments consistently in json functions

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

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

On 09/29/2016 05:48 PM, Tom Lane wrote: We might've caught these things earlier if the buildfarm testing included cross-version upgrades, but of course that requires a lot of test infrastructure that's not there ... I have done quite a bit of work on this - see

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

On 09/30/2016 10:25 AM, Tom Lane wrote: Andrew Dunstan writes: On 09/29/2016 05:48 PM, Tom Lane wrote: We might've caught these things earlier if the buildfarm testing included cross-version upgrades, but of course that requires a lot of test infrastructure that's not there ... I

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

On 09/30/2016 12:24 PM, Tom Lane wrote: Andrew Dunstan writes: On 09/30/2016 10:25 AM, Tom Lane wrote: Oh! How would I enable or use that? 1. Pull the latest version of the module from git. 2. enable it in your buildfarm config file 3. do "run_branches.pl --run-all --verbose --test

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

On 10/01/2016 02:01 PM, Tom Lane wrote: Andrew Dunstan writes: On 09/30/2016 12:24 PM, Tom Lane wrote: Seems to be some additional prep work needed somewhere ... No upgrade_install_root at /home/bfarm/bf-scripts/build-farm-4.17/PGBuild/Modules/TestUpgradeXversion.pm line 51. Oh sorry

[HACKERS] pg_upgade vs config

I'm working on updating and making production ready my experimental cross version pg_upgrade testing module for the buildfarm. A couple of things have emerged that are of concern. This module does a much more complete test that our normal test for pg_upgrade, which only checks upgrading the s

Re: [HACKERS] pg_upgade vs config

On 10/02/2016 09:50 AM, Michael Paquier wrote: On Sun, Oct 2, 2016 at 10:40 PM, Andrew Dunstan wrote: It looks like we have some work to do to teach pg_dump about handling access methods in extensions. This doesn't look quite as bad as the first issue, but it's a pity 9.6 escape

Re: [HACKERS] pg_upgade vs config

On 10/02/2016 01:53 PM, Tom Lane wrote: So then why are the pre-upgrade and post-upgrade dumps different? Because pg_dump with --binary-upgrade neglects to emit ALTER EXTENSION bloom ADD ACCESS METHOD bloom; That's what I suspected. which it would need to do in order to make this work ri

Re: [HACKERS] pg_upgade vs config

On 10/02/2016 12:54 PM, Tom Lane wrote: Andrew Dunstan writes: The biggest issue is this: the upgrade fails completely on ltree-plpython and hstore-plpython, presumably because these modules rely on the plpython module being loaded first. pg_upgrade rather simple-mindedly calls LOAD on the

Re: [HACKERS] pg_upgade vs config

On 10/02/2016 07:21 PM, Tom Lane wrote: I wrote: It occurs to me that a back-patchable workaround for this would be to make get_loadable_libraries sort the library names in order by length (and I guess we might as well sort same-length names alphabetically). This would for example guarantee th

Re: [HACKERS] Misidentification of Python shared library

On 10/04/2016 10:43 AM, Tom Lane wrote: While chasing down last night's failure on buildfarm member longfin, I came across an interesting factoid. If you just do ./configure --enable-shared make make install in unmodified Python sources, what you will get is an instal

[HACKERS] cygwin64 assertion failure

lorikeet seems to be stuck running the parallel tests, after having failed an assertion. Here's an excerpt from the log: 2016-10-09 11:52:35.751 EDT [57fa67c3.1148:11] LOG: statement: alter table tenk1 set (parallel_workers = 4); 2016-10-09 11:52:35.753 EDT [57fa67c3.1148:12] LOG: statement

[HACKERS] buildfarm client release 4.18

I have just released buildfarm client version 4.18. In addition to some minor fixes, there are two significant changes: * The client now makes a determined effort to clean up any left over build artefacts from previous runs at the start of a run. It also tries to clean away old socket

Re: [HACKERS] [PATCH] Better logging of COPY queries if log_statement='all'

On 10/17/2016 09:57 AM, Aleksander Alekseev wrote: Hello. Sometimes it's useful to log content of files used in COPY ... TO ... and COPY ... FROM ... queries. Unfortunately PostgreSQL doesn't allow to do it, even if log_statement='all'. Suggested patch fixes this. Log example: ``` LOG: stat

Re: [HACKERS] Speed of user-defined aggregates using array_append as transfn

On 10/28/2016 02:04 PM, Tom Lane wrote: Comments, better ideas? My initial admittedly ugly thought was why not have a second append function that doesn't use expanded arrays? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] Speed of user-defined aggregates using array_append as transfn

On 10/28/2016 03:14 PM, Tom Lane wrote: Andrew Dunstan writes: My initial admittedly ugly thought was why not have a second append function that doesn't use expanded arrays? That won't get us out of the O(N^2) behavior. Also I don't see what's better about it than my

Re: [HACKERS] btree_gin and btree_gist for enums

On 11/04/2016 04:14 PM, Emre Hasegeli wrote: Here is a patch to add enum support to btree_gin and btree_gist. I didn't include distance operations, as I didn't think it terribly important, and there isn't a simple way to compute it sanely and efficiently, so no KNN support. I don't think we ca

Re: [HACKERS] btree_gin and btree_gist for enums

On 11/04/2016 04:14 PM, Emre Hasegeli wrote: The GiST part of it doesn't really work. The current patch compares oids. We need to change it to compare enumsortorder. I could make it fail easily: regression=# create type e as enum ('0', '2', '3'); CREATE TYPE regression=# alter type e add v

Re: [HACKERS] btree_gin and btree_gist for enums

On 11/05/2016 01:13 PM, Tom Lane wrote: Andrew Dunstan writes: On 11/05/2016 11:46 AM, Tom Lane wrote: That may be a good fix for robustness purposes, but it seems pretty horrid from an efficiency standpoint. Where is this call, and should we be modifying it to provide a flinfo? I thought

Re: [HACKERS] Do we need use more meaningful variables to replace 0 in catalog head files?

On 11/11/2016 03:03 AM, Magnus Hagander wrote: On Nov 11, 2016 00:53, "Jan de Visser" > wrote: > > On 2016-11-09 10:47 AM, Tom Lane wrote: > >> Amit Langote > writes: >>> >>> On Wed, Nov 9, 2016 at 11:47 PM, Tom Lane

Re: [HACKERS] Do we need use more meaningful variables to replace 0 in catalog head files?

On 11/13/2016 04:54 AM, Andres Freund wrote: On 2016-11-12 12:30:45 -0500, Andrew Dunstan wrote: On 11/11/2016 11:10 AM, Tom Lane wrote: boolin: OID=1242 proname=boolin proargtypes="cstring" prorettype=bool boolin: prosrc=boolin provolatile=i proparallel=s I have written a l

Re: [HACKERS] Do we need use more meaningful variables to replace 0 in catalog head files?

On 11/13/2016 11:11 AM, Tom Lane wrote: Andrew Dunstan writes: I'm not convinced the line prefix part is necessary, though. What I'm thinking of is something like this: PROCDATA( oid=1242 name=boolin isstrict=t volatile=i parallel=s nargs=1 rettype=bool argtypes="cstr

[HACKERS] postgres_fdw and defaults

I know we've discussed this before, but I have just had the unpleasant experience of trying to get around the difficulty of inserting into a foreign table with a serial field, surely a common enough scenario that we should try to deal with it better. The solution of using a local sequence rea

Re: [HACKERS] postgres_fdw and defaults

On 11/15/2016 10:49 AM, Tom Lane wrote: Andrew Dunstan writes: I know we've discussed this before, but I have just had the unpleasant experience of trying to get around the difficulty of inserting into a foreign table with a serial field, surely a common enough scenario that we should t

Re: [HACKERS] Re: [COMMITTERS] pgsql: Build HTML documentation using XSLT stylesheets by default

On 11/16/2016 09:46 AM, Tom Lane wrote: Erik Rijkers writes: This xslt build takes 8+ minutes, compared to barely 1 minute for 'oldhtml'. I'm just discovering the same. I'd say that is a strong disadvantage. I'd say that is flat out unacceptable. I won't ever use this toolchain if it's

[HACKERS] Mail thread references in commits

I love seeing references to email threads in commit messages. It would make them a lot friendlier though if a full http URL were included instead of just a Message-ID, i.e. instead of put . I know this is a bit more trouble. but not that m

Re: [HACKERS] Mail thread references in commits

On 11/17/2016 04:06 PM, Andres Freund wrote: On November 17, 2016 1:02:38 PM PST, Andrew Dunstan wrote: I love seeing references to email threads in commit messages. It would make them a lot friendlier though if a full http URL were included instead of just a Message-ID, i.e. instead of

  1   2   3   4   5   6   7   8   9   10   >