Re: [BUGS] BUG #5800: "corrupted" error messages (encoding problem ?)
On Tue, Mar 22, 2011 at 7:07 AM, genamiga wrote: > I tried with 9.0.3...same problem... This should be resolved in 9.0.4 btw. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5800: "corrupted" error messages (encoding problem ?)
Just tested the 9.0.4...same problem I am affraid... -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-5800-corrupted-error-messages-encoding-problem-tp3313951p4340437.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- 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 #5800: "corrupted" error messages (encoding problem ?)
On Tue, Apr 26, 2011 at 10:07 AM, Carlo Curatolo wrote: > Just tested the 9.0.4...same problem I am affraid... Uh, that's odd. I've asked someone to see if we can reproduce it again. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5297: Add XATMI C API
We would certainly be very interested in testing XA support. Our project is called BlackTie - it's an XATMI implementation. We use the JBossTS transaction manager for the transaction engine - although JBossTS is written in Java, providing XA support was reasonably easy since it conforms to the OTS specification which means we can control transactions from a C based XA environment. There is an example of using different resource managers within transactions: https://svn.jboss.org/repos/blacktie/trunk/atmibroker-xatmi/src/example/txfooapp The files ora.c and db2.c show user code accessing resources from two different vendors - the XA specific information is defined in btconfig.xml (basically it just exposes the XA open string, the symbol name of the xa switch structure and the name of the library that exports the switch symbol). On 21.04.2011 20:04, Michael Musgrove wrote: I am referring to the X/Open specification Distributed Transaction Processing: The XA Specification (pubs.opengroup.org/onlinepubs/009680699/toc.pdf). If postgresql provides a conforming Resource Manager switch then we can include postgresql work along with interactions with other Resource Managers (Oracle, DB2) in the same transaction. For example the equivalent support in Oracle that I am asking for is documented at http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96590/adga1_xa.htm When I wrote the patch for the backend support, I was not able to find any open source implementations of X/Open XA-compatible resource managers or transaction managers, which makes it kind of hard to implement the API correctly. There was plenty of JDBC XA implementations, however, so I used that for testing. If you can find something to test it with, it probably wouldn't be that hard to write the library. -- 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 #5297: Add XATMI C API
Sorry, the link I included was for committers. Try this instead https://anonsvn.jboss.org/repos/blacktie/trunk/atmibroker-xatmi/src/example/txfooapp/ and the project page is http://www.jboss.org/blacktie We would certainly be very interested in testing XA support. Our project is called BlackTie - it's an XATMI implementation. We use the JBossTS transaction manager for the transaction engine - although JBossTS is written in Java, providing XA support was reasonably easy since it conforms to the OTS specification which means we can control transactions from a C based XA environment. There is an example of using different resource managers within transactions: https://svn.jboss.org/repos/blacktie/trunk/atmibroker-xatmi/src/example/txfooapp The files ora.c and db2.c show user code accessing resources from two different vendors - the XA specific information is defined in btconfig.xml (basically it just exposes the XA open string, the symbol name of the xa switch structure and the name of the library that exports the switch symbol). On 21.04.2011 20:04, Michael Musgrove wrote: I am referring to the X/Open specification Distributed Transaction Processing: The XA Specification (pubs.opengroup.org/onlinepubs/009680699/toc.pdf). If postgresql provides a conforming Resource Manager switch then we can include postgresql work along with interactions with other Resource Managers (Oracle, DB2) in the same transaction. For example the equivalent support in Oracle that I am asking for is documented at http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96590/adga1_xa.htm When I wrote the patch for the backend support, I was not able to find any open source implementations of X/Open XA-compatible resource managers or transaction managers, which makes it kind of hard to implement the API correctly. There was plenty of JDBC XA implementations, however, so I used that for testing. If you can find something to test it with, it probably wouldn't be that hard to write the library. -- 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] Setting timezone: is it bug or intended?
Yura Sokolov wrote: > 21.03.2011 15:51, Susanne Ebrecht ?: > > Hello Yora Sokolov, > > > > Maybe this is not a bug - just an inconsistence: > > > > Look here (tested with 9.0): > > > > =# set timezone='+3.5'; > > SET > > =# select current_timestamp; > >now > > -- > > 2011-03-21 16:05:34.761112+03:30 > > (1 row) > > > > In any case, this should get documented. > > > > Susanne > > > > > My question were about sign of timezone: > > postgres=# set timezone='+03'; -- positive > postgres=# select now(); > 2011-03-18 11:20:29.696671+03 -- positive > postgres=# set timezone='+03:00'; -- positive > 2011-03-18 05:20:35.46008-03 -- negative > > Is it intended? Uh, it certainly looks very odd. What I believe is happening is that +03:00 is processed as a real time zone specification: test=> set timezone='+03:00'; SET test=> show timezone; TimeZone -- --> +03:00 (1 row) test=> select now(); now --- 2011-04-26 15:41:11.409237-03 (1 row) You will notice that because of the SQL standard, GMT+3 processes as -03 utc_offset, and '+03:00' must be processed the same: test=> select * from pg_timezone_names; name | abbrev | utc_offset | is_dst --+++ ... Etc/GMT+3| GMT+3 | -03:00:00 | f The '+03' is seen as hours-minutes-seconds: test=> set timezone='+03'; SET test=> show timezone; TimeZone -- --> 03:00:00 (1 row) test=> select now(); now --- 2011-04-26 21:40:57.570654+03 (1 row) hence the +03. Notice how different that looks from the +03:00 above. As far as how to even document this, I have no idea. I think this code is being processed by the timezone library we include as part of Postgres. I am lost on how to proceed. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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 #5994: Can't excute DBI->connect to oracle by client site
The following bug has been logged online:
Bug reference: 5994
Logged by: Li Hongbing
Email address: lihongb...@intasect.com.cn
PostgreSQL version: PostgreSQL 8.4.
Operating system: x86_64_unknonwn_linux_gnu
Description:Can't excute DBI->connect to oracle by client site
Details:
I am trying to create a 64-bit postgresql 8.4 database server which can
retrieve data from Oracle(10gR2) at an other server by DBI-LINK.
DBI-LINK works good on postgresql server site when I connect to linux by
telnet.When I connect to postgresql server by postgresql client just like
pgAdmin or EMS SQL Manager,I got a error like this:
error from Perl function "set_up_connection": DBI
connect('host=192.168.138.173;sid=smmacs;port=1521','rmtrsys',...) failed:
ORA-24327: need explicit attach before authenticating a user (DBD ERROR:
OCISessionBegin) at line 43 at line 35.
so I write test code to confirm DBI connect function
CREATE OR REPLACE FUNCTION dbi_link.test2()
RETURNS char AS
$BODY$
use DBI;
use DBD::Oracle;
my $dbname = 'xxx';
my $user = 'rmtrsys';
my $passwd = 'rmtrsys';
my $dbh =
DBI->connect("dbi:Oracle:host=192.168.138.173;sid=smmacs;port=1521", $user,
$passwd,{ora_charset => 'UTF8'}) or
die "Database connection not made: $DBI::errstr";
$dbh -> disconnect;
return "OK";
$BODY$
LANGUAGE 'plperlu' VOLATILE
COST 100;
When I connect to linux by telnet and excute psql -d dbi_link_test to run,it
works good
dbi_link_test=# select dbi_link.test2();
test2
---
OK
(1 row)
But when I connect by postgresql client (pgAdmin or EMS SQL Manager) to run
same sql, it returned an error:
NOTICE: DBI
connect('host=192.168.138.173;sid=smmacs;port=1521','rmtrsys',...) failed:
ORA-24327: need explicit attach before authenticating a user (DBD ERROR:
OCISessionBegin) at line 10
ERROR: error from Perl function "test2": Database connection not made:
ORA-24327: need explicit attach before authenticating a user (DBD ERROR:
OCISessionBegin) at line 10.
** エラー **
ERROR: error from Perl function "test2": Database connection not made:
ORA-24327: need explicit attach before authenticating a user (DBD ERROR:
OCISessionBegin) at line 10.
SQLステート:XX000
when got this error,I can't shutdown the server normally,ths shutdown
command will not terminate unless I cancel it.
[postgres@localhost ~]$ pg_ctl stop -D /usr/local/pgsql/data
waiting for server to shut down...LOG: received smart shutdown request
.LOG: autovacuum launcher shutting down
..
Above test let me know the DBI-LINK crushed by DBI->connect, I think the
really reason is one of these:
1.postgresql create backend process has a bug,most likely with bad process
environment var
2.Orace OCI functions has a bug
3.DBD:Oracle has a bug
However,I should report this as a postgresql bug ,becourse of run same sql
must get same result anywhere(server or client).
Versions:
Oracle-10.2.0.1.0
DBI-1.616
DBD-Oracle-1.28
YAML-0.72
perl, v5.8.8 built for x86_64-linux-thread-multi
Regards,
Li Hongbing,China
--
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] Setting timezone: is it bug or intended?
Bruce Momjian writes: > As far as how to even document this, I have no idea. It already is documented. See http://developer.postgresql.org/pgdocs/postgres/datatype-datetime.html#DATATYPE-TIMEZONES specifically the point that POSIX zone names have the opposite sign convention from ISO-8601. The great thing about standards is there are so many to choose from ;-) 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
Re: [BUGS] Setting timezone: is it bug or intended?
Tom Lane wrote: > Bruce Momjian writes: > > As far as how to even document this, I have no idea. > > It already is documented. See > http://developer.postgresql.org/pgdocs/postgres/datatype-datetime.html#DATATYPE-TIMEZONES > specifically the point that POSIX zone names have the opposite sign > convention from ISO-8601. > > The great thing about standards is there are so many to choose from ;-) What isn't documented is why the sign changes for +0300 but not +03: test=> set timezone='+03:00'; SET test=> select now(); now --- 2011-04-26 18:22:55.571638-03 (1 row) test=> set timezone='+03'; SET test=> select now(); now --- 2011-04-27 00:23:00.627179+03 (1 row) It is the colon somehow: test=> set timezone='+03:'; ERROR: invalid value for parameter "TimeZone": "+03:" test=> select now(); now --- 2011-04-26 18:24:36.921323-03 (1 row) test=> set timezone='+03:0'; SET test=> select now(); now -- 2011-04-26 18:25:09.88588-03 (1 row) -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Setting timezone: is it bug or intended?
Bruce Momjian writes:
> Tom Lane wrote:
>> It already is documented. See
>> http://developer.postgresql.org/pgdocs/postgres/datatype-datetime.html#DATATYPE-TIMEZONES
>> specifically the point that POSIX zone names have the opposite sign
>> convention from ISO-8601.
>>
>> The great thing about standards is there are so many to choose from ;-)
> What isn't documented is why the sign changes for +0300 but not +03:
+03:00 is a legal POSIX zone name (hence the sign is different from SQL
convention). The other one is evidently being handled by this code path
in check_timezone:
/*
* Try it as a numeric number of hours (possibly fractional).
*/
hours = strtod(*newval, &endptr);
if (endptr != *newval && *endptr == '\0')
{
/* Here we change from SQL to Unix sign convention */
myextra.CTimeZone = -hours * SECS_PER_HOUR;
myextra.HasCTZSet = true;
}
which I think is legacy code meant to deal with SQL-standard
specification of timezone offsets as INTERVAL values. You get the same
interpretation of sign when you use the SQL-spec syntax:
regression=# set time zone interval '+03:00';
SET
regression=# select now();
now
---
2011-04-27 00:44:53.560295+03
(1 row)
Like I said, too many standards with their fingers in this pie.
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
