RE: [HACKERS] Proposal for DROP TABLE rollback mechanism

2000-11-08 Thread Mikheev, Vadim
> Rollback of DROP TABLE now works in non-WAL code, and seems to work in > WAL code too. I did not add WAL logging, because I'm not quite sure > what to do, so rollforward probably does the wrong thing. Could you > deal with that part? smgr.c is the place that keeps the list of what > to delete

Re: [HACKERS] Proposal for DROP TABLE rollback mechanism

2000-11-08 Thread Tom Lane
"Vadim Mikheev" <[EMAIL PROTECTED]> writes: > Please note that there is xlog_bufmgr.c If you'll add/change something in > bufmgr please let me know later. Per your request: I've changed bufmgr.c. I think I made appropriate changes in xlog_bufmgr, but please check. The changes were: 1. Modify F

Re: [HACKERS] Proposal for DROP TABLE rollback mechanism

2000-10-28 Thread Vadim Mikheev
> > BTW, why do we force buffers to disk in FlushRelationBuffers at all? > > Seems all what is required is to flush them *from* pool, not *to* disk > > immediately. > > Good point. Seems like it'd be sufficient to do a standard async write > rather than write + fsync. > > We'd still need some add

Re: [HACKERS] Proposal for DROP TABLE rollback mechanism

2000-10-28 Thread Tom Lane
"Vadim Mikheev" <[EMAIL PROTECTED]> writes: > BTW, why do we force buffers to disk in FlushRelationBuffers at all? > Seems all what is required is to flush them *from* pool, not *to* disk > immediately. Good point. Seems like it'd be sufficient to do a standard async write rather than write + fs

Re: [HACKERS] Proposal for DROP TABLE rollback mechanism

2000-10-28 Thread Vadim Mikheev
> > Mmmm, why not call FlushRelationBuffers? Calling bufmgr from smgr > > doesn't look like right thing. ? > > Yes, it's a little bit ugly, but if we call FlushRelationBuffers then we > will likely be doing some useless writes (to flush out pages that we are > only going to throw away anyway). I

Re: [HACKERS] Proposal for DROP TABLE rollback mechanism

2000-10-28 Thread Tom Lane
"Vadim Mikheev" <[EMAIL PROTECTED]> writes: >> 2. smgrunlink() normally will NOT immediately delete the file; instead it >> will perform smgrclose() and then add the rel's RelFileNode information to > ^^^ > Seems that smgrclose still need in Relation (where rd_fd lives and thi

Re: [HACKERS] Proposal for DROP TABLE rollback mechanism

2000-10-28 Thread Vadim Mikheev
> 1. smgrcreate() will create the file for the relation same as it does now, > and will add the rel's RelFileNode information to an smgr-private list of > rels created in the current transaction. > > 2. smgrunlink() normally will NOT immediately delete the file; instead it > will perform smgrclose