[ADMIN] Reg: unexpected EOF on client connection
Dear Friends, I am new to Postgres Administration. I am getting this below mentioned error in my pg_log and server looks in hanged state whenever this error is getting logged. OS - Suse Linux Enterprise Edition 11, DB - Postgres 8.3, Application Server - Jboss. 2011-11-22 16:57:55 IST LOG: unexpected EOF on client connection 2011-11-22 16:57:55 IST LOG: unexpected EOF on client connection 2011-11-22 16:58:58 IST LOG: unexpected EOF on client connection 2011-11-22 16:58:58 IST LOG: unexpected EOF on client connection 2011-11-22 16:58:58 IST LOG: unexpected EOF on client connection 2011-11-22 16:58:58 IST LOG: unexpected EOF on client connection 2011-11-22 16:58:58 IST LOG: unexpected EOF on client connection 2011-11-22 16:58:58 IST LOG: unexpected EOF on client connection 2011-11-22 16:58:58 IST LOG: unexpected EOF on client connection 2011-11-22 16:58:58 IST LOG: unexpected EOF on client connection 2011-11-22 16:58:58 IST LOG: unexpected EOF on client connection 2011-11-22 16:58:58 IST LOG: unexpected EOF on client connection 2011-11-22 16:58:58 IST LOG: unexpected EOF on client connection Kindly suggest me about how to overcome this. Suggestion are welcome whole heartedly. Thanks in advance. -- Regards, Hariraman Jayaraj Mobile - 9786228845
Re: [ADMIN] Reg: unexpected EOF on client connection
> I am new to Postgres Administration. I am getting this below mentioned error > in my pg_log and server looks in hanged state whenever this error is getting > logged. > OS - Suse Linux Enterprise Edition 11, DB - Postgres 8.3, Application Server > - Jboss. > > 2011-11-22 16:57:55 IST LOG: unexpected EOF on client connection > 2011-11-22 16:57:55 IST LOG: unexpected EOF on client connection These generally mean that the client has gone away without closing database connections. You should check your client code. It is highly unlikely these errors would cause your server to hang. -- Ian. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Reg: unexpected EOF on client connection
Dear All, Since you have postgres database server. You may need to check at client desktop PCs which is connected to Postgres database. Especially the physical ethernet connection from clients Desktop PCs to ethernet connection. (if its works within company local area network) You have option: 1) ping remote client Desktop PCs (which is, you suspect the Desktop PCs down). 2) check physical ethernet connection of the Desktop PC. 3) ping localhost to check if the network interface connection is working. Regards, MOHAMMAD ADLI BIN MT TAJUDIN A8-2-7, DESA PANDAN APARTMENTS, OFF JALAN KG. PANDAN, 55100 KUALA LUMPUR, WEST MALAYSIA. H/p number: (017) 362 3661 Email: white.he...@yahoo.com From: Ian Lea To: Hariraman Jayaraj Cc: pgsql-admin@postgresql.org Sent: Wednesday, November 23, 2011 5:42 PM Subject: Re: [ADMIN] Reg: unexpected EOF on client connection > I am new to Postgres Administration. I am getting this below mentioned error > in my pg_log and server looks in hanged state whenever this error is getting > logged. > OS - Suse Linux Enterprise Edition 11, DB - Postgres 8.3, Application Server > - Jboss. > > 2011-11-22 16:57:55 IST LOG: unexpected EOF on client connection > 2011-11-22 16:57:55 IST LOG: unexpected EOF on client connection These generally mean that the client has gone away without closing database connections. You should check your client code. It is highly unlikely these errors would cause your server to hang. -- Ian. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] Point in time recovery
Hello, Can any one please explain me how to use PITR? Regards, karuna karpe.
Re: [ADMIN] Point in time recovery
On Wed, Nov 23, 2011 at 12:39 PM, Karuna Karpe wrote: > Can any one please explain me how to use PITR? Yes, the docs contain a great explanation. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Point in time recovery
> Can any one please explain me how to use PITR? http://lmgtfy.com/?q=postgres+pitr -- Ian. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] Repeatable crash in pg_dump (with -d2 info)
I'm seeing pg_dump [8.3.15 Windows] crash reproducibly against a particular
database. Searching the web, I found [
http://grokbase.com/t/postgresql.org/pgsql-general/2001/02/pg-dump-crash/06ss55h5l35jh4bnnqfigxisy534]
with
a response from Tom Lane suggesting that it was probably due to a bug in
pg_dump related to dumping functions.
That post was made more than 10 years ago, but I figured it was worth a
try, and set my pg_dump to run with PGOPTIONS="-d2". Sure enough, the
crash is preceded by the following lines:
SELECT proretset, prosrc, probin, proallargtypes, proargmodes, proargnames,
provolatile, proisstrict, prosecdef, proconfig, procost, prorows, (SELECT
lanname FROM pg_catalog.pg_language WHERE oid = prolang) as lanname FROM
pg_catalog.pg_proc WHERE oid = '16730'::pg_catalog.oid
SELECT pg_catalog.format_type('1185'::pg_catalog.oid, NULL)
SELECT pg_catalog.format_type('1022'::pg_catalog.oid, NULL)
SELECT pg_catalog.format_type('1184'::pg_catalog.oid, NULL)
SELECT pg_catalog.format_type('701'::pg_catalog.oid, NULL)
SELECT pg_catalog.format_type('1185'::pg_catalog.oid, NULL)
SELECT pg_catalog.format_type('1022'::pg_catalog.oid, NULL)
SELECT pg_catalog.format_type('2249'::pg_catalog.oid, NULL)
The OIDs 1185, 1022, 1184 and 701 are present in proallargtypes, so pg_dump
appears to be looking up argument types for that function. I couldn't see
2249 anywhere, though, so I ran this:
SELECT * FROM pg_catalog.pg_proc WHERE oid = '16730'
And 2249 showed up in prorettype. The result from that last query is
'record', since the function RETURNS SETOF RECORD.
That original post turned out to be some temporary trigger function that
the user simply deleted to solve the problem. This function, however, is
legitimate, and I can't simply delete it. Does anyone know what might be
happening here, and how to work around it? Thanks!
Re: [ADMIN] Repeatable crash in pg_dump (with -d2 info)
David Schnur writes: > I'm seeing pg_dump [8.3.15 Windows] crash reproducibly against a particular > database. Can you provide a stack trace from the crash? There's some info about that here: http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows though I think it's oriented towards backend crashes more than client-side crashes. Alternatively, do you have the SQL definition for the function you think is causing the crash? There's not much that anybody else is going to be able to do about this unless you can provide a reproducible test case. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Repeatable crash in pg_dump (with -d2 info)
Sure; the function is created programmatically as part of schema creation, by the same user who owns (almost) everything else in the database. The definition looks like this: CREATE OR REPLACE FUNCTION datastore_unpack( data_times TIMESTAMP WITH TIME ZONE[], data_values DOUBLE PRECISION[], OUT data_time TIMESTAMP WITH TIME ZONE, OUT data_value DOUBLE PRECISION ) RETURNS SETOF RECORD AS $$ SELECT $1[rowx] AS data_time, $2[rowx] AS data_value FROM generate_series(1, array_upper($1, 1)) AS rowx; $$ LANGUAGE SQL STABLE; It takes two parallel arrays and unpacks them into a set of records.
Re: [ADMIN] Repeatable crash in pg_dump (with -d2 info)
David Schnur writes: > Sure; the function is created programmatically as part of schema creation, > by the same user who owns (almost) everything else in the database. The > definition looks like this: > CREATE OR REPLACE FUNCTION datastore_unpack( > data_times TIMESTAMP WITH TIME ZONE[], > data_values DOUBLE PRECISION[], > OUT data_time TIMESTAMP WITH TIME ZONE, > OUT data_value DOUBLE PRECISION > ) RETURNS SETOF RECORD AS $$ > SELECT $1[rowx] AS data_time, $2[rowx] AS data_value > FROM generate_series(1, array_upper($1, 1)) AS rowx; > $$ LANGUAGE SQL STABLE; No crash observed here. So either we fixed it since 8.3.15 (doesn't seem likely, as I see nothing potentially related in the commit logs), or the trigger for the problem is not (just) this function. It seems entirely plausible that the crash is associated with the next-to-be-dumped object rather than this one, anyway. How about that stack trace? Alternatively, if you have an idea of the next object it might be working on (most likely, the next function in alphabetical order) you might see if loading just that function into an empty database is enough to create a crash. It's also entirely plausible that the crash requires multiple objects to trigger it (for instance it might have something to do with inter-object dependencies). So if you're not eager to burrow into stack traces, you might see if you can strip your standard schema down to something you could post that still triggers the crash starting from an empty database. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Point in time recovery
On 11/23/2011 08:39 PM, Karuna Karpe wrote: Hello, Can any one please explain me how to use PITR? Are you struggling with one particular issue with PITR setup where the documentation isn't helping? If so, please explain in more detail, making sure to include all the appropriate information about your setup. See: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems If this is a more general question about how to use PITR and you haven't tried it yet, start with the manual here: http://www.postgresql.org/docs/current/static/continuous-archiving.html http://www.postgresql.org/docs/current/static/warm-standby.html -- Craig Ringer
