* Michael Meskes wrote:
>> It's not just thrips. Of the Windows machines that have reported in
>> since
>> that commit, only currawong and baiji passed. Although lorikeet,
>> woodlouse, bowerbird, and brolga are showing green, this proves
>> nothing
>> because they're all configured to skip the
* Michael Meskes wrote:
The v3 patch looks good to me. I've changed this patch status to Ready
for Committer.
Thank you all, committed.
The buildfarm says that sorting is frequently done case-sensitively:
*** 1,2
- josh 1.00 10.00
Ram 00.00 21.00
--- 1,2
Ram 11
* On 2017-06-21 02:06, Haribabu Kommi wrote:
Thanks for the review. Here I attached an updated patch with README update.
Hello,
the most recent update to VS 2017, version 15.3, now identifies as
"14.11" rather than "14.10" in the output of nmake /?. Simply adding
this value to the two place
Christian
From 5dee698f4cef684a320ced59b19cd4fea61319fb Mon Sep 17 00:00:00 2001
From: Christian Ullrich
Date: Wed, 14 Jun 2017 22:18:18 +0200
Subject: [PATCH] Make setlocale() aware of multithreading to avoid crash.
---
src/interfaces/ecpg/test/expected/thread-alloc.c | 39 +++--
.../ecpg/test/
* Andrew Dunstan wrote:
On 06/11/2017 11:33 AM, Christian Ullrich wrote:
To build correctly, it requires defining _WIN32_WINNT to be 0x600 or
above (and using an SDK that knows about InitOnceExecuteOnce()).
We already define _WIN32_WINNT to be 0x0600 on all appropriate platforms
(Vista
Hello,
my buildfarm animal woodlouse (Visual Studio 2013 on Windows 7) stopped
working correctly some months ago. After Tom kindly prodded me into
fixing it, I noticed that I had configured it to skip the ecpg-check
step because one of the tests in the "thread" section (not always the
same) n
* From: Michael Paquier
> With 0005 I am seeing a compilation failure: you need to have the
> declarations in the _MSC_VER block at the beginning of the routine. It
Sorry, too used to C++.
> would be nice to mention in a code comment that this what Noah has
> mentioned upthread: if a CRT loads w
* Michael Paquier wrote:
> On Wed, Nov 16, 2016 at 12:45 PM, Christian Ullrich
> wrote:
>> I also did a debug build with 1+2+4 that came in at 84 μs/iteration.
>
> Moved to next CF. Christian, perhaps this patch should have an extra
> round of reviews?
It is significant
* Noah Misch wrote:
> On Tue, Apr 26, 2016 at 07:39:29PM +0200, Christian Ullrich
> wrote:
> > * Christian Ullrich wrote:
> Patch 1 looks good, except that it should be three patches:
>
> - cosmetic parts: change whitespace and s/0/NULL/
> - remove CloseHandle() call
attached, also reordering the ecpg-clean command line in clean.bat
to match the others that have the project file first.
--
Christian
>From 09a5f3945e2b87b56ca3525a56db970e9ecf8ffd Mon Sep 17 00:00:00 2001
From: Christian Ullrich
Date: Thu, 8 Sep 2016 08:34:45 +0200
Subject: [PATCH] Let MSBFL
* Michael Paquier wrote:
On Tue, Sep 6, 2016 at 5:36 PM, Christian Ullrich wrote:
* Michael Paquier wrote:
In order to avoid any problems with the load and unload windows, my
bet goes for 0001, 0002 and 0003, with the last two patches merged
together, 0001 being only a set of independent
* Michael Paquier wrote:
On Thu, Sep 1, 2016 at 4:03 PM, Christian Ullrich wrote:
My conclusion from April stands:
The fact that master looks like it does means that there have not been
many (or any) complaints about missing cross-module environment
variables. If nobody ever needs to see
* Michael Paquier wrote:
On Mon, Sep 5, 2016 at 9:18 AM, Noah Misch wrote:
Every vcbuild and msbuild invocation ought to recognize this variable, so
please update the two places involving ecpg_regression.proj. Apart from that,
the patch looks good.
Good catch. I did not notice those durin
* Michael Paquier wrote:
> On Wed, Apr 27, 2016 at 2:39 AM, Christian Ullrich
wrote:
>> * Christian Ullrich wrote:
> And actually, by looking at those patches, isn't it a dangerous
> practice to be able to load multiple versions of the same DLL routines
> in the
* Tom Lane wrote:
So I think we should solve these problems at a stroke, and save ourselves
lots of breath in the future, by getting rid of the whole "major major"
idea and going over to a two-part version numbering scheme. To be
specific:
* This year's major release will be 9.6.0, with minor
Hello,
here is a patch for the German translation that removes (all) five
instances of *the* most annoying mistake ever.
By the way, is there any documentation anywhere about how and where to
send translation patches? I'm just guessing here.
--
Christian
diff --git a/de/postgres.po b/de/po
* Tom Lane wrote:
Christian Ullrich writes:
I suggest writing "use the Kerberos realm name for authentication
instead of the NetBIOS name" either in place of the existing description
or together with it.
OK, how about this:
Add new SSPI authentication
* Tom Lane wrote:
I've pushed a first cut at release notes for 9.6. There's a good deal
of work to do yet:
+
+
+Add new SSPI authentication parameters compat_realm
+and upn_usename, to make it possible to make SSPI
+work more like GSSAPI (Christi
* Andrew Dunstan wrote:
Support building with Visual Studio 2015
http://git.postgresql.org/pg/commitdiff/da52474f3d3cbdf38d8a6677a4ebedaf402ade3a
diff --git a/src/port/win32env.c b/src/port/win32env.c
index 7e4ff62..d6b0ebe 100644 (file)
--- a/src/port/win32env.c
+++ b/src/port/win32env.c
@@ -
* Michael Paquier wrote:
On Wed, Apr 27, 2016 at 5:15 PM, Christian Ullrich wrote:
OK then, hopefully last round attached.
Thanks. Those are fine in my view. It is hard to tell if a committer
is going to have a look at that soon, so I think that it would be
wiser to add that to the next CF
* From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> On Wed, Apr 27, 2016 at 4:06 PM, Christian Ullrich
> wrote:
> > * From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> >> vcbuild also supports /m. Wouldn't it make sense to have a environment
> &g
* From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> On Tue, Apr 26, 2016 at 10:09 PM, Christian Ullrich
> wrote:
>
> -build DEBUG
> +build -c DEBUG
>
> To build just a single project, for example psql, run the commands:
>
> build psql
> -buil
* Christian Ullrich wrote:
wrong even without considering the debug/release split. If we load a
compiled extension built with a CRT we have not seen yet, _after_ the
first call to pgwin32_putenv(), that module's CRT's view of its
environment will be frozen because we will never
onal fix required is to put gendef.pl's "symbols.out" file
into the directory it is working on, rather than the source tree root,
to avoid collisions that cause the parallel build to fail otherwise.
--
Christian
From 4b455e1ac38f1441f1faf695da4be8c5eb478970 Mon Sep 17 00:00:00 2001
* Christian Ullrich wrote:
* Andrew Dunstan wrote:
What if both are present? Is a release build prevented from loading a
debug dll and vice versa?
Debug and release are simply two separate CRTs. If your process contains
a module that needs the one, and another that needs the other, you
* Andrew Dunstan wrote:
On 04/25/2016 09:27 AM, Christian Ullrich wrote:
* Magnus Hagander wrote:
On Sun, Apr 24, 2016 at 9:56 PM, Christian Ullrich
wrote:
Just noticed something. This DLL detection by name has never worked in
debug builds where the DLL names end in "d"
* Magnus Hagander wrote:
On Sun, Apr 24, 2016 at 9:56 PM, Christian Ullrich
wrote:
* Magnus Hagander wrote:
Add putenv support for msvcrt from Visual Studio 2013
http://git.postgresql.org/pg/commitdiff/9f633b404cb3be6139f8dfdea00538489ffef9ab
Just noticed something. This DLL detection by
* Magnus Hagander wrote:
Add putenv support for msvcrt from Visual Studio 2013
This was missed when VS 2013 support was added.
Michael Paquier
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/9f633b404cb3be6139f8dfdea00538489ffef9ab
Just noticed something. This
* Andrew Dunstan wrote:
OK, here's my final version of the patch, which I will apply in 24 hours
or so unless there is an objection.
+ Visual Studio 2008 and above. Compilation
+ is supported down to Windows XP and
+ Windows Server 2003 when building with
+ Visual Studio 2005 to
+ Visual
* Andrew Dunstan wrote:
On 04/24/2016 03:16 PM, Christian Ullrich wrote:
* Andrew Dunstan wrote:
msvcr120.dll seems to be the highest numbered one on my system, and we
already cover that. If you like we can add to the comments in that file.
There won't be a higher one, with VS 2015
* Andrew Dunstan wrote:
On 04/24/2016 12:14 PM, Tom Lane wrote:
Andrew Dunstan writes:
OK, here's my final version of the patch, which I will apply in 24 hours
or so unless there is an objection.
BTW, in view of 9f633b404, shouldn't there be a similar addition to
win32env.c in this patch
* Andrew Dunstan wrote:
On 04/22/2016 01:21 AM, Michael Paquier wrote:
5. It also complains about us casting a pid_t to a HANDLE in
pg_basebackup.c. Not sure what to do about that.
The thing that's being cast is not a PID, but a HANDLE to a process.
pid_t is a typedef for int (in port/win32.
* Christian Ullrich wrote:
* Andrew Dunstan wrote:
On 04/22/2016 02:46 AM, Michael Paquier wrote:
Progress report:
1. My VS 2015 installations (I now have several) all generate
solution file
with:
Microsoft Visual Studio Solution File, Format Version 12.00
so I propose to set that as
* Andrew Dunstan wrote:
On 04/22/2016 02:46 AM, Michael Paquier wrote:
Progress report:
1. My VS 2015 installations (I now have several) all generate
solution file
with:
Microsoft Visual Studio Solution File, Format Version 12.00
so I propose to set that as the solution file version.
>>
* From: Andrew Dunstan [mailto:and...@dunslane.net]
> 4. The compiler complains about one of Microsoft's own header files -
> essentially it dislikes the=is construct:
>
> typedef enum { ... };
>
> It would be nice to make it shut up about it.
I doubt that's possible; the declaration *is* w
* Michael Paquier wrote:
On Wed, Apr 20, 2016 at 1:48 AM, Christian Ullrich wrote:
Both patches behave exactly the same in this test. Of the 102 remaining
locales, I get an unexpected codepage for just four:
- kk: Expected 1251, used 1252
- kk-KZ: Expected 1251, used 1252
- sr: Expected 1251
* Alvaro Herrera wrote:
Michael Paquier wrote:
On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
wrote:
Now, I have produced two patches:
- 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
__crt_locale_data_public in ucrt/corecrt.h. This is definitely an ugly
hack, though I am co
* From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Christian Ullrich writes:
> > * Tom Lane wrote:
> >> Hm, my grep found another one ...
>
> > Oh, sorry. I saw that one, but thought it was intentional because _WIN64
> > is defined automatically anyway.
>
>
* Tom Lane wrote:
Christian Ullrich writes:
According to git grep, this is the only place where WIN64 is used
without the leading underscore.
Hm, my grep found another one ...
Oh, sorry. I saw that one, but thought it was intentional because _WIN64
is defined automatically anyway
.
--
Christian
From 9bc9e8ed79747f7bf3e727c9f64f4a088de589fb Mon Sep 17 00:00:00 2001
From: Christian Ullrich
Date: Mon, 11 Apr 2016 15:47:20 +0200
Subject: [PATCH] Fixed preprocessor condition (WIN64 -> _WIN64).
---
src/test/regress/pg_regress.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
* Andrew Dunstan:
On 04/09/2016 08:43 AM, Christian Ullrich wrote:
Michael Paquier wrote:
I don't think that's good to use malloc in those code paths, and I
Oh?
+#if (_MSC_VER >= 1900)
+ uint32 cp;
+
+ if (GetLocal
> Michael Paquier wrote:
>
> On Sat, Apr 9, 2016 at 7:41 AM, Michael Paquier
> wrote:
>> On Sat, Apr 9, 2016 at 1:46 AM, Christian Ullrich
>> wrote:
>>> * Andrew Dunstan wrote:
>>>>> On 04/08/2016 11:02 AM, Christian Ullrich wrote:
>>&g
* Andrew Dunstan wrote:
On 04/08/2016 11:02 AM, Christian Ullrich wrote:
src/port/chklocale.c(233): warning C4133: 'function': incompatible
types - from 'const char *' to 'LPCWSTR' [...\postgres.vcxproj]
Do you have a fix for the LPCWSTR parameter issue?
* Tom Lane wrote:
+several. Grepping for compiler warnings, for example, is really painful
right now on any MSVC critter. I've resorted to grepping for "warning C",
which skips the noise messages, but I'm never sure if I'm missing
something.
You miss all diagnostics from other tools than the
* Michael Paquier wrote:
On Fri, Apr 8, 2016 at 10:05 PM, Andrew Dunstan wrote:
¥> On 04/08/2016 07:15 AM, Christian Ullrich wrote:
Michael, none of your patches change this, so how does it ever build on
your system?
Luck. I am getting a warning but the code is able to somewhat comp
* Michael Paquier wrote:
> On Fri, Apr 8, 2016 at 9:29 AM, Andrew Dunstan
> wrote:
Not out of the woods yet. Attached is what I got from VS2015 on a fresh W10
VM, with Michael's patch 0002 and 0004 applied.
Interesting, I have no idea what we are doing differently, and seeing
those errors
Hello,
could we perhaps lower the verbosity level of the msvc build (in
src/tools/msvc/build.pl) from "detailed" to "normal"? In my experiment,
this reduces the size of the build log by 96.4 percent (from 12.5 MiB to
438 KiB), or if the log is not redirected, it shortens the build time by
45
* Magnus Hagander wrote:
On Tue, Mar 29, 2016 at 5:09 PM, David Steele wrote:
It seems like this patch should be set "ready for committer". Can one of
the reviewers do that if appropriate?
I'll pick it up to do that as well as committing it.
Magnus, do you intend to commit the patch be
* Petr Jelinek wrote:
On 07/04/16 00:50, Michael Paquier wrote:
On Thu, Apr 7, 2016 at 7:44 AM, Michael Paquier
wrote:
On Thu, Apr 7, 2016 at 6:11 AM, Petr Jelinek
wrote:
On 06/04/16 22:50, Andrew Dunstan wrote:
* VS2015 appears to create version 12 solution files, not
version 14
* Magnus Hagander wrote:
On Tue, Mar 29, 2016 at 5:09 PM, David Steele wrote:
It seems like this patch should be set "ready for committer". Can one of
the reviewers do that if appropriate?
I'll pick it up to do that as well as committing it.
Ah, good news!
I hope it's not coming too la
* Tom Lane wrote:
Christian Ullrich writes:
Anyway, I think Michael's fix is wrong. The bug is that the Win32
version of link() (at the bottom of zic.c) does not set errno if its
attempt to copy the file fails, so what dolink() puts into link_errno is
bogus.
Ah-hah, that explains t
There are some instances of calls to FormatMessage() with the
FORMAT_MESSAGE_FROM_SYSTEM flag that omit the
FORMAT_MESSAGE_IGNORE_INSERTS flag. The effect of that is that if the
requested message string contains any insertion markers, the call to
FormatMessage() will fail because none of these
* Christian Ullrich wrote:
* Tom Lane wrote:
Christian Ullrich writes:
zic aborts somewhere between writing Etc/UTC and UTC.
Huh ... I would not have guessed that. Can you track down exactly
where it's failing?
I'd love to, but with 656ee84 I cannot reproduce on my Windows
* Tom Lane wrote:
Christian Ullrich writes:
zic aborts somewhere between writing Etc/UTC and UTC.
Huh ... I would not have guessed that. Can you track down exactly
where it's failing?
I'd love to, but with 656ee84 I cannot reproduce on my Windows 10
system. I can try on t
* Tom Lane wrote:
Michael Paquier writes:
Buildfarm-not-being-happy-status: woodloose, mastodon, thrips, jacana.
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=woodlouse&dt=2016-03-29%2000%3A42%3A08
The origin of the problem is that, which prevents all the subsequent
queries to fail:
* From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
> Christian Ullrich wrote:
> > * Christian Ullrich wrote:
> >
> > >* From: Magnus Hagander [mailto:mag...@hagander.net]
>
> > >>Code uses a mix of malloc() and palloc() (through sprintf). Is ther
* From: Christian Ullrich
> * From: Robbie Harwood [mailto:rharw...@redhat.com]
>
> > Christian Ullrich writes:
> > > + /* Replace domainname with realm name. */
> > > + if (upnamerealmsize > domainnamesize)
> > > +
On 2016-03-24 16:35, Christian Ullrich wrote:
* From: Robbie Harwood [mailto:rharw...@redhat.com]
Christian Ullrich writes:
pg_SSPI_recvauth(Port *port)
{
int mtype;
+ int status;
The section of this function for include_realm
* From: Robbie Harwood [mailto:rharw...@redhat.com]
> Christian Ullrich writes:
>
> > Updated patch attached.
>
> I unfortunately don't have windows machines to test this on, but I
> thought it might be helpful to review this anyway since I'm touching
> cod
* Christian Ullrich wrote:
* From: Magnus Hagander [mailto:mag...@hagander.net]
I don't like the name "real_realm" as a parameter name. I'm wondering if
it might be better to reverse the meaning, and call it sspi_netbios_realm
(and then change the default to on, to be
* From: Magnus Hagander [mailto:mag...@hagander.net]
> I took a quick look at this one, and have some initial thoughts.
>
> I don't like the name "real_realm" as a parameter name. I'm wondering if
> it might be better to reverse the meaning, and call it sspi_netbios_realm
> (and then change the d
* Alvaro Herrera wrote:
Magnus Hagander wrote:
On Wed, Mar 9, 2016 at 4:36 PM, Christian Ullrich
wrote:
And apparently not a single one with VS 2013. OK, I'll see what I can do
about setting some up soonish, at least with (server) 2008 and (client) 7.
FWIW, I have a local build of
* Magnus Hagander wrote:
I did notice the #ifdef's are actually different in the header and body
section of the patch, which seems wrong. I used the one from the actual
implementation (_M_AMD64) for the header includes as, and also merged the
#ifdef's together to a single #if in each section. Pl
* Magnus Hagander wrote:
On Wed, Mar 9, 2016 at 4:36 PM, Christian Ullrich
wrote:
* Magnus Hagander wrote:
How does this work wrt mingw, though? Do we have the same problem there?
AIUI this code can never run on mingw, correct?
Not unless mingw defines _MSC_VER.
The question is then
* Magnus Hagander wrote:
On Sat, Feb 13, 2016 at 4:45 PM, Christian Ullrich
wrote:
On February 13, 2016 4:10:34 PM Tom Lane wrote:
I'm also suspicious of the "#if _MSC_VER == 1800" tests, that is,
the code compiles on *exactly one* MSVC version.
The bug exists in onl
* Peter Eisentraut wrote:
On 2/12/16 11:24 AM, Christian Ullrich wrote:
Otherwise, it may be time to update the manual (15.6 Supported
Platforms) where it says PostgreSQL "can be expected to work on these
operating systems: [...] Windows (Win2000 SP4 and later), [...]".
Perhaps we
* Andreas 'ads' Scherbaum wrote:
Attached is a new version of the patch, with %lu replaced by %zu.
I re-ran all the tests, especially the long test with 2^32+x rows, and
it produces the same result as before.
To paraphrase Twain: "Sire, the Board finds this patch perfect in all
the requiremen
* From: Christian Ullrich
> On February 13, 2016 4:10:34 PM Tom Lane wrote:
>
> > Christian Ullrich writes:
> > Lastly, I'd like to see some discussion of what side effects
> > "_set_FMA3_enable(0);" has ... I rather doubt that it's really
> >
On February 13, 2016 4:10:34 PM Tom Lane wrote:
> Christian Ullrich writes:
>> * Robert Haas wrote:
>>> Thanks for the report and patch. Regrettably I haven't the Windows
>>> knowledge to have any idea whether it's right or wrong, but hopefully
>>&g
* Robert Haas wrote:
On Fri, Feb 12, 2016 at 7:26 PM, Christian Ullrich wrote:
startup_hacks(), I think. Proposed patch attached.
Thanks for the report and patch. Regrettably I haven't the Windows
knowledge to have any idea whether it's right or wrong, but hopefully
someone
* Christian Ullrich wrote:
Backends (and possibly other processes) crash at the slightest
provocation, such as "SELECT * FROM pg_stat_activity;" or VACUUM. The
log says either "exception 0xC005" (segfault) or "exception
0xC01D" (illegal instruction).
T
Hello,
I just found a compatibility issue when I was migrating an elderly VM to
a new host. The VM is running Windows Server 2008 SP2, and it has the
EDB build of PostgreSQL 9.4.5 on it. (9.4.6 behaves the same.) It is
also not dependent on running in a VM; it would fail on the hardware as
we
Ah, so it turns out I should have used the commitfest tool. My
apologies; I will send the whole thing through that again. Please
disregard the earlier message.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, failed
Spec compliant: not tested
Documentation:not tested
* Andreas 'ads' Scherbaum wrote:
> one of our customers approached us an
* Andreas 'ads' Scherbaum wrote:
one of our customers approached us and complained, that GET DIAGNOSTICS
row_count returns invalid results if the number of rows is > 2^31. It's
Attached patch expands the row_count to 64 bit.
diagnostics=# select testfunc_pg((2^32 + 5)::bigint);
testfun
* Christian Ullrich wrote:
* Christian Ullrich wrote:
* Christian Ullrich wrote:
> According to the release notes, the default for the "include_realm"
> option in SSPI authentication was changed from off to on in 9.5 for
> > improved security. However, the authenticat
Hello,
here's a one-line patch to close a handle leak in pg_SSPI_recvauth().
According to the docs, the token retrieved with
QuerySecurityContextToken() must be closed.
--
Christian
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
new file mode 100644
index 0131bfd..57c2f48
*
* Christian Ullrich wrote:
* Christian Ullrich wrote:
> According to the release notes, the default for the "include_realm"
> option in SSPI authentication was changed from off to on in 9.5 for
> > improved security. However, the authenticated user name, with the
> &
* Michael Paquier wrote:
On Sat, Dec 5, 2015 at 4:38 PM, Christian Ullrich wrote:
I have zero experience with libxml2, so no idea if the previous context
level can be turned on again. IMHO, the libxml2 change is a bug in itself;
PostgreSQL's error messages are more readable with the XML
Hello,
I just noticed that last night all built branches failed on my buildfarm
animal, jaguarundi. They all failed on the "xml" test, and the output is
essentially the same everywhere:
***
*** 9,16
LINE 1: INSERT INTO xmltest VALUES (3, ' SELECT xmlconcat('', NULL, 'stand
* Michael Nolan wrote:
> Why not take a simpler approach and create a zero length file in directories
> that should not be fiddled with by non-experts using a file name something
> like "DO.NOT.DELETE.THESE.FILES"?
Move the critical things into a new subdirectory?
$PGDATA/pg_critical/pg_xlog?
* Peter Eisentraut wrote:
On 5/16/15 12:06 PM, Tom Lane wrote:
As exhibited for instance here:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2015-05-16%2011%3A00%3A07
I've been able to replicate this on a Fedora 21 box: works fine with
Python 2, fails with Python 3. See
* Tom Lane wrote:
Christian Ullrich writes:
* Peter Eisentraut wrote:
On 4/30/15 2:49 PM, Andrew Dunstan wrote:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday runnin
* Peter Eisentraut wrote:
On 4/30/15 2:49 PM, Andrew Dunstan wrote:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running the plpython regression
tests. The only relevant commit
* Andrew Dunstan:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running the plpython regression
tests. The only relevant commit seems to be the transforms feature.
Here's what it's
* Stephen Frost wrote:
RLS fixes, new hooks, and new test module
The buildfarm says that with -DCLOBBER_CACHE_ALWAYS, the RLS violations
get blamed on the wrong tables. Mostly, they are catalogs (I have seen
pg_opclass, pg_am, and pg_amproc), but some also come up with binary
garbage instea
* From: Noah Misch [mailto:n...@leadboat.com]
> Buildfarm member jaguarundi, which has Python 3.4, activated --with-
> python for REL9_1_STABLE as of its 2014-12-15 run. Please remove --
> with-python or test against an older Python. It already omits --with-
> python for REL9_0_STABLE.
Done; so
* Alvaro Herrera wrote:
Michael Paquier wrote:
Btw, perhaps this diff should be pushed as a different patch as this is a
rather different thing:
- if (heapRelation->rd_rel->relpersistence == RELPERSISTENCE_UNLOGGED
&&
+ if (indexRelation->rd_rel->relpersistence ==
RELPERSISTENCE_UN
* From: Noah Misch [mailto:n...@leadboat.com]
> On Mon, Jun 30, 2014 at 07:28:03PM +0000, Christian Ullrich wrote:
> > * From: Noah Misch [mailto:n...@leadboat.com]
> > > I liked the proposal here; was there a problem with it?
> > > http://www.postgres
* From: Noah Misch [mailto:n...@leadboat.com]
> I liked the proposal here; was there a problem with it?
> http://www.postgresql.org/message-
> id/ca+tgmoz3ake4enctmqmzsykc_0pjl_u4c_x47ge48uy1upb...@mail.gmail.com
You're referring to the suggestion of accepting and ignoring the option on
non-Windo
* From: MauMau [mailto:maumau...@gmail.com]
> From: "Christian Ullrich"
> > OK, here is the first draft against current master. It builds on Windows
> > with VS 2012 and on FreeBSD 10 with clang 3.3. I ran the regression
> > tests on Windows, they all pass.
OK, here is the first draft against current master. It builds on Windows
with VS 2012 and on FreeBSD 10 with clang 3.3. I ran the regression
tests on Windows, they all pass.
The changed behavior is limited to Windows, where it now silently
ignores Ctrl-C and Ctrl-Break when started via pg_ctl
* From: Amit Kapila
> On Mon, Apr 14, 2014 at 11:46 AM, Christian Ullrich
> wrote:
> > * From: Amit Kapila
> >> Do you mean to say use some existing environment variable?
> >> Introducing an environment variable to solve this issue or infact
> >> using
* From: Bruce Momjian
> On Mon, Apr 14, 2014 at 09:34:14AM +0530, Amit Kapila wrote:
> > The problem can be solved this way, but the only question here is
> > whether it is acceptable for users to have a new console window for
> > server.
> >
> > Can others also please share their opinion if this
* From: Robert Haas
> On Mon, Apr 14, 2014 at 2:16 AM, Christian Ullrich
> wrote:
> > I meant creating a new one, yes. If, say, PGSQL_BACKGROUND_JOB was
> > set, the postmaster etc. would ignore the events.
>
> Why not just pass a command-line switch?
Because, as I
* From: Amit Kapila
> On Sun, Apr 13, 2014 at 5:59 PM, Christian Ullrich
> wrote:
> > There are some possible solutions:
> >
> > - pg_ctl could set an environment variable (unless it has to be
> > compatible with postmasters from different versions, and it does
* From: Amit Kapila
> On Sat, Apr 12, 2014 at 12:36 PM, Christian Ullrich
> wrote:
> > * From: Amit Kapila
> >
> >> Another thing to decide about this fix is that whether it is okay to
> >> fix it for CTRL+C and leave the problem open for CTRL+
* From: Amit Kapila
> Another thing to decide about this fix is that whether it is okay to fix
> it for CTRL+C and leave the problem open for CTRL+BREAK?
> (The current option used (CREATE_NEW_PROCESS_GROUP) will handle only
> CTRL+C).
I can think of three situations in which a postgres process c
Hello all,
when pg_ctl start is used to run PostgreSQL in a console window on
Windows, it runs in the background (it is terminated by closing the
window, but that is probably inevitable). There is one problem, however:
The first Ctrl-C in that window, no matter in which situation, will
cause
* Tom Lane wrote:
I looked at this patch a bit. I agree that we need to fix
pgwin32_CommandLine to double-quote the executable name, but it needs a
great deal more work than that :-(. Whoever wrote this code was
One additional issue is that the path to the service executable should
use back
1 - 100 of 130 matches
Mail list logo
