On Fri, Mar 31, 2017 at 02:11:44PM +0900, Kyotaro HORIGUCHI wrote:
> At Fri, 31 Mar 2017 13:37:38 +0900, Michael Paquier
> wrote in
>
At Fri, 31 Mar 2017 13:37:38 +0900, Michael Paquier
wrote in
On Fri, Mar 31, 2017 at 12:06 AM, Fujii Masao wrote:
> I don't think that using psql to run BASE_BACKUP command is good
> approach.
That's basically what pg_basebackup is made for, and it makes sure
that some sanity checks and measures happen.
> Instead, IMO you basically
On Wed, Mar 29, 2017 at 5:36 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Wed, 29 Mar 2017 09:23:42 +0200, Michael Banck
> wrote in <149077.18436.14.ca...@credativ.de>
>> Hi,
>>
>> Am Mittwoch, den 29.03.2017, 15:22 +0900 schrieb
Hello,
At Wed, 29 Mar 2017 09:23:42 +0200, Michael Banck
wrote in <149077.18436.14.ca...@credativ.de>
> Hi,
>
> Am Mittwoch, den 29.03.2017, 15:22 +0900 schrieb Michael Paquier:
> > On Wed, Mar 29, 2017 at 3:56 AM, Fujii Masao wrote:
> > >
Hi,
Am Mittwoch, den 29.03.2017, 15:22 +0900 schrieb Michael Paquier:
> On Wed, Mar 29, 2017 at 3:56 AM, Fujii Masao wrote:
> > If your need other information except START WAL LOCATION at the beginning of
> > base backup and they are very useful for many third-party
On Wed, Mar 29, 2017 at 3:56 AM, Fujii Masao wrote:
> If your need other information except START WAL LOCATION at the beginning of
> base backup and they are very useful for many third-party softwares,
> you can add them into that first result set. If you do this, you can
>
On Tue, Feb 21, 2017 at 7:17 PM, Michael Banck
wrote:
> Hi,
>
> currently, the backup_label and (I think) the tablespace_map files are
> (by design) conveniently located at the beginning of the main tablespace
> tarball when making a basebackup. However, (by accident or
Hi,
Am Freitag, den 17.03.2017, 20:46 +0900 schrieb Michael Paquier:
> On Fri, Mar 17, 2017 at 7:18 PM, Michael Banck
> wrote:
> > Am Freitag, den 17.03.2017, 10:50 +0900 schrieb Michael Paquier:
> >> The comment block format is incorrect. I would think as well that
On Fri, Mar 17, 2017 at 7:18 PM, Michael Banck
wrote:
> Hi,
>
> Am Freitag, den 17.03.2017, 10:50 +0900 schrieb Michael Paquier:
>> The comment block format is incorrect. I would think as well that this
>> comment should say it is important to have the main tablespace
Hi,
Am Freitag, den 17.03.2017, 10:50 +0900 schrieb Michael Paquier:
> The comment block format is incorrect. I would think as well that this
> comment should say it is important to have the main tablespace listed
> last it includes the WAL segments, and those need to contain all the
> latest WAL
On Fri, Mar 17, 2017 at 3:38 AM, Michael Banck
wrote:
>> Your patch would work with the stream mode though.
>
> Or, if not requesting the "WAL" option of the replication protocol's
> BASE_BACKUP command.
>
> I agree it doesn't make sense to start messing with fetch
Hi,
sorry, it took me a while to get back to this.
Am Freitag, den 03.03.2017, 15:44 +0900 schrieb Michael Paquier:
> On Wed, Feb 22, 2017 at 9:23 PM, Bernd Helmle wrote:
> > The comment in the code says explicitely to add the base directory to
> > the end of the list, not
On Tue, Mar 14, 2017 at 11:34 PM, David Steele wrote:
> This thread is stalled and it looks like the patch may not be workable,
> at least in the current form.
>
> I will mark this a "Returned with Feedback" on 2017-03-17 unless there
> are arguments to the contrary.
Or even
On Sat, Mar 4, 2017 at 1:13 AM, Bernd Helmle wrote:
> Ah right, i assumed there must be something, otherwise the comment
> won't be there ;)
>
> We could special case that part to distinguish fetch/stream mode, but i
> fear that leads to more confusion than it wants to fix.
Am Freitag, den 03.03.2017, 15:44 +0900 schrieb Michael Paquier:
> So, the main directory is located at the end on purpose. When using
> --wal-method=fetch the WAL segments are part of the main tarball, so
> if you send the main tarball first you would need to generate a
> second
> tarball with
On Wed, Feb 22, 2017 at 9:23 PM, Bernd Helmle wrote:
> The comment in the code says explicitely to add the base directory to
> the end of the list, not sure if that is out of a certain reason.
>
> I'd say this is an oversight in the implementation. I'm currently
> working on
Hi,
Am Sonntag, den 26.02.2017, 22:25 +0530 schrieb Robert Haas:
> On Tue, Feb 21, 2017 at 3:47 PM, Michael Banck
> wrote:
> > So I am proposing the attached patch, which sends the base tablespace
> > first, and then all the other external tablespaces afterwards, thus
On Tue, Feb 21, 2017 at 3:47 PM, Michael Banck
wrote:
> currently, the backup_label and (I think) the tablespace_map files are
> (by design) conveniently located at the beginning of the main tablespace
> tarball when making a basebackup. However, (by accident or also by
Am Dienstag, den 21.02.2017, 11:17 +0100 schrieb Michael Banck:
> However, third party tools using the BASE_BACKUP command might want
> to
> extract the backup_label, e.g. in order to figure out the START WAL
> LOCATION. If they make a big tarball for the whole cluster
> potentially
> including
Hi,
currently, the backup_label and (I think) the tablespace_map files are
(by design) conveniently located at the beginning of the main tablespace
tarball when making a basebackup. However, (by accident or also by
design?) the main tablespace is the last tarball[1] to be streamed via
the
21 matches
Mail list logo