WAL feature
WAL was a difficult feature to add to 7.1. Currently, it is only used
as a performance benefit, but I expect it will be used in the future to
add new features like:
Advanced Replication
Point-in-time recovery
Row reuse without vacuum
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
WAL was a difficult feature to add to 7.1. Currently, it is only used
as a performance benefit, but I expect it will be used in the future to
Not only. Did you forget about btree stability?
Partial disk writes?
add new features like:
Advanced Replication
I'm for sure not fan of this.
Point-in-time recovery
Row reuse without vacuum
Yes, it will help to remove uncommitted rows.
And don't forget about SAVEPOINTs.
Vadim
Import Notes
Resolved by subject fallback
On Fri, 27 Apr 2001, Bruce Momjian wrote:
WAL was a difficult feature to add to 7.1. Currently, it is only used
as a performance benefit, but I expect it will be used in the future to
add new features like:Advanced Replication
How?
Point-in-time recovery
I thought that was understood from Vadim's explanations?
Row reuse without vacuum
How? Didn't even see these as being related ...
On Fri, 27 Apr 2001, Bruce Momjian wrote:
WAL was a difficult feature to add to 7.1. Currently, it is only used
as a performance benefit, but I expect it will be used in the future to
add new features like:Advanced Replication
How?
I guess other hosts could read the WAL to find out what changed.
Point-in-time recovery
I thought that was understood from Vadim's explanations?
Yes, I am just reiterating that WAL may be related to future new
features.
Row reuse without vacuum
How? Didn't even see these as being related ...
It may be. Not sure.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Fri, 27 Apr 2001, Mikheev, Vadim wrote:
Row reuse without vacuum
Yes, it will help to remove uncommitted rows.
Same question as I asked Bruce ... how? :) I wasn't trying to be
fascisious(sp?) when I asked, I didn't realize the two were connected and
am curious as to how :)
On Fri, 27 Apr 2001, Bruce Momjian wrote:
How?
I guess other hosts could read the WAL to find out what changed.
I wonder if that would get around one of the issues I had brought up a
ways back concerning replication and stuff like sequences ...
Row reuse without vacuum
How? Didn't even see these as being related ...
It may be. Not sure.
Neither am I ... Vadim seems to think so, so am curious as to how ...
On Fri, 27 Apr 2001, Bruce Momjian wrote:
How?
I guess other hosts could read the WAL to find out what changed.
I wonder if that would get around one of the issues I had brought up a
ways back concerning replication and stuff like sequences ...
Yep, WAL collects all database changes into one file. Easy to see how
some other host trying to replication a different host would find the
WAL contents valuable.
Row reuse without vacuum
How? Didn't even see these as being related ...
It may be. Not sure.
Neither am I ... Vadim seems to think so, so am curious as to how ...
I think my point is that WAL could prove to be very valuable in a number
of areas, perhaps more areas than we know of right now. In fact, I
think one idea once we start 7.2 is to identify how we want to use WAL
in the upcoming 7.2 features, make any needed WAL improvements, then
start adding features.
WAL was tough to add, but there are probably a lot of nice things was
can do now that we have it.
Also, Vadim mentioned that WAL fixed btree corruption problems, which
was certainly important too.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Row reuse without vacuum
Yes, it will help to remove uncommitted rows.
Same question as I asked Bruce ... how? :) I wasn't trying to be
fascisious(sp?) when I asked, I didn't realize the two were
connected and am curious as to how :)
After implementing UNDO operation (we have only REDO now)
transactions will roll back their changes on abort and so
free space occupied by inserted rows.
How to re-use freed space (ie how to maintain information about
blocks available for insertion of new rows) is another issue,
of course, but anyway - space must be freed first.
Vadim
Import Notes
Resolved by subject fallback
On Fri, 27 Apr 2001, Mikheev, Vadim wrote:
Row reuse without vacuum
Yes, it will help to remove uncommitted rows.
Same question as I asked Bruce ... how? :) I wasn't trying to be
fascisious(sp?) when I asked, I didn't realize the two were
connected and am curious as to how :)After implementing UNDO operation (we have only REDO now)
transactions will roll back their changes on abort and so
free space occupied by inserted rows.
Ahhh, okay, so this isn't reusing space on delete/update, so much as
avoiding writing to the table until the transaction is committed?
Yep, WAL collects all database changes into one file. Easy to see how
some other host trying to replication a different host would find the
WAL contents valuable.
Unfortunately, slave database(s) should be on the same platform
(hardware+OS) to be able to use information about *physical*
changes in data files. Also, this would be still *async* replication.
Maybe faster than rserv, maybe with less space requirements (no rserv'
log table), but maybe not.
I believe that making efforts to implement (bi-directional) *sync*
replication would be more valuable.
Vadim
Import Notes
Resolved by subject fallback
[ Charset ISO-8859-1 unsupported, converting... ]
Yep, WAL collects all database changes into one file. Easy to see how
some other host trying to replication a different host would find the
WAL contents valuable.Unfortunately, slave database(s) should be on the same platform
(hardware+OS) to be able to use information about *physical*
changes in data files. Also, this would be still *async* replication.
Maybe faster than rserv, maybe with less space requirements (no rserv'
log table), but maybe not.I believe that making efforts to implement (bi-directional) *sync*
replication would be more valuable.
Or maybe an platform-neutral interface to the WAL file. Seems this
would fit a need.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
What about incremental backup ?
"Bruce Momjian" <pgman@candle.pha.pa.us> �������/�������� � ��������
���������: news:200104272103.f3RL3ur23234@candle.pha.pa.us...
Show quoted text
WAL was a difficult feature to add to 7.1. Currently, it is only used
as a performance benefit, but I expect it will be used in the future to
add new features like:Advanced Replication
Point-in-time recovery
Row reuse without vacuum-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?