I started thinking more about this --- we already allow multiple
processes to write to a single file when running Postgres as a backend
on Windows. I think it is these open() flags that make it possible:
(FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE),
However, we are n
I have fixed the bug below with the attached patches for 9.0, 9.1, and
9.2. I did a minimal patch for 9.0 and 9.1, and a more thorough patch
for 9.2.
The use of -l/log was tested originally in pg_migrator (for 8.4) and
reported to be working, but it turns out it only worked in 'check' mode,
and
On 07/19/2011 01:25 PM, Bruce Momjian wrote:
Andrew Dunstan wrote:
I can't figure out of there is something odd about this user's setup or
if there is a bug in pg_upgrade with -l on Windows.
The Windows file system seems to have some asynchronicity regarding what
files are locked. For that
Andrew Dunstan wrote:
> > I can't figure out of there is something odd about this user's setup or
> > if there is a bug in pg_upgrade with -l on Windows.
> >
>
>
> The Windows file system seems to have some asynchronicity regarding what
> files are locked. For that reason, the buildfarm code has
On Mon, July 18, 2011 11:28 pm, Bruce Momjian wrote:
> Has anyone successfully used pg_upgrade 9.0 with -l (log) on Windows?
>
> I received a private email bug report that pg_upgrade 9.0 does not work
> with the -l/log option on Windows. The error is:
>
> Analyzing all rows in the new cluste
Has anyone successfully used pg_upgrade 9.0 with -l (log) on Windows?
I received a private email bug report that pg_upgrade 9.0 does not work
with the -l/log option on Windows. The error is:
Analyzing all rows in the new cluster
""c:/MinGW/msys/1.0/home/edb/inst/bin/vacuumdb" --p
