Re: [HACKERS] Ordering in guc.c vs. config.sgml vs. postgresql.sample.conf

On Mon, Apr 25, 2016 at 3:58 AM, Andres Freund wrote: > Hi, > > While working on > http://www.postgresql.org/message-id/cabuevezwma9y+bp4fi4fe4hmpfzmjozomulvtbhhpwtcujr...@mail.gmail.com > I once more taken aback by the total lack of consistency between the > three files in

Re: [HACKERS] checkpoint_flush_after documentation inconsistency

On Mon, Apr 25, 2016 at 4:27 AM, Andres Freund wrote: > On 2016-04-21 11:20:38 -0700, Andres Freund wrote: >> On 2016-04-18 14:33:28 +0900, Fujii Masao wrote: >> > On Fri, Apr 15, 2016 at 6:56 PM, Magnus Hagander >> > wrote: >> > > The documentation says

Re: [HACKERS] pg_dump dump catalog ACLs

Noah, all, * Noah Misch (n...@leadboat.com) wrote: > On Fri, Apr 22, 2016 at 12:31:41PM -0400, Stephen Frost wrote: > > After looking through the code a bit, I realized that there are a lot of > > object types which don't have ACLs at all but which exist in pg_catalog > > and were being analyzed

Re: [HACKERS] Why doesn't src/backend/port/win32/socket.c implement bind()?

Michael Paquier writes: > Not worse, and still not enough... bowerbird complained again: > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird=2016-04-25%2002%3A13%3A54 That's a different symptom that seems unrelated: cannot remove directory for

Re: [HACKERS] Why doesn't src/backend/port/win32/socket.c implement bind()?

On Mon, Apr 25, 2016 at 4:43 AM, Tom Lane wrote: > I took a second look at the above-quoted Microsoft documentation, and > noticed that it specifies that this error occurs when another application > is *bound* to the target address. If by that they mean that the other > app

Re: [HACKERS] Rename max_parallel_degree?

On Sun, Apr 24, 2016 at 2:42 PM, Tom Lane wrote: > Magnus Hagander writes: >> On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane wrote: >>> FWIW, I agree with Bruce that using "degree" here is a poor choice. >>> It's an unnecessary dependence

Re: [HACKERS] [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.

Peter Eisentraut writes: > On 04/21/2016 08:18 PM, Tom Lane wrote: >> Could you send along the assembler code generated by the compiler (-S >> output) for float.c? Maybe that would shed some light. Probably the >> -O0 version would be easier to read. > Attached is a smaller

Re: [HACKERS] Rename max_parallel_degree?

On Sun, Apr 24, 2016 at 2:23 PM, Tom Lane wrote: > FWIW, I agree with Bruce that using "degree" here is a poor choice. > It's an unnecessary dependence on technical terminology that many people > will not be familiar with. And many others will. Some made-up term that is

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

* Andrew Dunstan (and...@dunslane.net) wrote: > On 04/24/2016 06:02 PM, Sehrope Sarkuni wrote: > >AFAIK, there's also no guarantee on the specific order of the > >resulting properties in the text representation either. I would > >suppose it's fixed for a given jsonb value within a database major >

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On 04/24/2016 06:02 PM, Sehrope Sarkuni wrote: AFAIK, there's also no guarantee on the specific order of the resulting properties in the text representation either. I would suppose it's fixed for a given jsonb value within a database major version but across major versions it could change

Re: [HACKERS] Rename max_parallel_degree?

On Sun, Apr 24, 2016 at 02:23:43PM -0400, Tom Lane wrote: > Robert Haas writes: > > Also, consider that we have the related but actually sorta different > > GUC max_worker_processes. I think max_parallel_workers to control the > > per-query behavior and

[HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

Hi, The default text representation of jsonb adds whitespace in between key/value pairs (after the colon ":") and after successive properties (after the comma ","): postgres=# SELECT '{"b":2,"a":1}'::jsonb::text; text -- {"a": 1, "b": 2} (1 row) AFAIK, there's also no

Re: [HACKERS] Proposed change to make cancellations safe

Simon Riggs writes: > On 24 April 2016 at 17:54, Shay Rojansky wrote: >> I definitely agree that simply tracking message sequence numbers on both >> sides is better. It's also a powerful feature to be able to cancel all >> messages "up to N" - I'm thinking

Re: [HACKERS] Proposed change to make cancellations safe

On 24 April 2016 at 17:54, Shay Rojansky wrote: > I definitely agree that simply tracking message sequence numbers on both > sides is better. It's also a powerful feature to be able to cancel all > messages "up to N" - I'm thinking of a scenario where, for example, many > simple

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

On 18 April 2016 at 13:15, Simon Riggs wrote: > On 18 April 2016 at 12:43, Michael Paquier > wrote: > >> On Sat, Apr 16, 2016 at 5:37 AM, Alvaro Herrera >> wrote: >> > Andres Freund wrote: >> >> On 2016-04-15 15:26:17

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

* 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

Re: [HACKERS] Why doesn't src/backend/port/win32/socket.c implement bind()?

I wrote: > However, it's still not entirely clear what is the root cause of the > failure and whether a patch along the discussed lines would prevent its > recurrence. Looking at TranslateSocketError, it seems we must be seeing > an underlying error code of WSAEACCES. A little googling says that

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

* 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

Re: [HACKERS] checkpoint_flush_after documentation inconsistency

On 2016-04-21 11:20:38 -0700, Andres Freund wrote: > On 2016-04-18 14:33:28 +0900, Fujii Masao wrote: > > On Fri, Apr 15, 2016 at 6:56 PM, Magnus Hagander > > wrote: > > > The documentation says that the default value is 128Kb on Linux, but the > > > code says it's 256Kb. >

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

* 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, CRT

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

On 04/24/2016 03:16 PM, Christian Ullrich wrote: * 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

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

* 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

[HACKERS] Ordering in guc.c vs. config.sgml vs. postgresql.sample.conf

Hi, While working on http://www.postgresql.org/message-id/cabuevezwma9y+bp4fi4fe4hmpfzmjozomulvtbhhpwtcujr...@mail.gmail.com I once more taken aback by the total lack of consistency between the three files in $subject. Some of the inconsistency of guc.c vs. the rest comes from having separate

Re: Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

On 04/02/2016 01:20 PM, Tom Lane wrote: Andrew Dunstan writes: Looking at this briefly. It looks like the check should be called from enum_in() and enum_recv(). What error should be raised if the enum row's xmin isn't committed? ERRCODE_FEATURE_NOT_SUPPORTED? or maybe

Re: [HACKERS] Rename max_parallel_degree?

Magnus Hagander writes: > On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane wrote: >> FWIW, I agree with Bruce that using "degree" here is a poor choice. >> It's an unnecessary dependence on technical terminology that many people >> will not be familiar with. >

Re: [HACKERS] Rename max_parallel_degree?

On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane wrote: > Robert Haas writes: > > On Sat, Apr 23, 2016 at 11:58 PM, Bruce Momjian > wrote: > >> Why is the parallelism variable called "max_parallel_degree"? Is that a > >> descriptive name?

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas writes: > On Sat, Apr 23, 2016 at 11:58 PM, Bruce Momjian wrote: >> Why is the parallelism variable called "max_parallel_degree"? Is that a >> descriptive name? What does "degree" mean? Why is it not called >> "max_parallel_workers"? >

Re: [HACKERS] Rename max_parallel_degree?

On Sat, Apr 23, 2016 at 11:58 PM, Bruce Momjian wrote: > Why is the parallelism variable called "max_parallel_degree"? Is that a > descriptive name? What does "degree" mean? Why is it not called > "max_parallel_workers"? Because "degree of parallelism" is standard

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

Andrew Dunstan writes: > On 04/24/2016 12:14 PM, Tom Lane wrote: >> BTW, in view of 9f633b404, shouldn't there be a similar addition to >> win32env.c in this patch? > msvcr120.dll seems to be the highest numbered one on my system, and we > already cover that. If you like we

Re: [HACKERS] Rename max_parallel_degree?

On 04/23/2016 11:00 PM, Peter Geoghegan wrote: On Sat, Apr 23, 2016 at 8:58 PM, Bruce Momjian wrote: Why is the parallelism variable called "max_parallel_degree"? Is that a descriptive name? What does "degree" mean? Why is it not called "max_parallel_workers"? I also

Re: [HACKERS] Proposed change to make cancellations safe

I definitely agree that simply tracking message sequence numbers on both sides is better. It's also a powerful feature to be able to cancel all messages "up to N" - I'm thinking of a scenario where, for example, many simple queries are sent and the whole process needs to be cancelled. Yes, this

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

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?

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

Andrew Dunstan writes: > On 04/24/2016 11:58 AM, Tom Lane wrote: >> Hmm ... does this pragma work on *every* compiler we're going to use >> on Windows? > According to my research it works on all the MSVC versions we support. I > didn't research the others (i.e. gcc), but we

Re: [HACKERS] Proposed change to make cancellations safe

On 24 April 2016 at 13:04, Shay Rojansky wrote: The issue I'd like to tackle is the fact that it's not possible to make > sure a cancellation request affects a specific query. Since cancellations > are totally asynchronous and occur on another socket, they affect whatever > query

Re: [HACKERS] Defaults for replication/backup

On Sun, Apr 24, 2016 at 5:50 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Thu, Apr 21, 2016 at 7:20 PM, Robert Haas > wrote: > >> I think we are far too close to beta1 to begin bikeshedding this. > >> Changing the defaults

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

On 04/24/2016 11:58 AM, 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. +#pragma warning(push) +#pragma warning(disable : 4091) #include +#pragma warning(pop) Hmm ...

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

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? regards, tom lane

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

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. > +#pragma warning(push) > +#pragma warning(disable : 4091) > #include > +#pragma warning(pop) Hmm ... does this pragma work on *every*

Re: [HACKERS] Defaults for replication/backup

Magnus Hagander writes: > On Thu, Apr 21, 2016 at 7:20 PM, Robert Haas wrote: >> I think we are far too close to beta1 to begin bikeshedding this. >> Changing the defaults is not going to be uncontroversial, and it's not >> something I think we should

Re: [HACKERS] Updated backup APIs for non-exclusive backups

* Magnus Hagander (mag...@hagander.net) wrote: > On Sun, Apr 24, 2016 at 5:37 AM, Bruce Momjian wrote: > > > On Fri, Apr 22, 2016 at 11:53:46AM -0400, Robert Haas wrote: > > > On Wed, Apr 20, 2016 at 1:32 PM, Magnus Hagander > > wrote: > > > > Note that we

Re: [HACKERS] Defaults for replication/backup

On Thu, Apr 21, 2016 at 7:20 PM, Robert Haas wrote: > On Wed, Apr 20, 2016 at 2:04 PM, Magnus Hagander > wrote: > > So what more do we need to just get going with this? Given feature freeze > > we're perhaps too late to actually build the parameter

Re: [HACKERS] Updated backup APIs for non-exclusive backups

On Sun, Apr 24, 2016 at 5:37 AM, Bruce Momjian wrote: > On Fri, Apr 22, 2016 at 11:53:46AM -0400, Robert Haas wrote: > > On Wed, Apr 20, 2016 at 1:32 PM, Magnus Hagander > wrote: > > > Note that we have not marked them as deprecated. We're just giving >

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

On 04/23/2016 11:25 PM, Andrew Dunstan wrote: On 04/23/2016 06:33 PM, Tom Lane wrote: I wrote: Andrew Dunstan writes: On 04/23/2016 05:30 PM, Christian Ullrich wrote: In this case, I would prefer this: #ifdef WIN32_ONLY_COMPILER -typedef int pid_t; +typedef

Re: [HACKERS] Proposed change to make cancellations safe

Shay Rojansky writes: > The issue I'd like to tackle is the fact that it's not possible to make > sure a cancellation request affects a specific query. Right ... > A simple fix for this would be to have a sequence number returned in the > BindComplete message. First, that

[HACKERS] Proposed change to make cancellations safe

Hi. A while ago I discussed some reliability issues when using cancellations ( http://www.postgresql.org/message-id/CADT4RqAk0E10=9ba8v+uu0dq9tr+pn8x+ptqbxfc1fbivh3...@mail.gmail.com). Since we were discussing some protocol wire changes recently I'd like to propose one to help with that. The

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

On 23/04/16 08:08, Christian Ullrich wrote: * 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,

Re: [HACKERS] [COMMITTERS] pgsql: doc: Fix typos

Hello Peter, http://git.postgresql.org/pg/commitdiff/b87b2f4bda1a3b98f8dea867b8bc419ace7a9ea9 doc/src/sgml/ref/pgbench.sgml | 8 - Here is example outputs: + Here is example output: I think that something is missing now on this line. Should it rather be "Here is an example

Re: [HACKERS] Rename max_parallel_degree?

On Sat, Apr 23, 2016 at 8:58 PM, Bruce Momjian wrote: > Why is the parallelism variable called "max_parallel_degree"? Is that a > descriptive name? What does "degree" mean? Why is it not called > "max_parallel_workers"? I also think that "max_parallel_workers" works better.