Thread: 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 ReplicationPoint-in-time recoveryRow 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, Pennsylvania19026
> 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
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, Pennsylvania19026
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, Pennsylvania19026
> > > 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
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
[ 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, Pennsylvania19026
What about incremental backup ? "Bruce Momjian" <pgman@candle.pha.pa.us> �������/�������� � �������� ���������: news:200104272103.f3RL3ur23234@candle.pha.pa.us... > > 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? > > http://www.postgresql.org/search.mpl