Thread: -D option of pg_resetwal is only works with absolute path
Hi, In the latest PG v11, found that -D option of pg_resetwal is only works with absolute path .. not with relative path e.g Not Working - [centos@localhost bin]$ ./pg_resetwal -D data pg_resetwal: could not read permissions of directory "data": No such file or directory Working - [centos@localhost bin]$ ./pg_resetwal -D /home/centos/pg11_22may/postgresql/edbpsql/bin/data Write-ahead log reset Is this something expected in v11 ? -- regards,tushar EnterpriseDB https://www.enterprisedb.com/ The Enterprise PostgreSQL Company
tushar <tushar.ahuja@enterprisedb.com> writes:
> In the latest PG v11, found that -D option of pg_resetwal is only
> works with absolute path .. not with relative path
Confirmed here. This did work in previous releases, so I'd say it's
unquestionably a bug.
[ diffs v10 against head... ]
Seems to be caused by careless placement of new umask-changing code.
I wonder how many other places that patch broke similarly.
regards, tom lane
On 5/23/18 10:08 AM, Tom Lane wrote: > tushar <tushar.ahuja@enterprisedb.com> writes: >> In the latest PG v11, found that -D option of pg_resetwal is only >> works with absolute path .. not with relative path > > Confirmed here. This did work in previous releases, so I'd say it's > unquestionably a bug. > > [ diffs v10 against head... ] > > Seems to be caused by careless placement of new umask-changing code. > I wonder how many other places that patch broke similarly. I'll look into this today. -- -David david@pgmasters.net
David Steele <david@pgmasters.net> writes:
> On 5/23/18 10:08 AM, Tom Lane wrote:
>> Seems to be caused by careless placement of new umask-changing code.
>> I wonder how many other places that patch broke similarly.
> I'll look into this today.
I pushed a patch already, although certainly an additional pair of eyes
on the issue would be good.
regards, tom lane
On 5/23/18 11:35 AM, Tom Lane wrote: > David Steele <david@pgmasters.net> writes: >> On 5/23/18 10:08 AM, Tom Lane wrote: >>> Seems to be caused by careless placement of new umask-changing code. >>> I wonder how many other places that patch broke similarly. > >> I'll look into this today. > > I pushed a patch already, although certainly an additional pair of eyes > on the issue would be good. Looks good to me. Thanks! -- -David david@pgmasters.net
On Wed, May 23, 2018 at 11:40:48AM -0400, David Steele wrote: > On 5/23/18 11:35 AM, Tom Lane wrote: >> I pushed a patch already, although certainly an additional pair of eyes >> on the issue would be good. > > Looks good to me. Thanks! The TAP tests cannot catch that as all paths are absolute in PostgresNode.pm. We could easily have tests using chdir though. Thoughts? -- Michael