Thread: pgsql in a virtual environment

I am running a postgresql application under Mandriva 2011 x86_64, and
want to explore the problems in porting it to a Mageia 4 x86_64
environment before actually upgrading. I have installed Mageia 4 as a
virtual machine under VBox, installed postgresql 9.3 and sorted out a
shared folder to get to the existing database from which the application
needs to read data. However I cannot start the virtual postgresql with
the existing data directory:
$ ./pg_ctl start -D /mnt/post/pgsql/data &
[1] 3692
[postgres@localhost bin]$ pg_ctl: could not open PID file
"/mnt/post/pgsql/data/postmaster.pid": Protocol error

[1]+  Exit 1                  ./pg_ctl start -D /mnt/post/pgsql/data
Is there any advice on running postgresql in a virtual machine
connecting to host data?
Thanks
Graeme

2014-05-16 11:56 GMT-03:00 Graeme Gemmill <graeme@gemmill.name>:
> $ ./pg_ctl start -D /mnt/post/pgsql/data &
> [1] 3692
> [postgres@localhost bin]$ pg_ctl: could not open PID file
> "/mnt/post/pgsql/data/postmaster.pid": Protocol error
>
> [1]+  Exit 1                  ./pg_ctl start -D /mnt/post/pgsql/data
> Is there any advice on running postgresql in a virtual machine connecting to
> host data?

Did you check your logs to see if there was any information which
would point to the problem?

Looks like a libpq - backend server mismatch.

--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

=?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= <martin@2ndquadrant.com> writes:
> 2014-05-16 11:56 GMT-03:00 Graeme Gemmill <graeme@gemmill.name>:
>> $ ./pg_ctl start -D /mnt/post/pgsql/data &
>> [1] 3692
>> [postgres@localhost bin]$ pg_ctl: could not open PID file
>> "/mnt/post/pgsql/data/postmaster.pid": Protocol error

> Looks like a libpq - backend server mismatch.

No --- pg_ctl is trying to read the postmaster's PID file, and it's
getting some bizarre error from fopen().  I have no idea exactly what
"Protocol error" might mean in this context.  It would make some sense
if the data directory were on NFS or other network-based file system,
but otherwise it's kind of weird.

Anyway this is a filesystem problem.  libpq is not involved.  I would
venture that it's either a kernel bug or some misconfiguration of the
virtual environment.  The fix is below Postgres' level, for sure.

            regards, tom lane