Please forgive me if I'm misunderstanding something of these rather
complex issues. But I think this is an important question from the
perspective of a sytem administrator responsible for the safety and
uncorruptedness of his users' data.
If I understand correctly, it is possible, through power
> Other than what we've discussed, do you have any
> comments/objections to my proposed patch?
> I've been holding off committing it so that you have
> time to review it...
Sorry - I'm heading to meet Marc, Thomas & Geoff right now,
will try to comment asap.
Vadim
---(e
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> No, but I want a system that's not brittle. You seem to be content to
>> design a system that is reliable as long as the WAL log is OK
>> but loses the entire database unrecoverably as soon as one bit goes bad
>> in the log.
> I don't see how absen
> > It seems that you want guarantee more than me, Tom -:)
>
> No, but I want a system that's not brittle. You seem to be content to
> design a system that is reliable as long as the WAL log is OK
> but loses the entire database unrecoverably as soon as one bit goes bad
> in the log.
I don't se
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> And how well will that approach work if the last checkpoint record
>> got written near the start of a log segment file, and then the
>> checkpointer discarded all your prior log segments because "you don't
>> need those anymore"? If the checkpoint r
What do we debate?
I never told that we shouldn't worry about current WAL disability to restart.
And WAL already correctly works in situation of "failing to write a couple of disk
blocks when the system crashes".
My statement at first place that "WAL can't help in the event of disk errors"
was to
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> If fsync may return before data *actually* flushed then you may have
> unlogged data page changes which breakes WAL rule and means corrupted
> (inconsistent) database without ANY ABILITY TO RECOVERY TO CONSISTENT
> STATE. Now please explain me how sa
> > If there is no pg_control or it's corrupted or points to
> > unexistent/corrupted checkpoint record then scan logs from
> > newest to oldest one till we find last valid checkpoint record
> > or oldest valid log record and than redo from there.
>
> And how well will that approach work if the l
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> "two checkpoints" approach is not the best way to follow.
> From my POV, scanning logs is much better - it doesn't require
> doubling size of on-line logs and allows to *restart* if pg_control
> was lost/corrupted:
> If there is no pg_control or it'
> >> * Store two past checkpoint locations, not just one, in pg_control.
> >> On startup, we fall back to the older checkpoint if the newer one
> >> is unreadable. Also, a physical copy of the newest
> >> checkpoint record
>
> > And what to do if older one is unreadable too?
> > (Isn't it like
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> If fsync may return before data *actually* flushed then you may have
> unlogged data page changes which breakes WAL rule and means corrupted
> (inconsistent) database without ANY ABILITY TO RECOVERY TO CONSISTENT
> STATE. Now please explain me how sav
> > But what can be done if fsync returns before pages flushed?
>
> When you write out critical information, you keep earlier versions of
> it. On startup, if the critical information is corrupt, you use the
> earlier versions of it. This helps protect against the scenario I
> mentioned: a few
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Why not? How is this a critical parameter (more critical than, say,
> >> fsync enable)?
>
> > Does it have any meaning other than testing ? IMHO recovery system
> > doesn't allow any optimism and archdir is al
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Why not? How is this a critical parameter (more critical than, say,
>> fsync enable)?
> I don't think 'fsync enable' is a critical parameter.
> It's a dangerous parameter and it's not appropriate
> as a GUC paramter either.
That's
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> >> But what possible reason is there for keeping it in pg_control?
> >> AFAICS that would just mean that we'd need special code for setting it,
> >> instead of making use of all of Peter's hard work on GUC.
>
> > I don't think it's a
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > > I feel that the fact that
> > >
> > > WAL can't help in the event of disk errors
> > >
> > > is often overlooked.
> >
> > This is true in general. But, nevertheless, WAL can be written to
> > protect against predictable disk errors, when poss
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>> But what possible reason is there for keeping it in pg_control?
>> AFAICS that would just mean that we'd need special code for setting it,
>> instead of making use of all of Peter's hard work on GUC.
> I don't think it's appropriate to edit archdir by
Tom Lane wrote:
>
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > So, it's better to leave archdir in pg_control now - if we'll
> > decide that GUC is better place then we'll just ignore archdir
> > in pg_control. But if it will be better to have it in pg_control
> > then we'll not be able to a
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> So, it's better to leave archdir in pg_control now - if we'll
> decide that GUC is better place then we'll just ignore archdir
> in pg_control. But if it will be better to have it in pg_control
> then we'll not be able to add it there.
But what possi
On Wed, Mar 07, 2001 at 12:03:41PM -0800, Mikheev, Vadim wrote:
> Ian wrote:
> > > I feel that the fact that
> > >
> > > WAL can't help in the event of disk errors
> > >
> > > is often overlooked.
> >
> > This is true in general. But, nevertheless, WAL can be written to
> > protect against pre
On Wed, Mar 07, 2001 at 11:09:25AM -0500, Tom Lane wrote:
> "Vadim Mikheev" <[EMAIL PROTECTED]> writes:
> >> * Store two past checkpoint locations, not just one, in pg_control.
> >> On startup, we fall back to the older checkpoint if the newer one
> >> is unreadable. Also, a physical copy of the
On Wed, 7 Mar 2001, Mikheev, Vadim wrote:
> But what can be done if fsync returns before pages flushed?
No, it won't. When fsync returns, data is promised by the OS to be on
disk.
-alex
---(end of broadcast)---
TIP 6: Have you searched our list a
> > But what can be done if fsync returns before pages flushed?
> No, it won't. When fsync returns, data is promised by the OS to be on
> disk.
Seems you didn't follow discussions about this issue.
Vadim
---(end of broadcast)---
TIP 3: if posting/
> > > I have just sent to the pgsql-patches list a rather large set of
> >
> > Please send it to me directly - pgsql-patches' archieve is
> dated by Feb -:(
>
> Huh?
>
> http://www.postgresql.org/mhonarc/pgsql-patches/2001-03/index.html
But there was nothing there yesterday -:)
(Seems archive
> > I feel that the fact that
> >
> > WAL can't help in the event of disk errors
> >
> > is often overlooked.
>
> This is true in general. But, nevertheless, WAL can be written to
> protect against predictable disk errors, when possible. Failing to
> write a couple of disk blocks when the sys
> > > What I've thought is to implement a new command to
> > > change archdir under WAL's control.
> > > If it's different from Vadim's plan I don't object.
> >
> > Actually, I have no concrete plans for archdir yet - this
> > one is for WAL based BAR we should discuss in future.
> > So, I don't
"Vadim Mikheev" <[EMAIL PROTECTED]> writes:
> I feel that the fact that
>
> WAL can't help in the event of disk errors
>
> is often overlooked.
This is true in general. But, nevertheless, WAL can be written to
protect against predictable disk errors, when possible. Failing to
write a couple
On Wed, 7 Mar 2001, Vadim Mikheev wrote:
> > I have just sent to the pgsql-patches list a rather large set of
>
> Please send it to me directly - pgsql-patches' archieve is dated by Feb -:(
Huh?
http://www.postgresql.org/mhonarc/pgsql-patches/2001-03/index.html
---(en
Tom Lane writes:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Do I have to send SIGHUP after changing postgresql.conf ?
>
> In general, yes. I think that for the (still vaporware) archdir option,
> you might not need to: archdir will only be looked at by the checkpoint
> subprocess, and I thi
"Vadim Mikheev" <[EMAIL PROTECTED]> writes:
>> I have just sent to the pgsql-patches list a rather large set of
> Please send it to me directly - pgsql-patches' archieve is dated by Feb -:(
Done under separate cover.
>> proposed diffs for the WAL code. These changes:
>>
>> * Store two past che
"Vadim Mikheev" <[EMAIL PROTECTED]> writes:
> So, I don't see why to remove archdir from pg_control now.
I didn't like the space consumption. I think it's important that the
pg_control data fit in less than 512 bytes so that it doesn't cross
physical sectors on the disk. This reduces the odds o
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Do I have to send SIGHUP after changing postgresql.conf ?
In general, yes. I think that for the (still vaporware) archdir option,
you might not need to: archdir will only be looked at by the checkpoint
subprocess, and I think that a newly spawned backe
> > > I thought the intended way to change a GUC parameter permanently was to
> > > edit data/postgresql.conf . No ?
> > >
> >
> > What I've thought is to implement a new command to
> > change archdir under WAL's control.
> > If it's different from Vadim's plan I don't object.
>
> Actually, I h
> I have just sent to the pgsql-patches list a rather large set of
Please send it to me directly - pgsql-patches' archieve is dated by Feb -:(
> proposed diffs for the WAL code. These changes:
>
> * Store two past checkpoint locations, not just one, in pg_control.
> On startup, we fall back
> > I thought the intended way to change a GUC parameter permanently was to
> > edit data/postgresql.conf . No ?
> >
>
> What I've thought is to implement a new command to
> change archdir under WAL's control.
> If it's different from Vadim's plan I don't object.
Actually, I have no concrete pla
Zeugswetter Andreas SB wrote:
>
> > Could GUC parameters be changed permanently e.g. by SET command ?
> >
> > For example,
> > 1) start postmaster
> > 2) set archdir to ''
> > 3) shutdown postmaster
>
> I thought the intended way to change a GUC parameter permanently was to
> edit data/postgr
> Could GUC parameters be changed permanently e.g. by SET command ?
>
> For example,
> 1) start postmaster
> 2) set archdir to ''
> 3) shutdown postmaster
I thought the intended way to change a GUC parameter permanently was to
edit data/postgresql.conf . No ?
Andreas
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > Could GUC parameters be changed permanently e.g. by SET command ?
>
> That's what postgresql.conf is for ...
>
Do I have to send SIGHUP after changing postgresql.conf ?
Regards,
Hiroshi Inoue
---(end o
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> Could GUC parameters be changed permanently e.g. by SET command ?
That's what postgresql.conf is for ...
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all li
> -Original Message-
> From: Zeugswetter Andreas SB
>
> > >> Remove archdir from pg_control; it ought to be a GUC
> > >> parameter, not a special case (not that it's implemented
> > yet anyway).
> >
> > > Is archdir really a GUC parameter ?
> >
> > Why shouldn't it be? I see nothing w
> >> Remove archdir from pg_control; it ought to be a GUC
> >> parameter, not a special case (not that it's implemented
> yet anyway).
>
> > Is archdir really a GUC parameter ?
>
> Why shouldn't it be? I see nothing wrong with changing it on-the-fly.
Yes, I think this is a good change, like
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
>> Remove archdir from pg_control; it ought to be a GUC
>> parameter, not a special case (not that it's implemented yet anyway).
> Is archdir really a GUC parameter ?
Why shouldn't it be? I see nothing wrong with changing it on-the-fly.
> -Original Message-
> From: Tom Lane
>
> I have just sent to the pgsql-patches list a rather large set of
> proposed diffs for the WAL code. These changes:
>
> * Store two past checkpoint locations, not just one, in pg_control.
> On startup, we fall back to the older checkpoint if the
I have just sent to the pgsql-patches list a rather large set of
proposed diffs for the WAL code. These changes:
* Store two past checkpoint locations, not just one, in pg_control.
On startup, we fall back to the older checkpoint if the newer one
is unreadable. Also, a physical copy of the
44 matches
Mail list logo
