Hi,
Thanks for having a look at this patch.
2017-11-09 20:55 GMT-03:00 Jeff Janes :
> On Fri, Sep 29, 2017 at 4:00 PM, Martin Marques
> wrote:
>>
>> Hi,
>>
>> Some time ago I had to work on a system where I was cloning a standby
>> using pg_basebackup, that didn't have screen or tmux. For that r
On Thu, Nov 09, 2017 at 03:55:36PM -0800, Jeff Janes wrote:
>
> I think I agree with Arthur that I'd rather have the decision made by
> inspecting whether output is going to a tty, rather than by adding another
> command line option. But maybe that is not detected robustly enough across
> all pla
On Fri, Sep 29, 2017 at 4:00 PM, Martin Marques <
martin.marq...@2ndquadrant.com> wrote:
> Hi,
>
> Some time ago I had to work on a system where I was cloning a standby
> using pg_basebackup, that didn't have screen or tmux. For that reason I
> redirected the output to a file and ran it with nohup
Hello,
On Sun, Oct 01, 2017 at 04:49:17PM -0300, Martin Marques wrote:
> Updated patch with documentation of the new option.
>
I have checked the patch.
The patch is applied and compiled correctly without any errors. Tests passed.
The documentation doesn't have errors too.
I have a little sugg
On Thu, Nov 2, 2017 at 2:05 AM, Peter Eisentraut
wrote:
> On 11/1/17 10:29, Michael Paquier wrote:
>> On Wed, Nov 1, 2017 at 2:24 PM, Peter Eisentraut
>> wrote:
>>> Committed to master. I suppose this should be backpatched?
>>
>> Thanks! Yes this should be back-patched.
>
> OK, done for 10, 9.6,
On 11/1/17 10:29, Michael Paquier wrote:
> On Wed, Nov 1, 2017 at 2:24 PM, Peter Eisentraut
> wrote:
>> Committed to master. I suppose this should be backpatched?
>
> Thanks! Yes this should be back-patched.
OK, done for 10, 9.6, and 9.5.
The tablespace mapping feature started in 9.4 (has it b
On Wed, Nov 1, 2017 at 2:24 PM, Peter Eisentraut
wrote:
> Committed to master. I suppose this should be backpatched?
Thanks! Yes this should be back-patched.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
On 9/10/17 00:39, Michael Paquier wrote:
>> Okay. I have once again reviewed your patch and tested it on Windows
>> as well as Linux. The patch LGTM. I am now marking it as Ready For
>> Committer. Thanks.
>
> Thanks for the review, Ashutosh.
Committed to master. I suppose this should be backpatc
Updated patch with documentation of the new option.
--
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
>From ede201ed96d41d799dc3c83dfab1cdcc03e5ced4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mart=C3=ADn=20Marqu=C3=A9s?=
Date:
Hi,
Some time ago I had to work on a system where I was cloning a standby
using pg_basebackup, that didn't have screen or tmux. For that reason I
redirected the output to a file and ran it with nohup.
I normally (always actually ;) ) run pg_basebackup with --progress and
--verbose so I can follow
On Tue, Sep 12, 2017 at 7:35 PM, Jeff Janes wrote:
> On Wed, Sep 6, 2017 at 2:50 AM, Alvaro Herrera
> wrote:
>
>> Magnus Hagander wrote:
>> > On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes
>> wrote:
>>
>> > > Should the parent process of pg_basebackup be made to respond to
>> SIGCHLD?
>> > > Or cal
On Wed, Sep 6, 2017 at 2:50 AM, Alvaro Herrera
wrote:
> Magnus Hagander wrote:
> > On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes wrote:
>
> > > Should the parent process of pg_basebackup be made to respond to
> SIGCHLD?
> > > Or call waitpid(bgchild, &status, WNOHANG) in some strategic loop?
> >
>
On Wed, Sep 6, 2017 at 11:50 AM, Alvaro Herrera
wrote:
> Magnus Hagander wrote:
> > On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes wrote:
>
> > > Should the parent process of pg_basebackup be made to respond to
> SIGCHLD?
> > > Or call waitpid(bgchild, &status, WNOHANG) in some strategic loop?
> >
>
On Sun, Sep 10, 2017 at 12:28 PM, Ashutosh Sharma wrote:
> On Tue, Jun 27, 2017 at 6:36 PM, Michael Paquier
> wrote:
>> On Tue, Jun 27, 2017 at 7:46 PM, Ashutosh Sharma
>> wrote:
>>> I am still seeing the issue with the attached patch. I had a quick
>>> look into the patch. It seems to me like
On Tue, Jun 27, 2017 at 6:36 PM, Michael Paquier
wrote:
> On Tue, Jun 27, 2017 at 7:46 PM, Ashutosh Sharma
> wrote:
>> I am still seeing the issue with the attached patch. I had a quick
>> look into the patch. It seems to me like you have canonicalized the
>> tablespace path to convert win32 sla
Magnus Hagander wrote:
> On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes wrote:
> > Should the parent process of pg_basebackup be made to respond to SIGCHLD?
> > Or call waitpid(bgchild, &status, WNOHANG) in some strategic loop?
>
> I think it's ok to just call waitpid() -- we don't need to react sup
On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes wrote:
>
> If I tell pg_basebackup to use a non-existent slot, it immediately reports
> an error. And then it exits with an error, but only after streaming the
> entire database contents.
>
> If you are doing this interactively and are on the ball, of c
Alvaro Herrera wrote:
> Jeff Janes wrote:
>
> > I'm attaching a patch for each option. Each one independently solves the
> > problem. But I think we should do both. There is no point in issuing
> > unnecessary kill system calls, and there may also be more spurious wake-ups
> > than just these o
Jeff Janes wrote:
> I'm attaching a patch for each option. Each one independently solves the
> problem. But I think we should do both. There is no point in issuing
> unnecessary kill system calls, and there may also be more spurious wake-ups
> than just these ones.
I modified patch 1 a bit --
If I tell pg_basebackup to use a non-existent slot, it immediately reports
an error. And then it exits with an error, but only after streaming the
entire database contents.
If you are doing this interactively and are on the ball, of course, you can
hit ctrl-C when you see the error message.
I do
On Sat, Sep 2, 2017 at 6:42 AM, Jeff Janes wrote:
> I'm attaching a patch for each option. Each one independently solves the
> problem. But I think we should do both. There is no point in issuing
> unnecessary kill system calls, and there may also be more spurious wake-ups
> than just these one
Jeff Janes wrote:
> On Fri, Sep 1, 2017 at 1:32 PM, Jeff Janes wrote:
>
> The "-r" option to pg_basebackup is supposed to throttle the rate of the
> backup. But it only works properly if the server is mostly idle.
>
> Every non-trivial call to XLogFlush or XLogBackgroundFlush will wake up t
On Fri, Sep 1, 2017 at 1:32 PM, Jeff Janes wrote:
> The "-r" option to pg_basebackup is supposed to throttle the rate of the
> backup. But it only works properly if the server is mostly idle.
>
> Every non-trivial call to XLogFlush or XLogBackgroundFlush will wake up
> the wal sender (the one wh
The "-r" option to pg_basebackup is supposed to throttle the rate of the
backup. But it only works properly if the server is mostly idle.
Every non-trivial call to XLogFlush or XLogBackgroundFlush will wake up the
wal sender (the one which is not really sending wal, but base files), and
the throt
On Tue, Jun 27, 2017 at 7:46 PM, Ashutosh Sharma wrote:
> I am still seeing the issue with the attached patch. I had a quick
> look into the patch. It seems to me like you have canonicalized the
> tablespace path to convert win32 slashes to unix type of slashes but
> that is not being passed to st
Hi,
On Tue, Jun 27, 2017 at 10:13 AM, Michael Paquier
wrote:
> On Tue, Jun 27, 2017 at 12:13 PM, Michael Paquier
> wrote:
>> At quick glance, I think that this should definitely be a client-only
>> fix. One reason is that pg_basebackup should be able to work with past
>> servers. A second is tha
On Tue, Jun 27, 2017 at 12:13 PM, Michael Paquier
wrote:
> At quick glance, I think that this should definitely be a client-only
> fix. One reason is that pg_basebackup should be able to work with past
> servers. A second is that this impacts as well the backend code, and
> readlink may not return
On Tue, Jun 27, 2017 at 1:57 AM, nb wrote:
> Trying to take a `pg_basebackup -T OLDDIR=NEWDIR [etc]` on master (server
> running the cluster) fails on Windows with error "pg_basebackup: directory
> "OLDDIR" exists but is not empty".
Yes, I can see this error easily.
> This fixed the issue, but a
Summary:
Trying to take a `pg_basebackup -T OLDDIR=NEWDIR [etc]` on master
(server running the cluster) fails on Windows with error "pg_basebackup:
directory "OLDDIR" exists but is not empty".
Version: 9.6.2, installed from Standard EDB package (built with MSVC).
Repro steps:
1. Have a clu
Hi All,
I have a working prototype now, but there is one aspect I haven't been
able to find the best solution for.
The CLI interface so far has the following new added option:
-C, --compressprog=PRG use supplied external program for compression
An example usage would be:
pg_basebackup
For reference this has been asked, and eventually answered on -general at:
https://www.postgresql.org/message-id/flat/CAKFQuwZDS7nA0SvVnumwjHBxz4CWKQm3bVNTHVeWdtAW_oXNJg%40mail.gmail.com#cakfquwzds7na0svvnumwjhbxz4cwkqm3bvnthvewdtaw_ox...@mail.gmail.com
Further comments below; partly a rehash of
Hi Team,
I am using Postgresql 9.5 and I have created backup_admin user and created
dba_admin ROLE with SUPERUSER and REPLICATION ,after that GRANT dba_admin
role to backup_admin user and executed pg_basebakup utility with
backup_admin user.
But I am not able to use the pg_basebackup utility u
Hi,
Thanks for the feedback!
>> 2) The current logic either uses zlib if compiled in, or offers no
>> compression at all, controlled by a series of #ifdef/#endif. I would
>> prefer that the user can either use zlib or an external program
>> without having to recompile, so I would remove the #ifde
On Fri, Apr 7, 2017 at 4:04 AM, Michael Harris wrote:
> Hello,
>
> Back in pg 9.2, we hacked a copy of pg_basebackup to add a command
> line option which would allow the user to specify an arbitrary
> external program (potentially including arguments) to be used to
> compress the tar backup.
>
>
On Thu, Apr 6, 2017 at 7:04 PM, Michael Harris wrote:
> Hello,
>
> Back in pg 9.2, we hacked a copy of pg_basebackup to add a command
> line option which would allow the user to specify an arbitrary
> external program (potentially including arguments) to be used to
> compress the tar backup.
>
>
Hello,
Back in pg 9.2, we hacked a copy of pg_basebackup to add a command
line option which would allow the user to specify an arbitrary
external program (potentially including arguments) to be used to
compress the tar backup.
Our motivation was to be able to use pigz (parallel gzip
implementatio
On 2/15/17 10:52, Robert Haas wrote:
> Let's wait and see if anybody else has an opinion. I imagine that, as
> further libpq parameters are added, eventually this is going to get
> long and annoying enough that we want to do something about it. But
> we might not have reached that point just yet.
On Tue, Feb 14, 2017 at 11:36 PM, Michael Paquier
wrote:
> On Wed, Feb 15, 2017 at 2:38 AM, Robert Haas wrote:
>> On Thu, Feb 9, 2017 at 9:40 PM, Michael Paquier
>> wrote:
>>> In short, I'd like to think that we should just filter out those two
>>> parameters by name and call it a day. Or introd
On Wed, Feb 15, 2017 at 2:38 AM, Robert Haas wrote:
> On Thu, Feb 9, 2017 at 9:40 PM, Michael Paquier
> wrote:
>> In short, I'd like to think that we should just filter out those two
>> parameters by name and call it a day. Or introduce an idea of value
>> set for the environment by adding some k
On Thu, Feb 9, 2017 at 9:40 PM, Michael Paquier
wrote:
> On Thu, Feb 9, 2017 at 8:17 PM, Amit Kapila wrote:
>> +1. Sounds sensible thing to do.
>
> Hm. It seems to me that PGPASSFILE still needs to be treated as an
> exception because it is set to $HOME/.pgpass without any value set in
> PQconni
On Thu, Feb 9, 2017 at 8:17 PM, Amit Kapila wrote:
> +1. Sounds sensible thing to do.
Hm. It seems to me that PGPASSFILE still needs to be treated as an
exception because it is set to $HOME/.pgpass without any value set in
PQconninfoOption->compiled and it depends on the environment. Similar
rul
On Wed, Feb 8, 2017 at 11:38 PM, Robert Haas wrote:
> I just tried out pg_basebackup -R and got the following recovery.conf file:
>
> standby_mode = 'on'
> primary_conninfo = 'user=rhaas passfile=''/home/rhaas/.pgpass''
> port=5432 sslmode=disable sslcompression=1 target_session_attrs=any'
>
> Thi
I just tried out pg_basebackup -R and got the following recovery.conf file:
standby_mode = 'on'
primary_conninfo = 'user=rhaas passfile=''/home/rhaas/.pgpass''
port=5432 sslmode=disable sslcompression=1 target_session_attrs=any'
This seems fairly random to me. pg_basebackup explains:
On Wed, Oct 26, 2016 at 2:00 AM, Magnus Hagander wrote:
> Thanks, applied and pushed.
Thanks.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Oct 25, 2016 at 2:52 PM, Michael Paquier
wrote:
> On Tue, Oct 25, 2016 at 7:12 PM, Magnus Hagander
> wrote:
> > On Mon, Oct 24, 2016 at 7:46 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >>
> >> On Sun, Oct 23, 2016 at 10:28 PM, Magnus Hagander
> >> wrote:
> >> + if
On Tue, Oct 25, 2016 at 7:12 PM, Magnus Hagander wrote:
> On Mon, Oct 24, 2016 at 7:46 AM, Michael Paquier
> wrote:
>>
>> On Sun, Oct 23, 2016 at 10:28 PM, Magnus Hagander
>> wrote:
>> + if (format == 'p')
>> + stream.walmethod = CreateWalDirectoryMethod(param->xlog, do_sync);
>> + els
On Mon, Oct 24, 2016 at 7:46 AM, Michael Paquier
wrote:
> On Sun, Oct 23, 2016 at 10:28 PM, Magnus Hagander
> wrote:
> > It also broke the tests and invalidated some documentation. But it was
> easy
> > enough to fix.
> >
> > I've now applied this, so next time you get to do the merging :P Jokin
On Sun, Oct 23, 2016 at 10:28 PM, Magnus Hagander wrote:
> It also broke the tests and invalidated some documentation. But it was easy
> enough to fix.
>
> I've now applied this, so next time you get to do the merging :P Joking
> aside, please review and let me know if you can spot something I mes
On Mon, Oct 24, 2016 at 1:38 PM, Andres Freund wrote:
> On 2016-10-17 14:37:05 +0900, Michael Paquier wrote:
>> 2) Add an option to pg_xlogdump to be able to output its output to a
>> file. That would be awkward to rely on grabbing the output data from a
>> pipe... On Windows particularly. Thinkin
On 2016-10-17 14:37:05 +0900, Michael Paquier wrote:
> 2) Add an option to pg_xlogdump to be able to output its output to a
> file. That would be awkward to rely on grabbing the output data from a
> pipe... On Windows particularly. Thinking about it, would that
> actually be useful to others? That'
On Sun, Oct 23, 2016 at 10:52 PM, Michael Paquier
wrote:
> On Sun, Oct 23, 2016 at 10:30 PM, Magnus Hagander wrote:
>> I think both of those would be worthwhile. Just for the testability in
>> itself, but such a flag to pg_xlogdump would probably be useful in other
>> cases as well, beyond just t
On Sun, Oct 23, 2016 at 10:30 PM, Magnus Hagander wrote:
> On Mon, Oct 17, 2016 at 7:37 AM, Michael Paquier
> wrote:
>> > But independent of this patch, actually putting that test in for non-tar
>> > mode would probably not be a bad idea -- if that breaks, it's likely
>> > both
>> > break, after
On Mon, Oct 17, 2016 at 7:37 AM, Michael Paquier
wrote:
> On Sat, Oct 15, 2016 at 8:51 AM, Magnus Hagander
> wrote:
> > Fixed.
>
> Ok, I had a extra look on the patch:
> + The transactionn log files are written to a separate file
> +called pg_xlog.tar.
> +
> s/tr
On Fri, Oct 21, 2016 at 2:02 PM, Michael Paquier
wrote:
> On Mon, Oct 17, 2016 at 2:37 PM, Michael Paquier
> wrote:
> > Except that it looks in pretty good to me, so I am switching that as
> > ready for committer.
>
> + /*
> +* Create pg_xlog/archive_status (and thus pg_xlog) so we
On Mon, Oct 17, 2016 at 2:37 PM, Michael Paquier
wrote:
> Except that it looks in pretty good to me, so I am switching that as
> ready for committer.
+ /*
+* Create pg_xlog/archive_status (and thus pg_xlog) so we can write to
+* basedir/pg_xlog as the directory entry in the
On Sat, Oct 15, 2016 at 8:51 AM, Magnus Hagander wrote:
> Fixed.
Ok, I had a extra look on the patch:
+ The transactionn log files are written to a separate file
+called pg_xlog.tar.
+
s/transactionn/transaction/, and the markup should be on its own line.
+ if
On Tue, Oct 4, 2016 at 12:05 AM, Michael Paquier
wrote:
> (Squashing two emails into one)
>
> On Fri, Sep 30, 2016 at 11:16 PM, Magnus Hagander
> wrote:
> > And here's yet another version, now rebased on top of the fsync and
> nosync
> > changes that got applied.
>
> My fault :p
>
Yes, definite
(Squashing two emails into one)
On Fri, Sep 30, 2016 at 11:16 PM, Magnus Hagander wrote:
> And here's yet another version, now rebased on top of the fsync and nosync
> changes that got applied.
My fault :p
> In particular, this conflicted with pretty much every single change from the
> fsync pa
On Thu, Sep 29, 2016 at 12:44 PM, Magnus Hagander
wrote:
> On Mon, Sep 5, 2016 at 10:01 AM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>> On Sat, Sep 3, 2016 at 10:35 PM, Magnus Hagander
>> wrote:
>> > Ugh. That would be nice to have, but I think that's outside the scope of
>> > thi
Michael Paquier writes:
> Oops. Are you using gcc to see that? I compiled with clang and on
> Windows without noticing it.
Peter already noted that you'd only see it on platforms that define
PG_FLUSH_DATA_WORKS.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Fri, Sep 30, 2016 at 1:31 AM, Jeff Janes wrote:
> On Thu, Sep 29, 2016 at 8:33 AM, Peter Eisentraut
> wrote:
>>
>> On 9/26/16 10:34 PM, Michael Paquier wrote:
>> > I thought that as long as the error string is shown to the user, it
>> > does not matter much if errno is still saved or not. All
On 9/29/16 12:31 PM, Jeff Janes wrote:
> With that in mind, I have committed the v3 series now.
>
>
> I'm getting compiler warnings:
Fixed.
>
> file_utils.c: In function 'fsync_pgdata':
> file_utils.c:86: warning: passing argument 2 of 'walkdir' from
> incompatible pointer type
> file_util
On Thu, Sep 29, 2016 at 8:33 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 9/26/16 10:34 PM, Michael Paquier wrote:
> > I thought that as long as the error string is shown to the user, it
> > does not matter much if errno is still saved or not. All the callers
> > of durable
On 9/26/16 10:34 PM, Michael Paquier wrote:
> I thought that as long as the error string is shown to the user, it
> does not matter much if errno is still saved or not. All the callers
> of durable_rename() on frontends don't check for strerrno(errno)
> afterwards. Do you think it matters? Changing
On Mon, Sep 5, 2016 at 10:01 AM, Michael Paquier
wrote:
> On Sat, Sep 3, 2016 at 10:35 PM, Magnus Hagander
> wrote:
> > Ugh. That would be nice to have, but I think that's outside the scope of
> > this patch.
>
> A test for this patch that could have value would be to use
> pg_basebackup -X stre
On 9/25/16 8:06 AM, Ashutosh Sharma wrote:
> Hi Peter,
>
>> I just wanted to update you, I have taken this commit fest entry patch
>> to review because I think it will be addresses as part of "Exclude
>> additional directories in pg_basebackup", which I'm also reviewing.
>> Therefore, I'm not actu
On Sep 28, 2016 19:11, "Robert Haas" wrote:
>
> On Mon, Sep 5, 2016 at 4:01 AM, Michael Paquier
> wrote:
> > [ review comments ]
>
> This thread has been sitting idle for more than 3 weeks, so I'm
> marking it "Returned with Feedback" in the CommitFest application.
> Magnus, Michael's latest roun
On Mon, Sep 5, 2016 at 4:01 AM, Michael Paquier
wrote:
> [ review comments ]
This thread has been sitting idle for more than 3 weeks, so I'm
marking it "Returned with Feedback" in the CommitFest application.
Magnus, Michael's latest round of comments seem pretty trivial, so
perhaps you want to ju
On Tue, Sep 27, 2016 at 11:16 AM, Peter Eisentraut
wrote:
> On 9/23/16 11:15 AM, Michael Paquier wrote:
>>> 0002:
>>> >
>>> > durable_rename needs close(fd) in non-error path (compare backend code).
>> Oops, leak.
>
> Why did you remove the errno save and restore?
That's this bit in durable_renam
On 9/23/16 11:15 AM, Michael Paquier wrote:
>> 0002:
>> >
>> > durable_rename needs close(fd) in non-error path (compare backend code).
> Oops, leak.
Why did you remove the errno save and restore?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
Hi Peter,
> I just wanted to update you, I have taken this commit fest entry patch
> to review because I think it will be addresses as part of "Exclude
> additional directories in pg_basebackup", which I'm also reviewing.
> Therefore, I'm not actually planning on discussing this patch further.
> P
On 9/23/16 2:12 PM, Peter Eisentraut wrote:
> On 4/26/16 5:02 AM, Ashutosh Sharma wrote:
>> Knowing that pg_basebackup always creates an empty directory for
>> pg_stat_tmp and pg_replslot in backup location, even i think it would be
>> better to handle these directories in such a way that pg_baseba
On 4/26/16 5:02 AM, Ashutosh Sharma wrote:
> Knowing that pg_basebackup always creates an empty directory for
> pg_stat_tmp and pg_replslot in backup location, even i think it would be
> better to handle these directories in such a way that pg_basebackup
> generates an empty directory for pg_replsl
On Fri, Sep 23, 2016 at 10:54 AM, Peter Eisentraut
wrote:
> This is looking pretty good. More comments on this patch set:
Thanks for the review.
> 0001:
>
> Keep the file order alphabetical in Mkvcbuild.pm.
>
> Needs nls.mk updates for file move (in initdb and pg_basebackup
> directories).
Fix
This is looking pretty good. More comments on this patch set:
0001:
Keep the file order alphabetical in Mkvcbuild.pm.
Needs nls.mk updates for file move (in initdb and pg_basebackup
directories).
0002:
durable_rename needs close(fd) in non-error path (compare backend code).
Changing from fsy
On Thu, Sep 15, 2016 at 9:44 AM, Peter Eisentraut
wrote:
> On 9/12/16 11:16 PM, Michael Paquier wrote:
>>> I don't think tar file output in pg_basebackup needs to be fsynced.
>>> > It's just a backup file like what pg_dump produces, and we don't fsync
>>> > that either. The point of this change i
On 9/12/16 11:16 PM, Michael Paquier wrote:
>> I don't think tar file output in pg_basebackup needs to be fsynced.
>> > It's just a backup file like what pg_dump produces, and we don't fsync
>> > that either. The point of this change is to leave a data directory in
>> > a synced state equivalent t
On Thu, Sep 15, 2016 at 9:26 AM, Peter Eisentraut
wrote:
> On 9/13/16 7:24 PM, Michael Paquier wrote:
>> PostgresNode.pm had better use the new --noclean option in its calls,
>> the new default is not useful for debugging.
>
> We don't do it for initdb either. Is that a problem?
Right. In case o
On 9/13/16 7:24 PM, Michael Paquier wrote:
> PostgresNode.pm had better use the new --noclean option in its calls,
> the new default is not useful for debugging.
We don't do it for initdb either. Is that a problem?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Developm
On Wed, Sep 14, 2016 at 6:52 AM, Peter Eisentraut
wrote:
> On 9/12/16 3:31 PM, Tom Lane wrote:
>> Hm, there was just a kerfuffle about spelling things like this
>> "--no-clean" etc. I wasn't on board with removing existing spellings,
>> but surely all newly added switches should use the "no-" spe
On 9/12/16 3:31 PM, Tom Lane wrote:
> Hm, there was just a kerfuffle about spelling things like this
> "--no-clean" etc. I wasn't on board with removing existing spellings,
> but surely all newly added switches should use the "no-" spelling?
This is supposed to be parallel to initdb's option. So
On Sat, Sep 10, 2016 at 6:27 PM, Peter Eisentraut
wrote:
> In fsync_pgdata(), you have removed the progname from one error
> message, even though it is passed into the function.
Right. Good catch.
> Also, I think
> fsync_pgdata() should not be printing initdb's progress messages.
> That should s
On Tue, Sep 13, 2016 at 10:37 AM, Andres Freund wrote:
> On 2016-09-13 10:35:38 +0900, Michael Paquier wrote:
>> On Sat, Sep 10, 2016 at 7:36 PM, Craig Ringer
>> wrote:
>> > We need it for tap tests. More and more will use pg_basebackup and it'll
>> > start hurting test speeds badly.
>>
>> Ah yes
On 2016-09-13 10:35:38 +0900, Michael Paquier wrote:
> On Sat, Sep 10, 2016 at 7:36 PM, Craig Ringer
> wrote:
> > We need it for tap tests. More and more will use pg_basebackup and it'll
> > start hurting test speeds badly.
>
> Ah yes, that's a good argument. hamster would suffer pretty badly
> a
On Sat, Sep 10, 2016 at 7:36 PM, Craig Ringer
wrote:
> We need it for tap tests. More and more will use pg_basebackup and it'll
> start hurting test speeds badly.
Ah yes, that's a good argument. hamster would suffer pretty badly
after that if nothing is done. I'll get an extra patch out for that,
Peter Eisentraut writes:
> On 8/19/16 1:04 AM, Masahiko Sawada wrote:
>> I agree with adding this as an option and removing directory by default.
>> And it looks good to me except for missing new line in usage output.
>>
>> printf(_(" -l, --label=LABEL set backup label\n"));
>> + prin
On 8/19/16 1:04 AM, Masahiko Sawada wrote:
> I agree with adding this as an option and removing directory by default.
> And it looks good to me except for missing new line in usage output.
>
> printf(_(" -l, --label=LABEL set backup label\n"));
> + printf(_(" -n, --noclean
On 3 Sep. 2016 9:22 pm, "Michael Paquier" wrote:
>
> On Sat, Sep 3, 2016 at 12:42 AM, Magnus Hagander
wrote:
> > On Fri, Sep 2, 2016 at 8:50 AM, Michael Paquier <
michael.paqu...@gmail.com>
> > wrote:
> >> On Fri, Sep 2, 2016 at 2:20 AM, Peter Eisentraut
> >> wrote:
> >> > On 5/13/16 2:39 AM, Mi
On 9/3/16 9:23 AM, Michael Paquier wrote:
> On Sat, Sep 3, 2016 at 10:22 PM, Michael Paquier
> wrote:
>> On Sat, Sep 3, 2016 at 10:21 PM, Michael Paquier
>> wrote:
>>> Oh, well. I have just implemented it on top of the two other patches
>>> for pg_basebackup. For pg_receivexlog, I am wondering if
On Sat, Sep 3, 2016 at 10:35 PM, Magnus Hagander wrote:
> Ugh. That would be nice to have, but I think that's outside the scope of
> this patch.
A test for this patch that could have value would be to use
pg_basebackup -X stream -Ft, then untar pg_xlog.tar and look at the
size of the segments. If
On Thu, Sep 1, 2016 at 2:39 PM, Michael Paquier
wrote:
> On Thu, Sep 1, 2016 at 5:13 PM, Magnus Hagander
> wrote:
> > We don't seem to check for similar issues as the one just found in the
> > existing tests though, do we? As in, we don't actually verify that the
> xlog
> > files being streamed
On Sat, Sep 3, 2016 at 10:26 PM, Magnus Hagander wrote:
> Yes, we should definitely not allow that combination. In fact, maybe that
> argument in itself is enough not to have it for pg_receivexlog -- the cause
> of confusion.
>
> I can see how you might want to avoid it for pg_basebackup during te
On Sat, Sep 3, 2016 at 3:21 PM, Michael Paquier
wrote:
> On Sat, Sep 3, 2016 at 12:42 AM, Magnus Hagander
> wrote:
> > On Fri, Sep 2, 2016 at 8:50 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >> On Fri, Sep 2, 2016 at 2:20 AM, Peter Eisentraut
> >> wrote:
> >> > On 5/13/16 2:
On Sat, Sep 3, 2016 at 10:22 PM, Michael Paquier
wrote:
> On Sat, Sep 3, 2016 at 10:21 PM, Michael Paquier
> wrote:
>> Oh, well. I have just implemented it on top of the two other patches
>> for pg_basebackup. For pg_receivexlog, I am wondering if it makes
>> sense to have it. That would be trivi
On Sat, Sep 3, 2016 at 10:21 PM, Michael Paquier
wrote:
> On Sat, Sep 3, 2016 at 12:42 AM, Magnus Hagander wrote:
>> On Fri, Sep 2, 2016 at 8:50 AM, Michael Paquier
>> wrote:
>>> On Fri, Sep 2, 2016 at 2:20 AM, Peter Eisentraut
>>> wrote:
>>> > On 5/13/16 2:39 AM, Michael Paquier wrote:
>>> Wha
On Sat, Sep 3, 2016 at 12:42 AM, Magnus Hagander wrote:
> On Fri, Sep 2, 2016 at 8:50 AM, Michael Paquier
> wrote:
>> On Fri, Sep 2, 2016 at 2:20 AM, Peter Eisentraut
>> wrote:
>> > On 5/13/16 2:39 AM, Michael Paquier wrote:
>> What do others think about that? I could implement that on top of 00
On Fri, Sep 2, 2016 at 8:50 AM, Michael Paquier
wrote:
> On Fri, Sep 2, 2016 at 2:20 AM, Peter Eisentraut
> wrote:
> > On 5/13/16 2:39 AM, Michael Paquier wrote:
> >> So, attached are two patches that apply on HEAD to address the problem
> >> of pg_basebackup that does not sync the data it write
On Fri, Sep 2, 2016 at 2:20 AM, Peter Eisentraut
wrote:
> On 5/13/16 2:39 AM, Michael Paquier wrote:
>> So, attached are two patches that apply on HEAD to address the problem
>> of pg_basebackup that does not sync the data it writes. As
>> pg_basebackup cannot use directly initdb -S because, as a
On 5/13/16 2:39 AM, Michael Paquier wrote:
> So, attached are two patches that apply on HEAD to address the problem
> of pg_basebackup that does not sync the data it writes. As
> pg_basebackup cannot use directly initdb -S because, as a client-side
> utility, it may be installed while initdb is not
On Thu, Sep 1, 2016 at 5:13 PM, Magnus Hagander wrote:
> We don't seem to check for similar issues as the one just found in the
> existing tests though, do we? As in, we don't actually verify that the xlog
> files being streamed are 16Mb? (Or for that matter that the tarfile emitted
> by -Ft is ac
1 - 100 of 523 matches
Mail list logo
