--On Sonntag, November 09, 2008 18:25:50 -0600 Decibel!
[EMAIL PROTECTED] wrote:
On Nov 7, 2008, at 9:53 AM, Tom Lane wrote:
FWIW, I don't see this patch as being terribly useful in the real world
until it can take place in the background, without locking stuff for a
huge amount of time.
On Nov 7, 2008, at 9:53 AM, Tom Lane wrote:
So I'm looking at the patch for ALTER DATABASE SET TABLESPACE, and
wondering about what happens if there's a system crash midway through.
The answer doesn't look too good: if the deletion pass has started,
your database is hosed.
FWIW, I don't see
So I'm looking at the patch for ALTER DATABASE SET TABLESPACE, and
wondering about what happens if there's a system crash midway through.
The answer doesn't look too good: if the deletion pass has started,
your database is hosed.
I think we can fix this along the following lines:
1. Copy
Tom Lane wrote:
That is, that's true as long as the filesystem copy in fact pushed
everything to disk. copydir() does an fsync() on each file it copies,
so I think we have done as much as we can to protect the data being
copied, but I wonder if anyone feels it's too dangerous?
Do we need to
Alvaro Herrera [EMAIL PROTECTED] writes:
Do we need to fsync the directory itself? My fsync(2) manpage says
Calling fsync() does not necessarily ensure that the entry in the
directory
containing the file has also reached disk. For that an explicit
fsync() on a
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Do we need to fsync the directory itself? My fsync(2) manpage says
Calling fsync() does not necessarily ensure that the entry in
the directory
containing the file has also reached disk. For that an explicit
