Re: [HACKERS] WAL feature
[ 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 [EMAIL PROTECTED] | (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
RE: [HACKERS] WAL feature
> 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
RE: [HACKERS] WAL feature
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? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
RE: [HACKERS] WAL feature
> > > 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] WAL feature
> 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 [EMAIL PROTECTED] | (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] WAL feature
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 ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: [HACKERS] WAL feature
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 :) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] WAL feature
> 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 [EMAIL PROTECTED] | (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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] WAL feature
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 ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
RE: [HACKERS] 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 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
