--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. T
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 thi
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
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:
> 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
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
