On 7/25/18 11:26 AM, Andres Freund wrote:
On 2018-07-25 11:19:49 -0400, David Steele wrote:
If one wanted to improve recoverability in scenarios like this, there'd
be actually useful things like adding the option to extract control
files, FPIs, clog contents from the WAL with pg_waldump.
I
David Steele writes:
> On 7/25/18 11:09 AM, Andres Freund wrote:
>> The problem is that that'll just hide the issue for a bit longer, while
>> continuing (due to the O_CREAT we'll not PANIC anymore). Which can lead
>> to a lot of followup issues, like checkpoints removing old WAL that'd
>> have
Hi,
On 2018-07-25 11:19:49 -0400, David Steele wrote:
> On 7/25/18 11:09 AM, Andres Freund wrote:
> > On 2018-07-25 10:52:08 -0400, David Steele wrote:
> > The problem is that that'll just hide the issue for a bit longer, while
> > continuing (due to the O_CREAT we'll not PANIC anymore). Which
David Steele writes:
> On 7/25/18 10:37 AM, Andres Freund wrote:
>> What would we win here? Which scenario that's not contrived would be less
>> bad due to the proposed change. This seems complexity for it's own sake.
> I favor the contrived scenario that helps preserve the current cluster
>
On 7/25/18 11:09 AM, Andres Freund wrote:
On 2018-07-25 10:52:08 -0400, David Steele wrote:
I favor the contrived scenario that helps preserve the current cluster
instead of a hypothetical newly init'd one. I also don't think that users
deleting files out of a cluster is all that contrived.
Hi,
On 2018-07-25 10:52:08 -0400, David Steele wrote:
> On 7/25/18 10:37 AM, Andres Freund wrote:
> > On July 25, 2018 7:18:30 AM PDT, David Steele wrote:
> > >
> > > It seems like an easy win if we can find a safe way to do it, though I
> > > admit that this is only a benefit in corner cases.
On 7/25/18 10:37 AM, Andres Freund wrote:
On July 25, 2018 7:18:30 AM PDT, David Steele wrote:
It seems like an easy win if we can find a safe way to do it, though I
admit that this is only a benefit in corner cases.
What would we win here? Which scenario that's not contrived would be less
On July 25, 2018 7:18:30 AM PDT, David Steele wrote:
>On 7/23/18 7:00 PM, Tom Lane wrote:
>> Brian Faherty writes:
> >
>>> There does not really seem to be a need for this behavior as all the
>>> information postgres needs is in memory at this point. I propose
>with
>>> a patch to just
On 7/23/18 7:00 PM, Tom Lane wrote:
Brian Faherty writes:
>
There does not really seem to be a need for this behavior as all the
information postgres needs is in memory at this point. I propose with
a patch to just recreate pg_control on updates if it does not exist.
I would vote to reject
On 24 July 2018 at 03:31, Brian Faherty
wrote:
> Hey Hackers,
>
> If a postmaster is running and the pg_control file is removed postgres
> will PANIC.
How does that happen?
"Don't go deleting stuff in pgdata" is pretty fundamental.
On Mon, Jul 23, 2018 at 07:00:30PM -0400, Tom Lane wrote:
> I would vote to reject any such patch; it's too likely to cause more
> problems than it solves. Generally, if critical files like that one
> have disappeared, trying to write new data isn't going to be enough
> to fix it and could well
On July 23, 2018 12:31:13 PM PDT, Brian Faherty
wrote:
>Hey Hackers,
>
>If a postmaster is running and the pg_control file is removed postgres
>will PANIC.
>
>Steps to recreate:
>
>1.) start a new cluster
>2.) rm $DATADIR/pg_control
>3.) psql => CHECKPOINT;
>
>PANIC: could not open control
On Mon, Jul 23, 2018 at 12:31 PM, Brian Faherty <
anothergenericu...@gmail.com> wrote:
> There does not really seem to be a need for this behavior as all the
> information postgres needs is in memory at this point. I propose with
> a patch to just recreate pg_control on updates if it does not
Hey Hackers,
If a postmaster is running and the pg_control file is removed postgres
will PANIC.
Steps to recreate:
1.) start a new cluster
2.) rm $DATADIR/pg_control
3.) psql => CHECKPOINT;
PANIC: could not open control file "global/pg_control": No such file
or directory
After the PANIC
14 matches
Mail list logo
