On 6/3/16 4:13 PM, Robert Haas wrote:
> On Fri, Jun 3, 2016 at 2:12 PM, Andres Freund wrote:
>> On 2016-06-03 14:00:00 -0400, Robert Haas wrote:
>>> On Fri, May 27, 2016 at 8:44 PM, Andres Freund wrote:
I'm not convinced of that. Hiding unexpected issues for longer, just to
continue ki
On Fri, Jun 3, 2016 at 2:12 PM, Andres Freund wrote:
> On 2016-06-03 14:00:00 -0400, Robert Haas wrote:
>> On Fri, May 27, 2016 at 8:44 PM, Andres Freund wrote:
>> > I'm not convinced of that. Hiding unexpected issues for longer, just to
>> > continue kind-of-operating, can make the impact of pr
On 2016-06-03 14:00:00 -0400, Robert Haas wrote:
> On Fri, May 27, 2016 at 8:44 PM, Andres Freund wrote:
> > I'm not convinced of that. Hiding unexpected issues for longer, just to
> > continue kind-of-operating, can make the impact of problems a lot worse,
> > and it makes it very hard to actual
On Fri, May 27, 2016 at 8:44 PM, Andres Freund wrote:
> I'm not convinced of that. Hiding unexpected issues for longer, just to
> continue kind-of-operating, can make the impact of problems a lot worse,
> and it makes it very hard to actually learn about the issues.
So if we made this a WARNING
, ["cp", "/pgdata/postXX_95_orig_wal/0"...,
"pg_xlog/RECOVERYXLOG"], [/* 60 vars */]) = 0
24623 stat("pg_xlog/RECOVERYXLOG", 0x7ffd4a373c40) = -1 ENOENT (No such file or
directory)
24623 stat("pg_xlog/RECOVERYXLOG", 0x7ffd4a373a60) = -1 ENOENT (No
On 2016-05-30 12:51:17 +0900, Michael Paquier wrote:
> On Sat, May 28, 2016 at 9:57 AM, Andres Freund wrote:
> > On 2016-05-27 20:54:43 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >> > On 2016-05-26 12:44:51 -0400, Tom Lane wrote:
> >> > 2016-04-27 17:02:06 EDT 572128cd.1811 [7-1] user=,d
On Sat, May 28, 2016 at 9:57 AM, Andres Freund wrote:
> On 2016-05-27 20:54:43 -0400, Tom Lane wrote:
>> Andres Freund writes:
>> > On 2016-05-26 12:44:51 -0400, Tom Lane wrote:
>> > 2016-04-27 17:02:06 EDT 572128cd.1811 [7-1] user=,db=,remote= FATAL:
>> > 42501:
>> > could not open file "pg_xl
On 2016-05-27 20:54:43 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-05-26 12:44:51 -0400, Tom Lane wrote:
> > 2016-04-27 17:02:06 EDT 572128cd.1811 [7-1] user=,db=,remote= FATAL: 42501:
> > could not open file "pg_xlog/RECOVERYXLOG": Permission denied
>
> > So, what's the permissio
Andres Freund writes:
> On 2016-05-26 12:44:51 -0400, Tom Lane wrote:
> 2016-04-27 17:02:06 EDT 572128cd.1811 [7-1] user=,db=,remote= FATAL: 42501:
> could not open file "pg_xlog/RECOVERYXLOG": Permission denied
> So, what's the permission of RECOVERYXLOG at that point? It's pretty
> weird that
On 2016-05-26 12:44:51 -0400, Tom Lane wrote:
> > 2016-04-27 17:02:06 EDT 572128cd.1811 [7-1] user=,db=,remote= FATAL: 42501:
> > could not open file "pg_xlog/RECOVERYXLOG": Permission denied
So, what's the permission of RECOVERYXLOG at that point? It's pretty
weird that directly after running r
[ redirecting to -hackers ]
writes:
> When performing a vanilla database restore using either the 9.2.16 or 9.2.17
> executables (i.e. just restoring the database files from a 'tar' backup and
> reading the WAL files created during the 'tar' backup - no specific PIT given
> in recovery.conf) t
11 matches
Mail list logo
