On 17.08.2011 12:26, Fujii Masao wrote:
So, in master, we should change pg_controldata.c and pg_resetxlog.c for
new pg_control field "backupEndRequired"?
Ah, good catch! Fixed.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-h
On Wed, Aug 17, 2011 at 5:49 PM, Heikki Linnakangas
wrote:
> Hmm, this behaves slightly differently, if you first try to start the
> restored server without recovery.conf, stop recovery, and restart it after
> adding recovery.conf. But I guess that's not a big deal, the check is simply
> skipped i
On 16.08.2011 04:10, Fujii Masao wrote:
On Thu, Aug 11, 2011 at 1:34 AM, Heikki Linnakangas
wrote:
Hmm, that's not possible for the 'tar' output, but would work for 'dir'
output. Another similar idea would be to withhold the control file in memory
until the end of backup, and append it to the
On Thu, Aug 11, 2011 at 1:34 AM, Heikki Linnakangas
wrote:
> Hmm, that's not possible for the 'tar' output, but would work for 'dir'
> output. Another similar idea would be to withhold the control file in memory
> until the end of backup, and append it to the output as last. The backup
> can't be
Magnus Hagander writes:
>>> Or add a signal
>>> handler in the pg_basebackup client emitting a warning about it?
>>
>> We don't have such a signal handler pg_dump either. I don't think we should
>> add it.
>
> Hmm. I guess an aborted pg_dump will also "look ok but actually be
> corrupt" (or incomp
On Wed, Aug 10, 2011 at 19:45, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Hmm, that's not possible for the 'tar' output, but would work for 'dir'
>> output. Another similar idea would be to withhold the control file in
>> memory until the end of backup, and append it to the output as last. T
On Wed, Aug 10, 2011 at 1:45 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Hmm, that's not possible for the 'tar' output, but would work for 'dir'
>> output. Another similar idea would be to withhold the control file in
>> memory until the end of backup, and append it to the output as last.
Heikki Linnakangas writes:
> Hmm, that's not possible for the 'tar' output, but would work for 'dir'
> output. Another similar idea would be to withhold the control file in
> memory until the end of backup, and append it to the output as last. The
> backup can't be restored until the control fi
On 10.08.2011 15:34, Simon Riggs wrote:
On Wed, Aug 10, 2011 at 1:19 PM, Robert Haas wrote:
On Wed, Aug 10, 2011 at 6:53 AM, Magnus Hagander wrote:
On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas
wrote:
On 10.08.2011 12:29, Magnus Hagander wrote:
On Tue, Aug 9, 2011 at 18:07, Tom Lane
On Wed, Aug 10, 2011 at 1:19 PM, Robert Haas wrote:
> On Wed, Aug 10, 2011 at 6:53 AM, Magnus Hagander wrote:
>> On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas
>> wrote:
>>> On 10.08.2011 12:29, Magnus Hagander wrote:
On Tue, Aug 9, 2011 at 18:07, Tom Lane wrote:
>
> Heikki
On Wed, Aug 10, 2011 at 6:53 AM, Magnus Hagander wrote:
> On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas
> wrote:
>> On 10.08.2011 12:29, Magnus Hagander wrote:
>>>
>>> On Tue, Aug 9, 2011 at 18:07, Tom Lane wrote:
Heikki Linnakangas writes:
>
> On 09.08.2011 18:20, Alvaro
On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas
wrote:
> On 10.08.2011 12:29, Magnus Hagander wrote:
>>
>> On Tue, Aug 9, 2011 at 18:07, Tom Lane wrote:
>>>
>>> Heikki Linnakangas writes:
On 09.08.2011 18:20, Alvaro Herrera wrote:
>
> How about making the new backup_label fie
On 10.08.2011 12:29, Magnus Hagander wrote:
On Tue, Aug 9, 2011 at 18:07, Tom Lane wrote:
Heikki Linnakangas writes:
On 09.08.2011 18:20, Alvaro Herrera wrote:
How about making the new backup_label field optional? If absent, assume
current behavior.
That's how I actually did it in the pa
On Tue, Aug 9, 2011 at 18:07, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 09.08.2011 18:20, Alvaro Herrera wrote:
>>> How about making the new backup_label field optional? If absent, assume
>>> current behavior.
>
>> That's how I actually did it in the patch. However, the problem wrt.
>>
On 09.08.2011 19:07, Tom Lane wrote:
Heikki Linnakangas writes:
On 09.08.2011 18:20, Alvaro Herrera wrote:
How about making the new backup_label field optional? If absent, assume
current behavior.
That's how I actually did it in the patch. However, the problem wrt.
requiring initdb is not
Heikki Linnakangas writes:
> On 09.08.2011 18:20, Alvaro Herrera wrote:
>> How about making the new backup_label field optional? If absent, assume
>> current behavior.
> That's how I actually did it in the patch. However, the problem wrt.
> requiring initdb is not the new field in backup_label,
On 09.08.2011 18:20, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of mar ago 09 05:00:00 -0400 2011:
I think this is a nice additional safeguard to have, making streamed
backups more robust. I'd like to add this to 9.1, but it required an
extra field to be added to the contr
Excerpts from Heikki Linnakangas's message of mar ago 09 05:00:00 -0400 2011:
> I think this is a nice additional safeguard to have, making streamed
> backups more robust. I'd like to add this to 9.1, but it required an
> extra field to be added to the control file, so it would force an
> initd
18 matches
Mail list logo