On Wed, Jun 10, 2015 at 12:29 PM, Joshua D. Drake
wrote:
>
> On 06/09/2015 05:54 PM, Michael Paquier wrote:
>
>> Looking at the documentation what is expected is not a path to a
>> segment file, but only a segment file name:
>> http://www.postgresql.org/docs/devel/static/pgarchivecleanup.html
>>
On 06/09/2015 05:54 PM, Michael Paquier wrote:
Looking at the documentation what is expected is not a path to a
segment file, but only a segment file name:
http://www.postgresql.org/docs/devel/static/pgarchivecleanup.html
So the current behavior is correct, it is actually what
SetWALFileNameFor
On Wed, Jun 10, 2015 at 7:27 AM, Joshua D. Drake wrote:
> Trying to use pg_archivecleanup as a:
>
> "standalone archive cleaner"
>
> Results in an error of:
>
> pg_archivecleanup: invalid filename input
> Try "pg_archivecleanup --help" for more information.
>
> /usr/pgsql-9.4/bin/pg_archivecleanup
Hello,
Trying to use pg_archivecleanup as a:
"standalone archive cleaner"
Results in an error of:
pg_archivecleanup: invalid filename input
Try "pg_archivecleanup --help" for more information.
/usr/pgsql-9.4/bin/pg_archivecleanup /backups/db1/archive
0001074800B1.00015838.backup
On Wed, Mar 19, 2014 at 02:02:50PM -0400, Bruce Momjian wrote:
> The attached patch is slightly updated. I will apply it to head and all
> the back branches, including the stylistic change to pg_resetxlog (for
> consistency) and remove the MinGW block in head.
Patch applied back through 8.4. I h
On Wed, Mar 19, 2014 at 09:59:19AM +0200, Heikki Linnakangas wrote:
> >Would people accept?
> >
> > for (errno = 0; (dirent = readdir(dir)) != NULL; errno = 0)
> >
> >That would keep the errno's together and avoid the 'continue' additions.
>
> That's clever. A less clever way would be:
>
> fo
On 03/19/2014 02:30 AM, Bruce Momjian wrote:
On Tue, Mar 18, 2014 at 09:13:28PM +0200, Heikki Linnakangas wrote:
On 03/18/2014 09:04 PM, Simon Riggs wrote:
On 18 March 2014 18:55, Alvaro Herrera wrote:
That said, I don't find comma expression to be particularly "not
simple".
Maybe, but we'
Bruce Momjian writes:
> Would people accept?
> for (errno = 0; (dirent = readdir(dir)) != NULL; errno = 0)
It's a bit weird looking, but I agree that there's value in only needing
the errno-zeroing in precisely one place.
regards, tom lane
--
Sent via pgsql-hack
On Tue, Mar 18, 2014 at 09:13:28PM +0200, Heikki Linnakangas wrote:
> On 03/18/2014 09:04 PM, Simon Riggs wrote:
> >On 18 March 2014 18:55, Alvaro Herrera wrote:
> >
> >>That said, I don't find comma expression to be particularly "not
> >>simple".
> >
> >Maybe, but we've not used it before anywher
On 03/18/2014 09:04 PM, Simon Riggs wrote:
On 18 March 2014 18:55, Alvaro Herrera wrote:
That said, I don't find comma expression to be particularly "not
simple".
Maybe, but we've not used it before anywhere in Postgres, so I don't
see a reason to start now. Especially since C is not the nat
On 18 March 2014 18:55, Alvaro Herrera wrote:
> That said, I don't find comma expression to be particularly "not
> simple".
Maybe, but we've not used it before anywhere in Postgres, so I don't
see a reason to start now. Especially since C is not the native
language of many people these days and
Simon Riggs escribió:
> On 18 March 2014 18:18, Bruce Momjian wrote:
> > On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote:
> >> Why make style changes at all? A patch with no style changes would
> >> mean backpatch and HEAD versions would be the same.
> >
> > The old style had errno se
On 18 March 2014 18:18, Bruce Momjian wrote:
> On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote:
>> On 18 March 2014 18:01, Bruce Momjian wrote:
>> > On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote:
>> >> > While I am not a fan of backpatching, the fact we are ignoring erro
Bruce Momjian escribió:
> On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote:
> > On 18 March 2014 18:01, Bruce Momjian wrote:
> > > On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote:
> > >> > While I am not a fan of backpatching, the fact we are ignoring errors
> > >> > in
> >
On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote:
> On 18 March 2014 18:01, Bruce Momjian wrote:
> > On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote:
> >> > While I am not a fan of backpatching, the fact we are ignoring errors in
> >> > some critical cases seems the non-cosm
On 18 March 2014 18:01, Bruce Momjian wrote:
> On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote:
>> > While I am not a fan of backpatching, the fact we are ignoring errors in
>> > some critical cases seems the non-cosmetic parts should be backpatched.
>>
>> pg_resetxlog was not an offen
On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote:
> > While I am not a fan of backpatching, the fact we are ignoring errors in
> > some critical cases seems the non-cosmetic parts should be backpatched.
>
> pg_resetxlog was not an offender here; its coding was sound.
>
> We shouldn't b
On 13 March 2014 05:48, Bruce Momjian wrote:
> On Mon, Dec 9, 2013 at 11:27:28AM -0500, Robert Haas wrote:
>> On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane wrote:
>> > But the other usages seem to be in assorted utilities, which
>> > will need to do it right for themselves. initdb.c's walkdir() seem
On 18 March 2014 15:50, Robert Haas wrote:
> On Tue, Mar 18, 2014 at 11:36 AM, Simon Riggs wrote:
>> Given the above, this means we've run for about 7 years without a
>> reported issue on this. If we are going to "make this better" by
>> actually having it throw errors in places that didn't throw
On Tue, Mar 18, 2014 at 11:36 AM, Simon Riggs wrote:
> Given the above, this means we've run for about 7 years without a
> reported issue on this. If we are going to "make this better" by
> actually having it throw errors in places that didn't throw errors
> before, are we sure that is going to ma
On 18 March 2014 14:15, Alvaro Herrera wrote:
> Bruce Momjian escribió:
>> On Tue, Mar 18, 2014 at 10:03:46AM -0400, Robert Haas wrote:
>> > On Tue, Mar 18, 2014 at 9:56 AM, Tom Lane wrote:
>> > > Bruce Momjian writes:
>> > >> Very good point. I have modified the patch to add this block in all
Bruce Momjian escribió:
> On Tue, Mar 18, 2014 at 10:03:46AM -0400, Robert Haas wrote:
> > On Tue, Mar 18, 2014 at 9:56 AM, Tom Lane wrote:
> > > Bruce Momjian writes:
> > >> Very good point. I have modified the patch to add this block in all
> > >> cases where it was missing. I started to wond
On Tue, Mar 18, 2014 at 10:03:46AM -0400, Robert Haas wrote:
> On Tue, Mar 18, 2014 at 9:56 AM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> Very good point. I have modified the patch to add this block in all
> >> cases where it was missing. I started to wonder about the comment and
> >> if t
On Tue, Mar 18, 2014 at 9:56 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> Very good point. I have modified the patch to add this block in all
>> cases where it was missing. I started to wonder about the comment and
>> if the Mingw fix was released. Based on some research, I see this as
>> fi
Bruce Momjian writes:
> Very good point. I have modified the patch to add this block in all
> cases where it was missing. I started to wonder about the comment and
> if the Mingw fix was released. Based on some research, I see this as
> fixed in mingw-runtime-3.2, released 2003-10-10. That's p
On Tue, Mar 18, 2014 at 11:25:46AM +0530, Amit Kapila wrote:
> On Thu, Mar 13, 2014 at 11:18 AM, Bruce Momjian wrote:
> >
> > I have developed the attached patch which fixes all cases where
> > readdir() wasn't checking for errno, and cleaned up the syntax in other
> > cases to be consistent.
>
>
On Thu, Mar 13, 2014 at 11:18 AM, Bruce Momjian wrote:
>
> I have developed the attached patch which fixes all cases where
> readdir() wasn't checking for errno, and cleaned up the syntax in other
> cases to be consistent.
1. One common thing missed wherever handling for errno is added
is below
On Thu, Mar 13, 2014 at 1:48 AM, Bruce Momjian wrote:
> On Mon, Dec 9, 2013 at 11:27:28AM -0500, Robert Haas wrote:
>> On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane wrote:
>> > But the other usages seem to be in assorted utilities, which
>> > will need to do it right for themselves. initdb.c's walkd
On Mon, Dec 9, 2013 at 11:27:28AM -0500, Robert Haas wrote:
> On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane wrote:
> > But the other usages seem to be in assorted utilities, which
> > will need to do it right for themselves. initdb.c's walkdir() seems to
> > have it right and might be a reasonable mo
On Thu, Dec 5, 2013 at 12:06:07PM -0800, Kevin Grittner wrote:
> An EDB customer reported a problem with pg_archivecleanup which I
> have looked into and found a likely cause. It is, in any event, a
> bug which I think should be fixed. It has to do with our use of
> the readdir() function:
>
>
On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane wrote:
> But the other usages seem to be in assorted utilities, which
> will need to do it right for themselves. initdb.c's walkdir() seems to
> have it right and might be a reasonable model to follow. Or maybe we
> should invent a frontend-friendly versi
On Fri, Dec 6, 2013 at 11:10 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane wrote:
>>> In general, I think there is no excuse for code in the backend to use
>>> readdir() directly; it should be using ReadDir(), which takes care of this
>>> as well as error
Robert Haas writes:
> On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane wrote:
>> In general, I think there is no excuse for code in the backend to use
>> readdir() directly; it should be using ReadDir(), which takes care of this
>> as well as error reporting.
> My understanding is that the fd.c infrastr
On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane wrote:
> In general, I think there is no excuse for code in the backend to use
> readdir() directly; it should be using ReadDir(), which takes care of this
> as well as error reporting.
My understanding is that the fd.c infrastructure can't be used in the
Kevin Grittner writes:
> | Applications wishing to check for error situations should set
> | errno to 0 before calling readdir(). If errno is set to non-zero
> | on return, an error occurred.
> So an error in scanning the directory will not be reported; the
> cleanup will quietly terminate the WA
On Thu, Dec 5, 2013 at 3:06 PM, Kevin Grittner wrote:
> An EDB customer reported a problem with pg_archivecleanup which I
> have looked into and found a likely cause. It is, in any event, a
> bug which I think should be fixed. It has to do with our use of
> the readdir() function:
>
> http://pub
An EDB customer reported a problem with pg_archivecleanup which I
have looked into and found a likely cause. It is, in any event, a
bug which I think should be fixed. It has to do with our use of
the readdir() function:
http://pubs.opengroup.org/onlinepubs/7908799/xsh/readdir_r.html
These are t
37 matches
Mail list logo
