On Tue, Oct 7, 2014 at 2:58 PM, Fujii Masao wrote:
> On Tue, Oct 7, 2014 at 2:55 PM, Andres Freund wrote:
>> On 2014-10-07 14:51:59 +0900, Fujii Masao wrote:
>>> >> *** a/src/bin/pg_basebackup/pg_receivexlog.c
>>> >> --- b/src/bin/pg_basebackup/pg_receivexlog.c
>>> >> ***
>>> >> *** 5
On 2014-10-17 20:28:29 +0900, Fujii Masao wrote:
> On Tue, Oct 7, 2014 at 2:58 PM, Fujii Masao wrote:
> > On Tue, Oct 7, 2014 at 2:55 PM, Andres Freund wrote:
> >> On 2014-10-07 14:51:59 +0900, Fujii Masao wrote:
> >>> >> *** a/src/bin/pg_basebackup/pg_receivexlog.c
> >>> >> --- b/src/bin/pg_base
On Fri, Oct 17, 2014 at 8:31 PM, Andres Freund wrote:
> Thanks. That looks good. Sorry for you having to do that - I'd kind of
> hoped that Michael would send a patch...
>
Sorry, I simply slipped through it. The patch looks good.
--
Michael
Fix pg_dump for UPDATE policies
pg_dump had the wrong character for update and so was failing when
attempts were made to pg_dump databases with UPDATE policies.
Pointed out by Fujii Masao (thanks!)
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/389573fd19edd255736c
Re-pgindent src/bin/pg_dump/*.
Seems to have gotten rather messy lately, as a consequence of a couple
of large recent commits.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/7584649a1c58029a83a7a57d74cedcf1af434c97
Modified Files
--
src/bin/pg_dump/para
Fix core dump in pg_dump --binary-upgrade on zero-column composite type.
This reverts nearly all of commit 28f6cab61ab8958b1a7dfb019724687d92722538
in favor of just using the typrelid we already have in pg_dump's TypeInfo
struct for the composite type. As coded, it'd crash if the composite type
h
Fix core dump in pg_dump --binary-upgrade on zero-column composite type.
This reverts nearly all of commit 28f6cab61ab8958b1a7dfb019724687d92722538
in favor of just using the typrelid we already have in pg_dump's TypeInfo
struct for the composite type. As coded, it'd crash if the composite type
h
Fix core dump in pg_dump --binary-upgrade on zero-column composite type.
This reverts nearly all of commit 28f6cab61ab8958b1a7dfb019724687d92722538
in favor of just using the typrelid we already have in pg_dump's TypeInfo
struct for the composite type. As coded, it'd crash if the composite type
h
Fix core dump in pg_dump --binary-upgrade on zero-column composite type.
This reverts nearly all of commit 28f6cab61ab8958b1a7dfb019724687d92722538
in favor of just using the typrelid we already have in pg_dump's TypeInfo
struct for the composite type. As coded, it'd crash if the composite type
h
Fix core dump in pg_dump --binary-upgrade on zero-column composite type.
This reverts nearly all of commit 28f6cab61ab8958b1a7dfb019724687d92722538
in favor of just using the typrelid we already have in pg_dump's TypeInfo
struct for the composite type. As coded, it'd crash if the composite type
h
Fix core dump in pg_dump --binary-upgrade on zero-column composite type.
This reverts nearly all of commit 28f6cab61ab8958b1a7dfb019724687d92722538
in favor of just using the typrelid we already have in pg_dump's TypeInfo
struct for the composite type. As coded, it'd crash if the composite type
h
Fix bug in handling of connections that pg_receivexlog creates.
Previously pg_receivexlog created new connection for WAL streaming
even though another connection which had been established to create
or delete the replication slot was being left. This caused the unused
connection to be left useless
On Fri, Oct 17, 2014 at 8:53 PM, Michael Paquier
wrote:
> On Fri, Oct 17, 2014 at 8:31 PM, Andres Freund wrote:
>>
>> Thanks. That looks good. Sorry for you having to do that - I'd kind of
>> hoped that Michael would send a patch...
>
> Sorry, I simply slipped through it. The patch looks good.
T
Avoid core dump in _outPathInfo() for Path without a parent RelOptInfo.
Nearly all Paths have parents, but a ResultPath representing an empty FROM
clause does not. Avoid a core dump in such cases. I believe this is only
a hazard for debugging usage, not for production, else we'd have heard
about
Avoid core dump in _outPathInfo() for Path without a parent RelOptInfo.
Nearly all Paths have parents, but a ResultPath representing an empty FROM
clause does not. Avoid a core dump in such cases. I believe this is only
a hazard for debugging usage, not for production, else we'd have heard
about
Avoid core dump in _outPathInfo() for Path without a parent RelOptInfo.
Nearly all Paths have parents, but a ResultPath representing an empty FROM
clause does not. Avoid a core dump in such cases. I believe this is only
a hazard for debugging usage, not for production, else we'd have heard
about
Avoid core dump in _outPathInfo() for Path without a parent RelOptInfo.
Nearly all Paths have parents, but a ResultPath representing an empty FROM
clause does not. Avoid a core dump in such cases. I believe this is only
a hazard for debugging usage, not for production, else we'd have heard
about
Avoid core dump in _outPathInfo() for Path without a parent RelOptInfo.
Nearly all Paths have parents, but a ResultPath representing an empty FROM
clause does not. Avoid a core dump in such cases. I believe this is only
a hazard for debugging usage, not for production, else we'd have heard
about
Declare mkdtemp() only if we're providing it.
Follow our usual style of providing an "extern" for a standard library
function only when we're also providing the implementation. This avoids
issues when the system headers declare the function slightly differently
than we do, as noted by Caleb Welto
Declare mkdtemp() only if we're providing it.
Follow our usual style of providing an "extern" for a standard library
function only when we're also providing the implementation. This avoids
issues when the system headers declare the function slightly differently
than we do, as noted by Caleb Welto
Declare mkdtemp() only if we're providing it.
Follow our usual style of providing an "extern" for a standard library
function only when we're also providing the implementation. This avoids
issues when the system headers declare the function slightly differently
than we do, as noted by Caleb Welto
Declare mkdtemp() only if we're providing it.
Follow our usual style of providing an "extern" for a standard library
function only when we're also providing the implementation. This avoids
issues when the system headers declare the function slightly differently
than we do, as noted by Caleb Welto
Declare mkdtemp() only if we're providing it.
Follow our usual style of providing an "extern" for a standard library
function only when we're also providing the implementation. This avoids
issues when the system headers declare the function slightly differently
than we do, as noted by Caleb Welto
Declare mkdtemp() only if we're providing it.
Follow our usual style of providing an "extern" for a standard library
function only when we're also providing the implementation. This avoids
issues when the system headers declare the function slightly differently
than we do, as noted by Caleb Welto
24 matches
Mail list logo
