doc: Turn on generate.consistent.ids parameter
This ensures that automatically generated HTML anchors don't change in
every build.
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/9101688502cc25ed8f521e33de5f1d793aeec9e0
Modified Files
--
doc/src/
doc: Turn on generate.consistent.ids parameter
This ensures that automatically generated HTML anchors don't change in
every build.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/28f8896af0765a05447f605c55fa9f1ab3b41150
Modified Files
--
doc/src/sgml/st
Mark assorted variables PGDLLIMPORT.
This makes life easier for extension authors who wish to support
Windows.
Brian Cloutier, slightly amended by me.
Discussion:
http://postgr.es/m/cajcy68fscdnhmzfps4kyo00cadkvxvea-28h-otenk-pa2o...@mail.gmail.com
Branch
--
REL9_5_STABLE
Details
---
Mark assorted variables PGDLLIMPORT.
This makes life easier for extension authors who wish to support
Windows.
Brian Cloutier, slightly amended by me.
Discussion:
http://postgr.es/m/cajcy68fscdnhmzfps4kyo00cadkvxvea-28h-otenk-pa2o...@mail.gmail.com
Branch
--
REL9_4_STABLE
Details
---
Mark assorted variables PGDLLIMPORT.
This makes life easier for extension authors who wish to support
Windows.
Brian Cloutier, slightly amended by me.
Discussion:
http://postgr.es/m/cajcy68fscdnhmzfps4kyo00cadkvxvea-28h-otenk-pa2o...@mail.gmail.com
Branch
--
REL9_6_STABLE
Details
---
Mark assorted variables PGDLLIMPORT.
This makes life easier for extension authors who wish to support
Windows.
Brian Cloutier, slightly amended by me.
Discussion:
http://postgr.es/m/cajcy68fscdnhmzfps4kyo00cadkvxvea-28h-otenk-pa2o...@mail.gmail.com
Branch
--
master
Details
---
https:/
Mark assorted variables PGDLLIMPORT.
This makes life easier for extension authors who wish to support
Windows.
Brian Cloutier, slightly amended by me.
Discussion:
http://postgr.es/m/cajcy68fscdnhmzfps4kyo00cadkvxvea-28h-otenk-pa2o...@mail.gmail.com
Branch
--
REL9_3_STABLE
Details
---
Mark assorted variables PGDLLIMPORT.
This makes life easier for extension authors who wish to support
Windows.
Brian Cloutier, slightly amended by me.
Discussion:
http://postgr.es/m/cajcy68fscdnhmzfps4kyo00cadkvxvea-28h-otenk-pa2o...@mail.gmail.com
Branch
--
REL_10_STABLE
Details
---
postgres_fdw: Judge password use by run-as user, not session user.
This is a backward incompatibility which should be noted in the
release notes for PostgreSQL 11.
For security reasons, we require that a postgres_fdw foreign table use
password authentication when accessing a remote server, so tha
Robert,
* Robert Haas ([email protected]) wrote:
> postgres_fdw: Judge password use by run-as user, not session user.
There was apparently a regression test that was broken by this and is
making the buildfarm rather unhappy..
Thanks!
Stephen
signature.asc
Description: Digital signature
On Tue, Dec 5, 2017 at 1:03 PM, Stephen Frost wrote:
> * Robert Haas ([email protected]) wrote:
>> postgres_fdw: Judge password use by run-as user, not session user.
>
> There was apparently a regression test that was broken by this and is
> making the buildfarm rather unhappy..
Oops. Sorry.
postgres_fdw: Fix failing regression test.
Commit ab3f008a2dc364cf7fb75de0a691fb0c61586c8e broke this.
Report by Stephen Frost.
Discussion: http://postgr.es/m/[email protected]
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/82c5c533d1f55df
Hi,
On 2017-12-05 12:59:21 +1300, Thomas Munro wrote:
> src/backend/commands/explain.c | 58 ++--
This didn't actually include nodeHash.h, therefore
ExecHashGetInstrumentation() didn't have a prototype. I added the
relevant include and remove the hashjoin.h include which isn
Fix EXPLAIN ANALYZE of hash join when the leader doesn't participate.
If a hash join appears in a parallel query, there may be no hash table
available for explain.c to inspect even though a hash table may have
been built in other processes. This could happen either because
parallel_leader_partici
On 11/28/17 13:35, Peter Eisentraut wrote:
> On 11/28/17 11:35, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> PL/Python: Fix potential NULL pointer dereference
>>
>> I do not think it's correct to just "return" out of the middle
>> of a PG_TRY block --- doesn't that result in failing to pop the
Fix accumulation of parallel worker instrumentation.
When a Gather or Gather Merge node is started and stopped multiple
times, the old code wouldn't reset the shared state between executions,
potentially resulting in dramatically inflated instrumentation data
for nodes beneath it. (The per-worker
Fix accumulation of parallel worker instrumentation.
When a Gather or Gather Merge node is started and stopped multiple
times, the old code wouldn't reset the shared state between executions,
potentially resulting in dramatically inflated instrumentation data
for nodes beneath it. (The per-worker
Peter Eisentraut writes:
> On 11/28/17 13:35, Peter Eisentraut wrote:
>> OK, I'll revert and rethink.
> How about this instead?
This looks better, but I think there are a couple more things:
* Seems like you ought to s/Py_DECREF(result)/Py_XDECREF(result)/ in the
PG_CATCH block (line 451 in HEA
On Wed, Dec 6, 2017 at 8:03 AM, Andres Freund wrote:
> On 2017-12-05 12:59:21 +1300, Thomas Munro wrote:
>> src/backend/commands/explain.c | 58 ++--
>
> This didn't actually include nodeHash.h, ...
Ugh, I'd lost -Werror from my COPT. Back in there it goes.
> Pushed, thank
doc: Update memory requirements for FOP
Reported-by: Dave Page
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/8097d189ccc2cd55a8bf189bd21cb196e3cfc385
Modified Files
--
doc/src/sgml/docguide.sgml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions
doc: Update memory requirements for FOP
Reported-by: Dave Page
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/54b5c8c2f1168108305f1ba3f036af679bbda252
Modified Files
--
doc/src/sgml/docguide.sgml | 6 +++---
1 file changed, 3 insertions(+), 3 de
Support Parallel Append plan nodes.
When we create an Append node, we can spread out the workers over the
subplans instead of piling on to each subplan one at a time, which
should typically be a bit more efficient, both because the startup
cost of any plan executed entirely by one worker is paid o
Fix broken markup.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/7404704a0c5abf0510a9cd889bd867ce46bdfc4c
Modified Files
--
doc/src/sgml/config.sgml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Robert Haas writes:
> Support Parallel Append plan nodes.
Buildfarm member sidewinder doesn't like this:
Program terminated with signal SIGABRT, Aborted.
#0 0x7f7ff5b0e01a in _lwp_kill () from /usr/lib/libc.so.12
#0 0x7f7ff5b0e01a in _lwp_kill () from /usr/lib/libc.so.12
#1 0x7f7f
doc: Flex is not a GNU package
Remove the designation that Flex is a GNU package. Even though Bison is
a GNU package, leave out the designation to not make the sentence
unnecessarily complicated.
Author: Pavan Maddamsetti
Branch
--
master
Details
---
https://git.postgresql.org/pg/comm
Adjust regression test cases added by commit ab7271677.
I suppose it is a copy-and-paste error that this test doesn't actually
test the "Parallel Append with both partial and non-partial subplans"
case (EXPLAIN alone surely doesn't qualify as a test of executor
behavior). Fix that.
Also, add cos
I wrote:
> Robert Haas writes:
>> Support Parallel Append plan nodes.
> Buildfarm member sidewinder doesn't like this:
It transpires that my machine prairiedog also shows the failure.
I instrumented nodeAppend.c (as per attached patch) to see what
was going on, and I get this trace on prairiedog
Hi,
On 2017-12-05 23:01:59 -0500, Tom Lane wrote:
> I conclude that the reason we don't see the crash except on the slowest
> buildfarm critters is that on most machines the leader process manages
> to finish off all the subplans before any of the workers get as far as
> doing something. This doe
Thanks Tom for the crash analysis, I think this is the same reason that
Rajkumar's reported case[1] was crashing only with partition-wise-join = on.
I tried to fix this crash[2] but missed the place where I have added assert
check in the assumption that we always coming from the previous check in t
29 matches
Mail list logo
