"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
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 at
"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 this is
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). If we
"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 + fsync.
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 additional
