On Fri, Jun 3, 2016 at 10:25 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote: >>> + char new_vmbuf[BLCKSZ]; >>> + char *new_cur = new_vmbuf; >>> + bool empty = true; >>> + bool old_lastpart; >>> + >>> + /* Copy page header in advance */ >>> + memcpy(new_vmbuf, &pageheader, >>> SizeOfPageHeaderData); >>> >>> Shouldn't we zero out new_vmbuf? Afaics we're not necessarily zeroing it >>> with old_lastpart && !empty, right? >> >> Oh, dear. That seems like a possible data corruption bug. Maybe we'd >> better fix that right away (although I don't actually have time before >> the wrap).
Actually, on second thought, I'm not seeing the bug here. It seems to me that the loop commented this way: /* Process old page bytes one by one, and turn it into new page. */ ...should always write to every byte in new_vmbuf, because we process exactly half the bytes in the old block at a time, and so that's going to generate exactly one full page of new bytes. Am I missing something? > Since the force is always set true, I removed the force from argument > of copyFile() and rewriteVisibilityMap(). > And destination file is always opened with O_RDWR, O_CREAT, O_TRUNC flags . I'm not happy with this. I think we should always open with O_EXCL, because the new file is not expected to exist and if it does, something's probably broken. I think we should default to the safe behavior (which is failing) rather than the unsafe behavior (which is clobbering data). (Status update for Noah: I expect Masahiko Sawada will respond quickly, but if not I'll give some kind of update by Monday COB anyhow.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers