From: Tom Lane on
Fujii Masao <masao.fujii(a)gmail.com> writes:
> + Free(xldir);

> s/Free/FreeDir ?

Yeah, that too. I think it's all good now, but please test.

One thing I was wondering was whether the stat-wrong-file problem
could explain the buildfarm failures that we thought were evidence
of a portability issue. I was tempted to re-enable the #ifdef NOTYET
code, but didn't want to pull that trigger while there were other
problems outstanding.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Andres Freund on
On Monday 22 February 2010 04:58:29 Tom Lane wrote:
> Fujii Masao <masao.fujii(a)gmail.com> writes:
> > + Free(xldir);
> >
> > s/Free/FreeDir ?
>
> Yeah, that too. I think it's all good now, but please test.
At least I havent seen any of the problems pointed out in "fsync fun".

> One thing I was wondering was whether the stat-wrong-file problem
> could explain the buildfarm failures that we thought were evidence
> of a portability issue. I was tempted to re-enable the #ifdef NOTYET
> code, but didn't want to pull that trigger while there were other
> problems outstanding.
I unfortunately dont think so. The mkdir above should not have been bothered
by the stat issue - especially as it was only introduced by the commit to
disable the fsyncing.

> I also think it should scan the todir not the fromdir, just on
> general principles to avoid any possibility of race conditions.
That one actually was my idea/code and intentional with the idea to error out
at one more place if anything goes wrong in the copy loop - I could not think
of any race issues created by that which were not there before.
On the other hand its unlikely to catch anything so I dont mind.

Andres

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers