Re: [BUGS] BUG #5297: Add XATMI C API
On Tue, Jan 26, 2010 at 1:11 PM, Juergen Weber webe...@gmail.com wrote: An XATMI C API should be added to the PostgresQL C client, so one could run XA transactions under control of a TX monitor. An interesting usecase would be to use PostgresQL together with the LGPL open source JBoss Blacktie transaction manager (http://www.jboss.org/blacktie.html) You could submit a patch... or offer to fund a developer... ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] problem with segmentation fault error
Hello, I've got problem with PostgreSQL crash (today it was twice). Usually, average load5 is about 16-20. Today I've run new application and load has increased dramatically. First time before crash load was fast rising from 30 to 70 (log below) 2010-01-27 10:34:01 CET [3931]: [9-1] host=,user=,db= LOG: server process (PID 24454) was terminated by signal 11: Segmentation fault 2010-01-27 10:34:01 CET [3931]: [10-1] host=,user=,db= LOG: terminating any other active server processes 2010-01-27 10:34:01 CET [21906]: [1-1] host=X.X.X.X,user=pgmed,db=pgmed WARNING: terminating connection because of crash of another server process 2010-01-27 10:34:01 CET [21906]: [2-1] host=X.X.X.X,user=pgmed,db=pgmed DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. Second time, load was about 70-80 and processor utilization was almost 100% from 1 hour (log below) 2010-01-27 18:46:06 CET [3931]: [16-1] host=,user=,db= LOG: server process (PID 28357) was terminated by signal 11: Segmentation fault 2010-01-27 18:46:06 CET [3931]: [17-1] host=,user=,db= LOG: terminating any other active server processes 2010-01-27 18:46:06 CET [26377]: [3-1] host=X.X.X.X,user=pgmed_app,db=pgmed WARNING: terminating connection because of crash of another server process 2010-01-27 18:46:06 CET [26377]: [4-1] host=X.X.X.X,user=pgmed_app,db=pgmed DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. I have 8.4.0 version. Do you have any idea where problem could be? Is it hardware or rather PostgreSQL configuration problem? I'll be grateful for any help. Best regards PG -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] unable to fail over to warm standby server
Hello -- We are using PostgreSQL 8.3.8 with a Warm Standy (PITR) setup. Recently we experienced a failure on our primary database server and when we attempted to fail over to the standby server it would not come up. This configuration has been tested previously (we've successfully transferred from primary to secondary at least 3 times in the past). Our system is up and running with the Warm Standby setup reconfigured and running again. I'm reporting this issue as bug to describe the circumstances of this failed recovery in the event it does indicates a bug in this very critical feature of PostgreSQL. Both servers are identically configured as follows: - Dual QuadCore Intel Xeon-Harpertown 5430 @ 2.66GHz - Redhat EL 5.1-64 - 64GB RAM - 250GB - 2-disk RAID 0 for / partition - 1.1TB - 8 disk RAID 10 configuration for /data - 72GB - 2-disk RAID 0 for /pg_xlog It is also probably worth mentioning that Simon Riggs (copied) consulted on the configuration of our warm standby setup, thus we are fairly confident it was setup correctly. ;-) Archive configuration on primary server (prod-db-1) was: archive_mode = on archive_command = 'rsync -az --rsh=ssh %p prod-db-2.vpn:wal_archive/%f /dev/null' archive_timeout = 120 Restore configuration (in recovery.conf) on secondary server (prod-db-2) was: restore_command = 'pg_standby -t /tmp/pgsql.trigger.5432 /home/postgres/wal_archive %f %p %r 2pg_standby.log' Timeline of events: 1.) At 20:58 UTC -- received alert that primary server was not responding to pings FYI the last lines in the postgresql.log file on the primary server (before it crashed) were: 2010-01-18 20:40:56 UTC (10.16.74.194)LOG: unexpected EOF on client connection 2010-01-18 20:40:59 UTC ()LOG: checkpoint starting: time 2010-01-18 20:45:56 UTC (10.16.74.200)LOG: unexpected EOF on client connection 2010-01-18 20:50:57 UTC (10.12.58.142)LOG: unexpected EOF on client connection 2010-01-18 20:51:45 UTC ()LOG: checkpoint complete: wrote 45066 buffers (8.6%); 0 transaction log file(s) added, 0 removed, 44 recycled; write=455.622 s, sync=190.549 s, total=646.443 s - sysadmin confirmed primary was offline, and started manual process to transition to standby server, while another sysadmin worked simultaneously on trying to bring the primary server back online. 2.) Running `ps aufx` on the standby (prod-db-2) included this output postgres 16323 0.0 0.1 4578680 98180 ? S 2009 0:00 /usr/local/pgsql-8.3.8/bin/postgres -D /data/pgdata-8.3 postgres 16324 0.0 0.0 71884 716 ?Ss2009 0:09 \_ postgres: logger process postgres 16325 3.4 6.5 4581480 4284404 ? Ss2009 3902:25 \_ postgres: startup process waiting for 00023C8200D8 postgres 9164 0.0 0.0 63772 996 ?S20:56 0:00 \_ sh -c pg_standby -t /tmp/pgsql.trigger.5432 /home/postgres/wal_archive 00023C8200D postgres 9165 0.0 0.0 19168 616 ?S20:56 0:00 \_ pg_standby -t /tmp/pgsql.trigger.5432 /home/postgres/wal_archive 00023C8200D8 Notice the standby server is waiting on WAL file: 00023C8200D8 3.) Running `ls -l /home/postgres/wal_archive` showed that the most recent files transferred were -rw--- 1 postgres postgres 16777216 Jan 18 20:55 00023C8200D5 -rw--- 1 postgres postgres 16777216 Jan 18 20:55 00023C8200D6 -rw--- 1 postgres postgres 16777216 Jan 18 20:56 00023C8200D7 4.) The sysadmin ran the following command to make the secondary server exit recovery mode and come online: sudo touch /tmp/pgsql.trigger.5432 NOTE: The use of 'sudo' here is a potential cause/contributor of the failure, because the file pgsql.trigger.5432 will be owned by root, yet the postmaster process starts as user 'postgres'. However a permission issue is inconsistent with what we saw next. 5.) After a few seconds the postgres process stopped but did not come backup. The last few lines of the postgresql.log file were: 2010-01-18 20:54:28 UTC ()LOG: restored log file 00023C8200D4 from archive 2010-01-18 20:55:03 UTC ()LOG: restored log file 00023C8200D5 from archive 2010-01-18 20:55:37 UTC ()LOG: restored log file 00023C8200D6 from archive 2010-01-18 20:56:20 UTC ()LOG: restored log file 00023C8200D7 from archive 2010-01-18 21:08:31 UTC ()FATAL: could not restore file 00023C8200D8 from archive: return code 65280 2010-01-18 21:08:31 UTC ()LOG: startup process (PID 16325) exited with exit code 1 2010-01-18 21:08:31 UTC ()LOG: aborting startup due to startup process failure Looking in the /home/postgres/wal_archive directory again confirmed that it did not contain any file named 00023C8200D8 This was the most mysterious part of the puzzle as the database apparently aborted with a FATAL error when trying to restore a file that didn't exist. We've searched Google and postgresql.org to determine what return
Re: [BUGS] problem with segmentation fault error
p...@onet.eu writes: 2010-01-27 10:34:01 CET [3931]: [9-1] host=,user=,db= LOG: server process (PID 24454) was terminated by signal 11: Segmentation fault I have 8.4.0 version. The *first* thing to do is update to 8.4.2 to see if the problem was already fixed. If not, you need to try to gather some data. What query was running in the crashed backend would be useful to know, and a stack trace would be even better. Do you have any idea where problem could be? Is it hardware or rather PostgreSQL configuration problem? It could be a hardware problem or a software bug. How reproducible is it? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5298: emedded SQL in C to get the record type from plpgsql
The following bug has been logged online:
Bug reference: 5298
Logged by: George
Email address: sunduozh...@revenco.com
PostgreSQL version: 8.4.2
Operating system: Red Hat Linux AS 4
Description:emedded SQL in C to get the record type from plpgsql
Details:
CREATE OR REPLACE FUNCTION test4(IN a integer, OUT b int,OUT c int) AS
$BODY$
declare
begin
b:=100;
c:=200;
return;
END $BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100;
int test(int a)
{
EXEC SQL TYPE my_type IS STRUCT
{
int b[1];
int c[1];
};
EXEC SQL BEGIN DECLARE SECTION;
my_type ppp;
EXEC SQL END DECLARE SECTION;
EXEC SQL WHENEVER sqlerror SQLPRINT;
EXEC SQL select test4(1) into :ppp;
EXEC SQL COMMIT;
return 0;
}
So how can emedded SQL in C to get the record type which returning from
plpgsql function?
My project is migrating from Oracle to postgresql,can you help me ?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5298: emedded SQL in C to get the record type from plpgsql
George wrote: The following bug has been logged online: My project is migrating from Oracle to postgresql,can you help me ? This is a bug report form. Perhaps you were looking for the pgsql-general mailing list? -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5298: emedded SQL in C to get the record type from plpgsql
Sun Duozhong(孙多忠) wrote: Hi Craig， Thanks for your reply. Could you help me solve the problem or give me a supporter email address? http://www.postgresql.org/support/ http://archives.postgresql.org/pgsql-novice/ http://archives.postgresql.org/pgsql-general/ http://www.postgresql.org/support/professional_support -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
