pg_resetwal: Fix logical typo in code
introduced in f1a074b146c900bd439b6ef1953866f41b61a669
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/cc547cf08fe62e90f34a780a6b4fe428336ab3ec
Modified Files
--
src/bin/pg_resetwal/pg_resetwal.c | 4 ++--
1 file cha
Doc: remove extra comma in syntax summary for array_fill().
Noted by Scott Ure. Back-patch to all supported branches.
Discussion:
https://postgr.es/m/152199346794.4544.1888397173908716...@wrigleys.postgresql.org
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/ee4
Doc: remove extra comma in syntax summary for array_fill().
Noted by Scott Ure. Back-patch to all supported branches.
Discussion:
https://postgr.es/m/152199346794.4544.1888397173908716...@wrigleys.postgresql.org
Branch
--
REL9_3_STABLE
Details
---
https://git.postgresql.org/pg/commitd
Doc: remove extra comma in syntax summary for array_fill().
Noted by Scott Ure. Back-patch to all supported branches.
Discussion:
https://postgr.es/m/152199346794.4544.1888397173908716...@wrigleys.postgresql.org
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitd
Doc: remove extra comma in syntax summary for array_fill().
Noted by Scott Ure. Back-patch to all supported branches.
Discussion:
https://postgr.es/m/152199346794.4544.1888397173908716...@wrigleys.postgresql.org
Branch
--
REL9_4_STABLE
Details
---
https://git.postgresql.org/pg/commitd
Doc: remove extra comma in syntax summary for array_fill().
Noted by Scott Ure. Back-patch to all supported branches.
Discussion:
https://postgr.es/m/152199346794.4544.1888397173908716...@wrigleys.postgresql.org
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitd
Doc: remove extra comma in syntax summary for array_fill().
Noted by Scott Ure. Back-patch to all supported branches.
Discussion:
https://postgr.es/m/152199346794.4544.1888397173908716...@wrigleys.postgresql.org
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org/pg/commitd
Teodor Sigaev writes:
> Exclude unlogged tables from base backups
Buildfarm member skink (valgrind) has reported this during its last couple
of runs:
2018-03-24 03:18:23.409 UTC [17302] 010_pg_basebackup.pl LOG: received
replication command: BASE_BACKUP LABEL 'pg_basebackup base backup'NOW
Remove useless if-test.
Coverity complained that this check is pointless, and it's right.
There is no case where we'd call ExecutorStart with a null plannedstmt,
and if we did, it'd have crashed before here. Thinko in commit cc415a56d.
Branch
--
master
Details
---
https://git.postgresql
initdb: Further polishing of --wal-segsize option
Extend documentation. Improve option parsing in case no argument was
specified.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/8ad8d916f99d19e0be7800992c828c3c1a01b693
Modified Files
--
doc/src/sgml/re
pg_resetwal: Allow users to change the WAL segment size
This adds a new option --wal-segsize (analogous to initdb) that changes
the WAL segment size in pg_control.
Author: Nathan Bossart
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/bf4a8676c316c177f395b54d3305e
On 3/25/18 2:16 PM, Tom Lane wrote:
> Teodor Sigaev writes:
>> Exclude unlogged tables from base backups
>
> Buildfarm member skink (valgrind) has reported this during its last couple
> of runs:
>
> 2018-03-24 03:18:23.409 UTC [17302] 010_pg_basebackup.pl LOG: received
> replication command: B
Fix unsafe extraction of the OID part of a relation filename.
Commit 8694cc96b did this randomly differently from other callers of
parse_filename_for_nontemp_relation(). Perhaps unsurprisingly,
the randomly different way is wrong; it fails to ensure the
extracted string is null-terminated. Per b
I wrote:
> I might be wrong to blame that on this patch, but nothing else has
> touched basebackup.c lately.
Ah, I see the problem, I think. Fixed.
regards, tom lane
David Steele writes:
> On 3/25/18 2:16 PM, Tom Lane wrote:
>> Buildfarm member skink (valgrind) has reported this during its last couple
>> of runs:
> I think skink is using large values for rel oids and that has exposed a
> bug. The strncpy doesn't zero terminate the string if the oid has the
>
On 3/25/18 3:22 PM, Tom Lane wrote:
> David Steele writes:
>> On 3/25/18 2:16 PM, Tom Lane wrote:
>>> Buildfarm member skink (valgrind) has reported this during its last couple
>>> of runs:
>
>> I think skink is using large values for rel oids and that has exposed a
>> bug. The strncpy doesn't z
David Steele writes:
> On 3/25/18 3:22 PM, Tom Lane wrote:
>> Actually, that code didn't guarantee zero termination under *any*
>> circumstances; it only happened to work if the stack contained
>> zeroes to start with.
> Interesting. strncpy() says it will pad the destination with NULLs when
> s
On 3/25/18 3:54 PM, Tom Lane wrote:
> David Steele writes:
>> On 3/25/18 3:22 PM, Tom Lane wrote:
>>> Actually, that code didn't guarantee zero termination under *any*
>>> circumstances; it only happened to work if the stack contained
>>> zeroes to start with.
>
>> Interesting. strncpy() says it
Doc: add example of type resolution in nested UNIONs.
Section 10.5 didn't say explicitly that multiple UNIONs are resolved
pairwise. Since the resolution algorithm is described as taking any
number of inputs, readers might well think that a query like
"select x union select y union select z" woul
Doc: add example of type resolution in nested UNIONs.
Section 10.5 didn't say explicitly that multiple UNIONs are resolved
pairwise. Since the resolution algorithm is described as taking any
number of inputs, readers might well think that a query like
"select x union select y union select z" woul
Doc: add example of type resolution in nested UNIONs.
Section 10.5 didn't say explicitly that multiple UNIONs are resolved
pairwise. Since the resolution algorithm is described as taking any
number of inputs, readers might well think that a query like
"select x union select y union select z" woul
Doc: add example of type resolution in nested UNIONs.
Section 10.5 didn't say explicitly that multiple UNIONs are resolved
pairwise. Since the resolution algorithm is described as taking any
number of inputs, readers might well think that a query like
"select x union select y union select z" woul
Doc: add example of type resolution in nested UNIONs.
Section 10.5 didn't say explicitly that multiple UNIONs are resolved
pairwise. Since the resolution algorithm is described as taking any
number of inputs, readers might well think that a query like
"select x union select y union select z" woul
Doc: add example of type resolution in nested UNIONs.
Section 10.5 didn't say explicitly that multiple UNIONs are resolved
pairwise. Since the resolution algorithm is described as taking any
number of inputs, readers might well think that a query like
"select x union select y union select z" woul
24 matches
Mail list logo
