Обсуждение: LINE 1: IDENTIFY_SYSTEM error infinitum
Can anyone see why I keep getting the below "IDENTIFY_SYSTEM" error in my logs when I start my replication database process? I use "postgres primary" as my prefix in the syslog and "postgres replication" as the replication one so their outputs are distinguishable. Jun 30 14:10:25 postgres primary[19617]: [2-1] LOG: connection received: host=192.168.2.8 port=55138 Jun 30 14:10:25 postgres primary[19617]: [3-1] LOG: connection authorized: user=foobar database=postgres Jun 30 14:10:25 postgres primary[19617]: [4-1] ERROR: syntax error at or near "IDENTIFY_SYSTEM" at character 1 Jun 30 14:10:25 postgres primary[19617]: [4-2] STATEMENT: IDENTIFY_SYSTEM Jun 30 14:10:25 postgres replication[19616]: [1-1] FATAL: could not receive database system identifier and timeline ID from the primary server: ERROR: syntax error at or near "IDENTIFY_SYSTEM" Jun 30 14:10:25 postgres replication[19616]: [1-2] LINE 1: IDENTIFY_SYSTEM Jun 30 14:10:25 postgres replication[19616]: [1-3] ^ Jun 30 14:10:25 postgres replication[19616]: [1-4] Jun 30 14:10:25 postgres primary[19617]: [5-1] LOG: On primary's postgresql.conf I have this: port = 5432 wal_level = archive # minimal, archive, or hot_standby archive_mode = on max_wal_senders = 1 # max number of walsender processes #hot_standby = off On the replication database's postgresql.conf I have this: port = 5433 wal_level = minimal archive_mode = off #max_wal_senders = 0 # max number of walsender processes hot_standby = off
Zoid <Zoid@the-lounge.us> writes:
> Can anyone see why I keep getting the below "IDENTIFY_SYSTEM" error in
> my logs when I start my replication database process?
Are you sure the primary is 9.0? It sure looks like you're getting a
plain backend connection instead of a walsender, which is what I'd
expect to happen if the server were too old to recognize the replication
parameter in the connection request.
regards, tom lane
Tom, Actually, I'm using postgresql beta2 and my replication process is connectiong to my primary (or backend) at 5432 via the connect_info line of the recovery.conf file. I had already saw that the error is identical if I merely connect directly to the primary and issue the command "IDENTITY_SYSTEM", so it seems to me the primary (or backend) is not treating the IDENTITY_SYSTEM command as "Streaming Replication Protocol", but I'm not sure why it would anyway as I've connected to thesame port psql does. Tom Lane wrote: > Zoid <Zoid@the-lounge.us> writes: > >> Can anyone see why I keep getting the below "IDENTIFY_SYSTEM" error in >> my logs when I start my replication database process? >> > > Are you sure the primary is 9.0? It sure looks like you're getting a > plain backend connection instead of a walsender, which is what I'd > expect to happen if the server were too old to recognize the replication > parameter in the connection request. > > regards, tom lane > >
Zoid <Zoid@the-lounge.us> writes:
> Actually, I'm using postgresql beta2 and my replication process is
> connectiong to my primary (or backend) at 5432 via the connect_info line
> of the recovery.conf file.
> I had already saw that the error is identical if I merely connect
> directly to the primary and issue the command "IDENTITY_SYSTEM", so it
> seems to me the primary (or backend) is not treating the IDENTITY_SYSTEM
> command as "Streaming Replication Protocol", but I'm not sure why it
> would anyway as I've connected to thesame port psql does.
The port's not the issue --- replication connections are supposed to use
the same port. Try something like
psql -h primary-server replication=1
regards, tom lane
Hmm. I tried the replication=1 switch but I was prompted with the below
but I noticed the "local" requirement assumes a UNIX socket which i'm
not using. And both databases are actually on the same box (just
different ports).
psql: FATAL: no pg_hba.conf entry for replication connection from
host "[local]", user "postgres"
I've been using this to start the replication database processs, which
does start ok, spit out to syslog then barfs on the IDENTIFY_SYSTEM
returned from the primary.
/usr/local/pgsql/bin/postgres -p5433 -D replication_database -o -d5
Can I be sure that the Primary even has the capability to answer the
IDENTIFY_SYSTEM command? I'm beginning to think maybe this is zero'd
out until the beta is finalized. It would take a code search but if
the functionality is linked to Major Version and Minor version
variables, I guess its possible that it won't work until the beta2 is
normalized to an normal release. So I'll look for an alternate means
to extract the System Identity on the primary.
Tom Lane wrote:
> Zoid <Zoid@the-lounge.us> writes:
>
>> Actually, I'm using postgresql beta2 and my replication process is
>> connectiong to my primary (or backend) at 5432 via the connect_info line
>> of the recovery.conf file.
>>
>
>
>> I had already saw that the error is identical if I merely connect
>> directly to the primary and issue the command "IDENTITY_SYSTEM", so it
>> seems to me the primary (or backend) is not treating the IDENTITY_SYSTEM
>> command as "Streaming Replication Protocol", but I'm not sure why it
>> would anyway as I've connected to thesame port psql does.
>>
>
> The port's not the issue --- replication connections are supposed to use
> the same port. Try something like
>
> psql -h primary-server replication=1
>
> regards, tom lane
>
On Thu, Jul 1, 2010 at 11:35 AM, Zoid <Zoid@the-lounge.us> wrote:
> Hmm. I tried the replication=1 switch but I was prompted with the below but
> I noticed the "local" requirement assumes a UNIX socket which i'm not using.
> And both databases are actually on the same box (just different ports).
>
> psql: FATAL: no pg_hba.conf entry for replication connection from host
> "[local]", user "postgres"
>
>
> I've been using this to start the replication database processs, which does
> start ok, spit out to syslog then barfs on the IDENTIFY_SYSTEM returned from
> the primary. /usr/local/pgsql/bin/postgres -p5433 -D
> replication_database -o -d5
>
> Can I be sure that the Primary even has the capability to answer the
> IDENTIFY_SYSTEM command? I'm beginning to think maybe this is zero'd out
> until the beta is finalized. It would take a code search but if the
> functionality is linked to Major Version and Minor version variables, I
> guess its possible that it won't work until the beta2 is normalized to an
> normal release. So I'll look for an alternate means to extract the System
> Identity on the primary.
Hmm... you'd like to get the system identifier from the postgres server via SQL
rather than starting replication? If so, you can do that by adding replication
entry into pg_hba.conf and performing the following
$ psql replication=1 -c "IDENTIFY_SYSTEM"
systemid | timeline
---------------------+----------
5488763631978937207 | 1
(1 row)
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Fujii Masao <masao.fujii@gmail.com> writes:
> Hmm... you'd like to get the system identifier from the postgres
> server via SQL rather than starting replication? If so, you can do
> that by adding replication entry into pg_hba.conf and performing the
> following
> $ psql replication=1 -c "IDENTIFY_SYSTEM"
Cute, but all Zoid wants is to get his replication slave to start ;-)
Can you figure out what's going wrong? I'm wondering about some sort of
incompatibility between various pre-beta states of the code, but don't
have a clear answer.
regards, tom lane
On Thu, Jul 1, 2010 at 1:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Fujii Masao <masao.fujii@gmail.com> writes: >> Hmm... you'd like to get the system identifier from the postgres >> server via SQL rather than starting replication? If so, you can do >> that by adding replication entry into pg_hba.conf and performing the >> following > >> $ psql replication=1 -c "IDENTIFY_SYSTEM" > > Cute, but all Zoid wants is to get his replication slave to start ;-) > Can you figure out what's going wrong? I'm wondering about some sort of > incompatibility between various pre-beta states of the code, but don't > have a clear answer. I'm suspicious of that incompatibility, too. So reinstalling the postgres 9.0beta2 would fix the problem, I guess. Though I'm not convinced.. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center