Re: [COMMITTERS] Re: pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co

[Michael Paquier]

On Wed, Apr 27, 2016 at 12:04 PM, Andres Freund  wrote:
> On 2016-04-26 22:59:44 -0400, Tom Lane wrote:
>> What's the argument that it makes debugging harder?  Especially if
>> you aren't using it?
>
> If you try to write a V1 function, but forget or mistype/rename the
> function in PG_FUNCTION_INFO_V1, you'll get crashes, at least if you're
> lucky.

At some point we'll surely arrive at dropping it... Now if V0 is
decided to be dropped, making a deprecation notice in the release
notes of major version X and actually dropping it 2-3 years after
would be really welcome to ease the transaction. I am guessing that
you meant that.
-- 
Michael


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Emit invalidations to standby for transactions without xid.

[Andres Freund]

Hi,

On 2016-04-27 03:35:56 +, Andres Freund wrote:
> Emit invalidations to standby for transactions without xid.

Damnit.  I shouldn't have worked on this while tired.  I wanted to
rebase to remove this commit after performing my testing for
http://archives.postgresql.org/message-id/E1avGGa-0007I0-Ua%40gemulon.postgresql.org
. But I somehow only removed the testing commit.

Now that I pushed it, I'm inclined to leave this in. Afaik the only
thing Michael's review has found is one typo and one copy-pasto. But
Simon didn't comment yet on whether he agreed on this path, Simon?

I'm planning, independent of whether people vote for reverting this till
then, on making a backpatchable version of this commit.

Andres


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Emit invalidations to standby for transactions without xid.

[Andres Freund]

Emit invalidations to standby for transactions without xid.

So far, when a transaction with pending invalidations, but without an
assigned xid, committed, we simply ignored those invalidation
messages. That's problematic, because those are actually sent for a
reason.

Known symptoms of this include that existing sessions on a hot-standby
replica sometimes fail to notice new concurrently built indexes and
visibility map updates.

The solution is to WAL log such invalidations in transactions without an
xid. We considered to alternatively force-assign an xid, but that'd be
problematic for vacuum, which might be run in systems with few xids.

Important: This adds a new WAL record, but as the patch has to be
back-patched, we can't bump the WAL page magic. This means that standbys
have to be updated before primaries; otherwise
"PANIC: standby_redo: unknown op code 32" errors can be encountered.

XXX:

Reported-By: Васильев Дмитрий, Masahiko Sawada
Discussion:
CAB-SwXY6oH=9twbkxjtgr4uc1nqt-vpyatxcseme62adwyk...@mail.gmail.com
CAD21AoDpZ6Xjg=gFrGPnSn4oTRRcwK1EBrWCq9OqOHuAcMMC=w...@mail.gmail.com

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/c6ff84b06a68b71719aa1aaa5f6704d8db1b51f8

Modified Files
--
src/backend/access/rmgrdesc/standbydesc.c   | 54 +
src/backend/access/rmgrdesc/xactdesc.c  | 30 ++
src/backend/access/transam/xact.c   | 18 +
src/backend/replication/logical/decode.c|  9 +
src/backend/replication/logical/reorderbuffer.c | 53 +++-
src/backend/storage/ipc/standby.c   | 35 
src/backend/utils/cache/inval.c |  5 ++-
src/include/replication/reorderbuffer.h |  2 +
src/include/storage/standby.h   |  2 +
src/include/storage/standbydefs.h   | 21 ++
10 files changed, 181 insertions(+), 48 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Don't open formally non-existent segments in _mdfd_getseg().

[Andres Freund]

Don't open formally non-existent segments in _mdfd_getseg().

Before this commit _mdfd_getseg(), in contrast to mdnblocks(), did not
verify whether all segments leading up to the to-be-opened one, were
RELSEG_SIZE sized. That is e.g. not the case after truncating a
relation, because later segments just get truncated to zero length, not
removed.

Once a "non-existent" segment has been opened in a session, mdnblocks()
will return wrong results, causing errors like "could not read block %u
in file" when accessing blocks. Closing the session, or the later
arrival of relevant invalidation messages, would "fix" the problem.

That, so far, was mostly harmless, because most segment accesses are
only done after an mdnblocks() call. But since 428b1d6b29ca we try to
open segments that might have been deleted, to trigger kernel writeback
from a backend's queue of recent writes.

To fix check segment sizes in _mdfd_getseg() when opening previously
unopened segments. In practice this shouldn't imply a lot of additional
lseek() calls, because mdnblocks() will most of the time already have
opened all relevant segments.

This commit also fixes a second problem, namely that _mdfd_getseg(
EXTENSION_RETURN_NULL) extends files during recovery, which is not
desirable for the mdwriteback() case.  Add EXTENSION_REALLY_RETURN_NULL,
which does not behave that way, and use it.

Reported-By: Thom Brown
Author: Andres Freund, Abhijit Menon-Sen
Reviewd-By: Robert Haas, Fabien Coehlo
Discussion: CAA-aLv6Dp_ZsV-44QA-2zgkqWKQq=GedBX2dRSrWpxqovXK=p...@mail.gmail.com
Fixes: 428b1d6b29ca599c5700d4bc4f4ce4c5880369bf

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/72a98a639574d2e25ed94652848555900c81a799

Modified Files
--
src/backend/storage/smgr/md.c | 96 +++
1 file changed, 69 insertions(+), 27 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] Re: pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co

[Andres Freund]

On 2016-04-26 22:59:44 -0400, Tom Lane wrote:
> What's the argument that it makes debugging harder?  Especially if
> you aren't using it?

If you try to write a V1 function, but forget or mistype/rename the
function in PG_FUNCTION_INFO_V1, you'll get crashes, at least if you're
lucky.


> I don't particularly buy the "easier exploitation" argument, either.
> You can't create a C function without superuser, and if you've got
> superuser there are plenty of ways to run arbitrary code.

Without pl*u installed, I don't think any of them are as simple as
calling system(). But yea, it's not a very high barrier.


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] Re: pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co

[Tom Lane]

Andres Freund  writes:
> I don't understand why we don't just drop V0. It makes debugging harder,
> exploitation easier (call arbitrary functions), and really has no
> features making it desirable.

What's the argument that it makes debugging harder?  Especially if
you aren't using it?

I don't particularly buy the "easier exploitation" argument, either.
You can't create a C function without superuser, and if you've got
superuser there are plenty of ways to run arbitrary code.

I'd agree that there are no desirable features that would motivate
writing new code in V0.  But that's not the reason for keeping it;
the reason for keeping it is to avoid unnecessarily breaking
existing extension code.

regards, tom lane


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Fix pg_get_functiondef to dump parallel-safety markings.

[Robert Haas]

Fix pg_get_functiondef to dump parallel-safety markings.

Ashutosh Sharma

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/2ac3be2e763d9b971352819f285dd51519e0aeb9

Modified Files
--
src/backend/utils/adt/ruleutils.c | 13 +
1 file changed, 13 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co

[Tom Lane]

Noah Misch  writes:
> On Fri, Apr 22, 2016 at 03:54:48PM +, Tom Lane wrote:
>> Convert contrib/seg's bool-returning SQL functions to V1 call convention.
>> 
>> It appears that we can no longer get away with using V0 call convention
>> for bool-returning functions in newer versions of MSVC.  The compiler
>> seems to generate code that doesn't clear the higher-order bits of the
>> result register, causing the bool result Datum to often read as "true"
>> when "false" was intended.  This is not very surprising, since the
>> function thinks it's returning a bool-width result but fmgr_oldstyle
>> assumes that V0 functions return "char *"; what's surprising is that
>> that hack worked for so long on so many platforms.

> Does this warrant a change to the "Section 2" comment of postgres.h,
> explaining that its precautions no longer suffice everywhere?

Hmmm ... looking at that again, and particularly at the definition
of DatumGetBool, I wonder whether the true problem is that a cast to
bool is being interpreted differently than we expect.  The intention,
as per its comment, is that we should consider only the rightmost byte
of the Datum value but consider any nonzero value of that byte as "true".
But if MSVC is now treating bool according to C99 rules, it might be
interpreting "(bool) (X)" as "(X) != 0".

It would be interesting to find out if VS2015 passes with this commit
reverted and instead defining DatumGetBool as, say,

#define DatumGetBool(X) ((bool) (GET_1_BYTE(X) != 0))

regards, tom lane


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] Re: pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co

[Andres Freund]

On 2016-04-26 22:38:28 -0400, Noah Misch wrote:
> On Fri, Apr 22, 2016 at 03:54:48PM +, Tom Lane wrote:
> > Convert contrib/seg's bool-returning SQL functions to V1 call convention.
> > 
> > It appears that we can no longer get away with using V0 call convention
> > for bool-returning functions in newer versions of MSVC.  The compiler
> > seems to generate code that doesn't clear the higher-order bits of the
> > result register, causing the bool result Datum to often read as "true"
> > when "false" was intended.  This is not very surprising, since the
> > function thinks it's returning a bool-width result but fmgr_oldstyle
> > assumes that V0 functions return "char *"; what's surprising is that
> > that hack worked for so long on so many platforms.
> 
> Does this warrant a change to the "Section 2" comment of postgres.h,
> explaining that its precautions no longer suffice everywhere?

I don't understand why we don't just drop V0. It makes debugging harder,
exploitation easier (call arbitrary functions), and really has no
features making it desirable.

Andres


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] Re: pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co

[Noah Misch]

On Fri, Apr 22, 2016 at 03:54:48PM +, Tom Lane wrote:
> Convert contrib/seg's bool-returning SQL functions to V1 call convention.
> 
> It appears that we can no longer get away with using V0 call convention
> for bool-returning functions in newer versions of MSVC.  The compiler
> seems to generate code that doesn't clear the higher-order bits of the
> result register, causing the bool result Datum to often read as "true"
> when "false" was intended.  This is not very surprising, since the
> function thinks it's returning a bool-width result but fmgr_oldstyle
> assumes that V0 functions return "char *"; what's surprising is that
> that hack worked for so long on so many platforms.

Does this warrant a change to the "Section 2" comment of postgres.h,
explaining that its precautions no longer suffice everywhere?


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Impose a full barrier in generic-xlc.h atomics functions.

[Noah Misch]

Impose a full barrier in generic-xlc.h atomics functions.

pg_atomic_compare_exchange_*_impl() were providing only the semantics of
an acquire barrier.  Buildfarm members hornet and mandrill revealed this
deficit beginning with commit 008608b9d51061b1f598c197477b3dc7be9c4a64.
While we have no report of symptoms in 9.5, we can't rule out the
possibility of certain compilers, hardware, or extension code relying on
these functions' specified barrier semantics.  Back-patch to 9.5, where
commit b64d92f1a5602c55ee8b27a7ac474f03b7aee340 introduced atomics.

Reviewed by Andres Freund.

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/f9989482d0a24cd69f574b805db770980603a5ca

Modified Files
--
src/include/port/atomics/generic-xlc.h | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Impose a full barrier in generic-xlc.h atomics functions.

[Noah Misch]

Impose a full barrier in generic-xlc.h atomics functions.

pg_atomic_compare_exchange_*_impl() were providing only the semantics of
an acquire barrier.  Buildfarm members hornet and mandrill revealed this
deficit beginning with commit 008608b9d51061b1f598c197477b3dc7be9c4a64.
While we have no report of symptoms in 9.5, we can't rule out the
possibility of certain compilers, hardware, or extension code relying on
these functions' specified barrier semantics.  Back-patch to 9.5, where
commit b64d92f1a5602c55ee8b27a7ac474f03b7aee340 introduced atomics.

Reviewed by Andres Freund.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/213c7df0337278c71c98e90605dc83023db1a80e

Modified Files
--
src/include/port/atomics/generic-xlc.h | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: pg_dump: Message style improvements

[Peter Eisentraut]

pg_dump: Message style improvements

forgotten in b6dacc173b6830c515d970698cead9a85663c553

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/3019f432d6fffe6d8e04f5ccc592eb385af96492

Modified Files
--
src/bin/pg_dump/pg_dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: pg_upgrade: Convert old visibility map format to new format.

[Bruce Momjian]

On Fri, Mar 11, 2016 at 05:36:34PM +, Robert Haas wrote:
> pg_upgrade: Convert old visibility map format to new format.
> 
> Commit a892234f830e832110f63fc0a2afce2fb21d1584 added a second bit per
> page to the visibility map, but pg_upgrade has been unaware of it up
> until now.  Therefore, a pg_upgrade from an earlier major release of
> PostgreSQL to any commit preceding this one and following the one
> mentioned above would result in invalid visibility map contents on the
> new cluster, very possibly leading to data corruption.  This plugs
> that hole.
> 
> Masahiko Sawada, reviewed by Jeff Janes, Bruce Momjian, Simon Riggs,
> Michael Paquier, Andres Freund, me, and others.

I have tested the current git trees of all supported versions of
Postgres in all possible pg_upgrade combinations and they all worked
perfectly.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Add a --brief option to git_changelog.

[Tom Lane]

Add a --brief option to git_changelog.

In commit c0b050192, Andres introduced the idea of including one-line
commit references in our major release notes.  Teach git_changelog to
emit a (lightly adapted) version of that format, so that we don't
have to laboriously add it to the notes after the fact.  The default
output isn't changed, since I anticipate still using that for minor
release notes.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/8067c8f86b5f4516ee204a119a750329f7d126ee

Modified Files
--
src/tools/git_changelog | 47 +--
1 file changed, 37 insertions(+), 10 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add putenv support for msvcrt from Visual Studio 2013

[Christian Ullrich]

* 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 attempt to update it.


Four patches attached:

master --- 0001 --- 0002 --- 0003
 \
  `- 0004

0001 is just some various fixes to set the stage.

0002 fixes this "load race" by not remembering a negative result 
anymore. However, ...



If it can happen that a CRT DLL is unloaded before the process exits,
and we cached the module handle while it was loaded, and later
pgwin32_putenv() is called, that won't end well for the process. This
might be a bit far-fetched; I have to see if I can actually make it happen.


... this *can* and does happen, so fixing the load race alone is not 
enough. 0004 fixes the unload race as well, by dropping the entire DLL 
handle/_putenv pointer cache from the function and going through the 
list of DLLs each time.


I tested this with a project 
() that contains two DLLs:


- The first one is built with VS 2013 (debug), as is the server. It
  does not matter what it is built with, except it must not be the same
  as the second DLL. It exports a single function callable from SQL.

- The second one is built with VS 2015 (debug), and again, the exact
  CRT is not important as long as it is not the same as the server
  or the first DLL.

The function does this:

1. It loads the second DLL. This brings in ucrtbased.dll as well.
2. It calls putenv().
3. It unloads the second DLL. This also causes ucrtbased.dll to be
   unloaded because it is not needed anymore.
4. It calls putenv() again.

   - With current master, this works, because pgwin32_putenv(),
 after the first call somewhere early during backend startup,
 never looks for ucrtbased again (including in step 2).

   - With patch 0002 applied, it crashes because pgwin32_putenv(),
 having detected ucrtbased.dll and cached its HMODULE during
 the call in step 2 above, reuses these values after the DLL
 is long gone.

   - With patch 0004 applied as well, it works again because no
 caching is done anymore.

Even with patch 0004, there is still a race condition between the main 
thread and a theoretical additional thread created by some other 
component that unloads some CRT between GetProcAddress() and the 
_putenv() call, but that is hardly fixable.


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 a variable set elsewhere, we have 
a very simple solution: Why don't we simply throw out the whole #ifdef 
_MSC_VER block?


There is another possible fix, ugly as sin, if we really need to keep 
the whole environment update machinery *and* cannot do the full loop 
each time. Patch 0003 pins each CRT when we see it for the first time. 
GET_MODULE_HANDLE_EX_FLAG_PIN is documented as "The module stays loaded 
until the process is terminated, no matter how many times FreeLibrary is 
called", so the unload race cannot occur anymore.


--
Christian

From d74e778d8abbfea244bacbeb352cadc737032e85 Mon Sep 17 00:00:00 2001
From: Christian Ullrich 
Date: Tue, 26 Apr 2016 15:26:14 +0200
Subject: [PATCH 1/3] Cleanups in pgwin32_putenv().

- Added UCRT and all debug CRTs
- Condensed the array to one line per item (it was getting long)
- Test HMODULEs for NULL instead of zero
- Removed unnecessary CloseHandle() call
---
 src/port/win32env.c | 49 -
 1 file changed, 20 insertions(+), 29 deletions(-)

diff --git a/src/port/win32env.c b/src/port/win32env.c
index 7e4ff62..fd6762e 100644
--- a/src/port/win32env.c
+++ b/src/port/win32env.c
@@ -45,33 +45,25 @@ pgwin32_putenv(const char *envval)
PUTENVPROC  putenvFunc;
}   rtmodules[] =
{
-   {
-   "msvcrt", 0, NULL
-   },  /* Visual 
Studio 6.0 / mingw */
-   {
-   "msvcr70", 0, NULL
-   },  /* Visual 
Studio 2002 */
-   {
-   "msvcr71", 0, NULL
-   },  /* Visual 
Studio 2003 */
-   {
-   "msvcr80", 0, NULL
-   },  /* Visual 
Studio 2005 */
-   {
-   "msvcr90", 0, NULL
-   },  /* Visual 
Studio 2008 */
-   {
-   "msvcr100", 0, NULL
-   },  /* 

[COMMITTERS] pgsql: Fix tsearch docs

[Teodor Sigaev]

Fix tsearch docs

Remove mention of setweight(tsquery) which wasn't included in 9.6. Also
replace old forgotten phrase operator to new one.

Dmitry Ivanov

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/f1e3c76066f0066a8a9bb09b80cd97f11e4b2dc4

Modified Files
--
doc/src/sgml/textsearch.sgml | 30 +-
1 file changed, 1 insertion(+), 29 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Fix order of shutdown cleanup operations in PostgresNode.pm.

[Tom Lane]

Fix order of shutdown cleanup operations in PostgresNode.pm.

Previously, database clusters created by a TAP test were shut down by
DESTROY methods attached to the PostgresNode objects representing them.
The trouble with that is that if the objects survive into the final global
destruction phase (which they do), Perl executes the DESTROY methods in an
unspecified order.  Thus, the order of shutdown of multiple clusters was
indeterminate, which might lead to not-very-reproducible errors getting
logged (eg from a slave whose master might or might not get killed first).
Worse, the File::Temp objects representing the temporary PGDATA directories
might get destroyed before the PostgresNode objects, resulting in attempts
to delete PGDATA directories that still have live servers in them.  On
Windows, this would lead to directory deletion failures; on Unix, it
usually had no effects worse than erratic "could not open temporary
statistics file "pg_stat/global.tmp": No such file or directory" log
messages.

While none of this would affect the reported result of the TAP test, which
is already determined, it could be very confusing when one is trying to
understand from the logs what went wrong with a failed test.

To fix, do the postmaster shutdowns in an END block rather than at object
destruction time.  The END block will execute at a well-defined (and
reasonable) time during script termination, and it will stop the
postmasters in order of PostgresNode object creation.  (Perhaps we should
change that to be reverse order of creation, but the main point here is
that we now have control which we did not before.)  Use "pg_ctl stop", not
an asynchronous kill(SIGQUIT), so that we wait for the postmasters to shut
down before proceeding with directory deletion.

Deletion of temporary directories still happens in an unspecified order
during global destruction, but I can see no reason to care about that
once the postmasters are stopped.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/08af9219060a9526c69f5408b80eee0aa8f707e9

Modified Files
--
src/test/perl/PostgresNode.pm | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Yet more portability hacking for degree-based trig functions.

[Tom Lane]

Yet more portability hacking for degree-based trig functions.

The true explanation for Peter Eisentraut's report of inexact asind results
seems to be that (a) he's compiling into x87 instruction set, which uses
wider-than-double float registers, plus (b) the library function asin() on
his platform returns a result that is wider than double and is not rounded
to double width.  To fix, we have to force the function's result to be
rounded comparably to what happened to the scaling constant asin_0_5.
Experimentation suggests that storing it into a volatile local variable is
the least ugly way of making that happen.  Although only asin() is known to
exhibit an observable inexact result, we'd better do this in all the places
where we're hoping to get an exact result by scaling.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/82311bcdd76904b2cee7567e14e9fb0cf6c6178c

Modified Files
--
src/backend/utils/adt/float.c | 64 ---
1 file changed, 54 insertions(+), 10 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Enable parallel query by default.

[Robert Haas]

Enable parallel query by default.

Change max_parallel_degree default from 0 to 2.  It is possible that
this is not a good idea, or that we should go with 1 worker rather
than 2, but we won't find out without trying it.  Along the way,
reword the documentation for max_parallel_degree a little bit to
hopefully make it more clear.

Discussion: 20160420174631.3qjjhpwsvvx5b...@alap3.anarazel.de

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/77cd477c4ba885cfa1ba67beaa82e06f2e182b85

Modified Files
--
doc/src/sgml/config.sgml  | 12 
src/backend/optimizer/path/costsize.c |  2 +-
src/backend/utils/misc/guc.c  |  2 +-
src/backend/utils/misc/postgresql.conf.sample |  2 +-
4 files changed, 11 insertions(+), 7 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Fix typo in comment

[Magnus Hagander]

Fix typo in comment

Author: Daniel Gustafsson

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/b7351ced425f3937f0a61adb4ade1d4b93bf751d

Modified Files
--
src/backend/executor/execProcnode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers