Fix typo
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/5303ffe71b4d28663e0881199bb1a5ea26217ce4
Modified Files
--
src/bin/pg_basebackup/pg_recvlogical.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 2017-12-27 17:59:26 -0500, Tom Lane wrote:
> [ back from Christmas break ]
>
> Andres Freund writes:
> > On December 22, 2017 7:52:54 PM GMT+01:00, Tom Lane
> > wrote:
> >> I will not accept an implementation that spews compiler warnings
> >> all over the place, which is what this one is doi
On Sat, Dec 30, 2017 at 8:43 AM, Andres Freund wrote:
> On 2017-12-29 23:06:10 +1300, Thomas Munro wrote:
>> On Wed, Dec 13, 2017 at 2:01 PM, Andres Freund wrote:
>> > Use new overflow aware integer operations.
>>
>> frogmouth seems to have crashed in the vicinity of various number
>> processing
Rely on executor utils to build targetlist for DML RETURNING.
This is useful because it gets rid of the sole direct user of
ExecAssignResultType(). A future commit will likely make use of that
and combine creating the targetlist with the initialization of the
result slot. But it seems like good co
Perform slot validity checks in a separate pass over expression.
This reduces code duplication a bit, but the primary benefit that it
makes JITing expression evaluation easier. When doing so we can't, as
previously done in the interpreted case, really change opcode without
recompiling. Nor dow we
On 2017-12-29 23:06:10 +1300, Thomas Munro wrote:
> On Wed, Dec 13, 2017 at 2:01 PM, Andres Freund wrote:
> > Use new overflow aware integer operations.
>
> frogmouth seems to have crashed in the vicinity of various number
> processing tests -- could this commit be responsible? A wild guess as
>
Properly set base backup backends to active in pg_stat_activity
When walsenders were included in pg_stat_activity, only the ones
actually streaming WAL were listed as active when they were active. In
particular, the connections sending base backups were listed as being
idle. Which means that a reg
Properly set base backup backends to active in pg_stat_activity
When walsenders were included in pg_stat_activity, only the ones
actually streaming WAL were listed as active when they were active. In
particular, the connections sending base backups were listed as being
idle. Which means that a reg
Fix race condition when changing synchronous_standby_names
A momentary window exists when synchronous_standby_names
changes that allows commands issued after the change to
continue to act as async until the change becomes visible.
Remove the race by using more appropriate test in syncrep.c
Author
Extend near-wraparound hints to include replication slots
Author: Feike Steenbergen
Reviewed-by: Michael Paquier
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/2958a672b1fed35403b23c2b453aede9f7ef4b39
Modified Files
--
doc/src/sgml/logicaldecoding.sgml
On 12/29/2017 08:04 AM, Raúl Marín Rodríguez wrote:
>
> Probably "0?". Although an int with leading zeros is usually an
> octal number, so window's rational fails me.
>
>
> You are right. From the C99 standard:
>
> The exponent always contains at least two digits, and only as many
>
Allow leading zero on exponents in pgbench test results
Following commit 7a727c18 this is found to be necessary on at least some
Windows platforms.
per buildfarm.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/0aa1d489ea756b96b6d5573692ae9cd5d143c2a5
Modified Fil
>
> Probably "0?". Although an int with leading zeros is usually an octal
> number, so window's rational fails me.
You are right. From the C99 standard:
> The exponent always contains at least two digits, and only as many more
> digits as necessary to represent the exponent. If the value is zero
# debug(script=0,command=31): double 8.50705917302346e+037
# doesn't match '(?^:command=31.: double 8.50705917302346e\+37\b)'
# debug(script=0,command=32): double 1e+030
# doesn't match '(?^:command=32.: double 1e\+30\b)'
The difference seems to be a leading zero before the exponent, s
On Wed, Dec 13, 2017 at 2:01 PM, Andres Freund wrote:
> Use new overflow aware integer operations.
frogmouth seems to have crashed in the vicinity of various number
processing tests -- could this commit be responsible? A wild guess as
there isn't much to go on in the build log:
https://buildfar
On Thu, Dec 28, 2017 at 7:47 AM, Robert Haas wrote:
> Add pow(), aka power(), function to pgbench.
>
> Raúl Marín Rodríguez, reviewed by Fabien Coelho and Michael Paquier,
> with a minor fix by me.
>
> Discussion:
> http://postgr.es/m/cam6_um4xia14y9hndqu9kaaotwmhhzxw--q_zaczw9hsrsf...@mail.gmail
16 matches
Mail list logo