Обсуждение: RE: [HACKERS] Transaction logging
Your getting me excited about 6.5. Is there a projected release date for 6.5? Is there any information on transaction logging? Is there anything I can do to help? I am curious about these items because they will make my life much easier in the upcoming months as I migrate my application to Postgres. Working around these could be very difficulty or near impossible. -----Original Message-----From: Bruce Momjian [SMTP:maillist@candle.pha.pa.us]Sent: Tuesday, February 23, 1999 8:02PMTo: Michael DavisCc: pgsql-general@postgreSQL.org; pgsql-hackers@postgreSQL.orgSubject: Re: [GENERAL] Transactionlogging > What would it take to have transaction logging added to Postgres. I am a> c/c++ programmer and will consider contributing to the Postgres development> effort. I really like everything I see and read about Postgres. As a> result, I am strongly considering Postgres as the database engine for my> Membership database application. My customer is willing to invest in a> commercial database, but most of the commercial databases I have briefly> looked at fall a little short in one way or another. I have several> concerns/needs that I am willing to implement and/or support:> > - Outer join support in views In the works. Perhaps for 6.5, probably not. > > - Transaction logging> > - Some form of mirroring, shadowing, or replication> > - The current locking mechanismis of some concern. I need to make> sure that one user can read a record and then a second can read and update> that same record. MVCC locking in 6.5. Will do what you need.> > - If the first user attempts to update that record, what happens? Hard to explain. Will wait or update a copy while read's use an oldercopy fo the row. -- Bruce Momjian | http://www.op.net/~candle maillist@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
> Your getting me excited about 6.5. Is there a projected release date for > 6.5? Is there any information on transaction logging? Is there anything I > can do to help? I am curious about these items because they will make my > life much easier in the upcoming months as I migrate my application to > Postgres. Working around these could be very difficulty or near impossible. We are waiting for the MVCC/locking stuff to be finished. Everything else is mostly ready. We were planning for Feb 1, but we must wait. -- Bruce Momjian | http://www.op.net/~candle maillist@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
> > Your getting me excited about 6.5. Is there a projected release date for > 6.5? Is there any information on transaction logging? Is there anything I > can do to help? I am curious about these items because they will make my > life much easier in the upcoming months as I migrate my application to > Postgres. Working around these could be very difficulty or near impossible. I've spent some time thinking about transaction log. The first idea was to log queries and in some way. But I had to drop that approach because there are functions (and users could have written threir own ones too), that don't return the same result when the database later get's rolled forward (e.g. anything handling date's/times). And OTOH an application could SELECT something from the database that maybe got created by a sequence, and uses this value then in another INSERT. But when recovering the database, it isn't guaranteed that all the data will get the same sequences again (race conditions in concurrent queries). How should the transaction log now know that this one constant value in the query must be substituted by another value to ensure referential integrity? Absolutely impossible. So the only way I see is to use some sort of image logging from inside the heap access methods. Would be much more tricky to dump and recover. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) #