|
Home > Archive > PostgreSQL Discussion > May 2005 > unsupported frontend protocol
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
unsupported frontend protocol
|
|
| Bucks vs Bytes Inc 2005-05-25, 8:24 pm |
| I've painted myself into a little corner here:
I pg_dumped a 7.4.3 database, created a database of the same name on a
7.3.4 server, psql'd into the new database, and \i'd the dump file.
The database was created although there were a variety of errors which I
realized were due to 7.4.3 and 7.3.4 SQL incompatibilities. I had also
added a new entry to pg_hba.conf. After restarting the 7.3.4 postmaster
I started getting an endless series of "FATAL: unsupported frontend
protocol" messages, even when not using psql. The only other access to
the cluster is by PHP 4.2.2, and nothing accesses the newly restored
database.
Since the db had errors anyway, I restored the old pg_hba.conf file,
dropped the new database, and restarted the postmaster -- i.e.
attempting to wipe out all changes. HOWEVER, the protocol error message
persists, endlessly and infuriatingly! Searching on the error message
text doesn't return anything enlightening.
Can anyone suggest why this is happening or where I find a log with
further details. Thank you in advance
John Gunther
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
| |
| Tom Lane 2005-05-25, 8:24 pm |
| Bucks vs Bytes Inc < postgresql@bucksvsby
tes.com> writes:
> The database was created although there were a variety of errors which I
> realized were due to 7.4.3 and 7.3.4 SQL incompatibilities. I had also
> added a new entry to pg_hba.conf. After restarting the 7.3.4 postmaster
> I started getting an endless series of "FATAL: unsupported frontend
> protocol" messages, even when not using psql.
Not surprising if you are using 7.4 or later client libraries. Those
will try to connect using the PG V3 protocol (added in 7.4). libpq, at
least, will fall back to the older protocol if V3 doesn't work, but
I am not sure whether PHP uses libpq.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Bucks vs Bytes Inc 2005-05-25, 8:24 pm |
| Agreed that the symptom fits a client library mismatch, but the only
thing I moved from the 7.4.3 system to the 7.3.4 system was a pg_dump'ed
database. That can't carry anything that would affect the interaction
between the existing PHP 4.2.2 and PostgreSQL 7.3.4 versions, can it?
They worked without error for many months prior to that database load.
Is there any postmaster logging I can turn on that will detail what's
triggering the error?
John
Tom Lane wrote:
>Not surprising if you are using 7.4 or later client libraries. Those
>will try to connect using the PG V3 protocol (added in 7.4). libpq, at
>least, will fall back to the older protocol if V3 doesn't work, but
>I am not sure whether PHP uses libpq.
>
> regards, tom lane
>
>
>
>
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
| |
| Tom Lane 2005-05-25, 8:24 pm |
| Bucks vs Bytes Inc < postgresql@bucksvsby
tes.com> writes:
> Is there any postmaster logging I can turn on that will detail what's
> triggering the error?
Well, you could change the error report in postmaster.c to show the
specific protocol version code it's receiving (7.4 and up do this,
but it hadn't occurred to us as of 7.3). I have little doubt what
you will find though. Maybe what you really want is to enable
log_connections so you can find out where the problematic connections
are coming from.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
| |
| Tom Lane 2005-05-26, 11:23 am |
| Bucks vs Bytes Inc < postgresql@bucksvsby
tes.com> writes:
> Any thoughts on what could make both clients attempt wrong protocol?
They are both using 7.4-or-later libpq. Whether you think so or not.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
|
|
|
|
|