Re: [BUGS] BUG #2697: 8.2beta1 SIGSEGV crash/assertion on insert statement w/ sub-select and placeholders
Rusty Conover <[EMAIL PROTECTED]> writes:
> LOG: execute : insert into bar (id, a) select id, $1 from foo
> DETAIL: parameters: $1 = '5'
> TRAP: FailedAssertion("!(n < list->length)", File: "list.c", Line: 392)
> LOG: server process (PID 21539) was terminated by signal 6
This looks like an already-reported bug in BIND processing:
http://archives.postgresql.org/pgsql-committers/2006-10/msg00107.php
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] 8.2beta1 (w32): server process crash (tsvector)
<[EMAIL PROTECTED]> writes: > the following query will crash the server process: > INSERT INTO news.news > SELECT * FROM news.news2; This is undoubtedly data-dependent. Can you supply some sample data that makes it happen? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #2693: Abut SQL ASCII through JDBC
The following bug has been logged online: Bug reference: 2693 Logged by: Delight Chen Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4 Operating system: Red Hat Enterprise Linux ES release 4 (Nahant) Kernel 2.6.9-5.ELsmp on an x86_64 Description:Abut SQL ASCII through JDBC Details: I tried to install postgresql 8.1.4 Initdb with SQL_ASCII is work. Create table is correct. Insert Big5 text data correctly. Try to view through /usr/local/pgsql/bin/psql and it's correct. But when I try to query throught JDBC Driver, it always says "invalid byte value for encoding" And I tried another version 7.3.3 of postgresql. Do all of thing above I metioned, and check it. Finally I check data throught JDBC Driver, it's work correctly. I think it's a bug for 8.1.4, so I report to you. Here is the log of Version 8.1.4 LOG: duration: 1.700 ms statement: set datestyle to 'ISO'; select version(), c ase when pg_encoding_to_char(1) = 'SQL_ASCII' then 'UNKNOWN' else getdatabaseenc oding() end; LOG: duration: 0.115 ms statement: set client_encoding = 'BIG5'; show autocomm it ERROR: invalid byte value for encoding "SQL_ASCII": 0xa4 Here is the log of Version 7.3.3 LOG: query: set datestyle to 'ISO'; select version(), case when pg_encoding_to_ char(1) = 'SQL_ASCII' then 'UNKNOWN' else getdatabaseencoding() end; LOG: query: set client_encoding = 'BIG5'; show autocommit LOG: query: select * from person_info where memo='大' ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2700: tsearch2: snowball api outdated.
The following bug has been logged online: Bug reference: 2700 Logged by: Andrea C. Granata Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2beta1 Operating system: Linux Description:tsearch2: snowball api outdated. Details: Hi, Please update snowball api (api.c, api.h, utilities.c, header.h in contrib/tsearch/snowball) otherwise gendict doesn't work. Bye, Andrea. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2697: SIGSEGV crash/assertion on insert statement w/ subselect (very simple test case)
The following bug has been logged online:
Bug reference: 2697
Logged by: Rusty Conover
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2beta1
Operating system: Fedora Core 5
Description:SIGSEGV crash/assertion on insert statement w/ subselect
(very simple test case)
Details:
8.2beta1 postgres crashes with an assertion failure (or segv when built
without assertions) on these steps via perl DBD::Pg 1.49:
$dbh->begin_work();
my @statements_1 = (
"create temp table foo(id integer) WITHOUT OIDS ON COMMIT DROP",
"create temp table bar(id integer, a integer) WITHOUT OIDS ON COMMIT DROP
",
"insert into foo (id) values (5)",
);
foreach my $s (@statements_1) {
$dbh->do($s) || die("failed to execute: $s " . $dbh->errstr());
}
# This causes the crash...
$dbh->do("insert into bar (id, a) select id, ? from foo", undef, 5) ||
die("Failed to execute");
$dbh->rollback();
$dbh->disconnect();
LOG: statement: begin
LOG: statement: create temp table foo(id integer) WITHOUT OIDS ON COMMIT
DROP
LOG: statement: create temp table bar(id integer, a integer) WITHOUT OIDS
ON COMMIT DROP
LOG: statement: insert into foo (id) values (5)
LOG: execute : insert into bar (id, a) select id, $1 from foo
DETAIL: parameters: $1 = '5'
TRAP: FailedAssertion("!(n < list->length)", File: "list.c", Line: 392)
LOG: server process (PID 21539) was terminated by signal 6
Mean while this works fine via psql:
begin;
create temp table foo(id integer) WITHOUT OIDS ON COMMIT DROP;
create temp table bar(id integer, a integer) WITHOUT OIDS ON COMMIT DROP;
insert into foo (id) values (5);
prepare foobar (integer) as insert into bar (id, a) select id, $1 from foo;
execute foobar(5);
commit;
It would appear that a seperate branch is getting used when you do a named
prepare.
Here is the gdb backtrace to the assertion:
#4 0x0818c2f1 in list_nth_cell (list=0x8bc54fc, n=2) at list.c:392
392 Assert(n < list->length);
(gdb) bt
#0 0x00320402 in __kernel_vsyscall ()
#1 0x004f2159 in raise () from /lib/libc.so.6
#2 0x004f36e3 in abort () from /lib/libc.so.6
#3 0x0827a031 in ExceptionalCondition (conditionName=Variable
"conditionName" is not available.
) at assert.c:51
#4 0x0818c2f1 in list_nth_cell (list=0x8bc54fc, n=2) at list.c:392
#5 0x0818c45d in list_nth (list=0x8bc54fc, n=2) at list.c:413
#6 0x08171217 in ExecOpenScanRelation (estate=0x8bde02c, scanrelid=3) at
execUtils.c:823
#7 0x0817b7dd in ExecInitSeqScan (node=0x8bdd420, estate=0x8bde02c,
eflags=0) at nodeSeqscan.c:150
#8 0x08169431 in ExecInitNode (node=0x8bdd420, estate=0x8bde02c, eflags=0)
at execProcnode.c:164
#9 0x08167018 in ExecutorStart (queryDesc=0x8bdd5f0, eflags=0) at
execMain.c:628
#10 0x081fdc26 in ProcessQuery (parsetree=Variable "parsetree" is not
available.
) at pquery.c:152
#11 0x081feb57 in PortalRunMulti (portal=0x8baf89c, dest=0x83570b4,
altdest=0x83570b4, completionTag=0xbf872080 "") at pquery.c:1145
#12 0x081ff4bd in PortalRun (portal=0x8baf89c, count=2147483647,
dest=0x8b90ed0, altdest=0x8b90ed0, completionTag=0xbf872080 "") at
pquery.c:700
#13 0x081fbf40 in PostgresMain (argc=4, argv=Variable "argv" is not
available.
) at postgres.c:1775
#14 0x081d08d2 in ServerLoop () at postmaster.c:2848
#15 0x081d1644 in PostmasterMain (argc=4, argv=0x8b301a0) at
postmaster.c:950
#16 0x0818b9b0 in main (argc=4, argv=Cannot access memory at address 0x5442
If I can be of assistance please feel free to contact me.
Thanks,
Rusty
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[BUGS] BUG #2695: Randomly repeated query execution
The following bug has been logged online: Bug reference: 2695 Logged by: Jakub Email address: [EMAIL PROTECTED] PostgreSQL version: Postgres 7.4 Operating system: Linux Description:Randomly repeated query execution Details: Sometimes, randomly single query execution is repeated twice or more in 2-5 second. Thanks, Jakub ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #2698: Update table alias not supported
The following bug has been logged online:
Bug reference: 2698
Logged by: Lachhman Dass
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Windows 2000 Professional
Description:Update table alias not supported
Details:
In the Update statement alias must be supported and the syntax should be
UPDATE [ ONLY ] table alias SET column = { expression | DEFAULT } [, ...]
[ FROM fromlist ]
[ WHERE condition ]
this is required when same table is used multiple time in where clause and
you want to restrict the selection.
Thanks,
Lachhman Dass
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[BUGS] 8.1.5 rpms for FC5
Hi. There seems to be files missing in the rpm packages for postgresql 8.1.5. [] rpm -Uvh postgresql*.rpm error: Failed dependencies: libpq.so is needed by postgresql-server-8.1.5-2PGDG.i686 libpq.so is needed by postgresql-tcl-1.5.2-4PGDG.i686 i got my rpms from ftp.no.postgresql.org the files are: postgresql-8.1.5-2PGDG.i686.rpm postgresql-contrib-8.1.5-2PGDG.i686.rpm postgresql-devel-8.1.5-2PGDG.i686.rpm postgresql-docs-8.1.5-2PGDG.i686.rpm postgresql-jdbc-8.1.407-4PGDG.i686.rpm postgresql-libs-8.1.5-2PGDG.i686.rpm postgresql-odbc-08.02.0100-2PGDG.i686.rpm postgresql-pl-8.1.5-2PGDG.i686.rpm postgresql-python-3.8.1-3PGDG.i686.rpm postgresql-server-8.1.5-2PGDG.i686.rpm postgresql-tcl-1.5.2-4PGDG.i686.rpm postgresql-test-8.1.5-2PGDG.i686.rpm ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #2696: odbc driver cannot connect
The following bug has been logged online: Bug reference: 2696 Logged by: Ergin Ozekes Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: ubuntu Description:odbc driver cannot connect Details: I have installed openldap with back-sql.I have not connected to postgres via openldap.I have get an error below.What is the problem? Please help me! Thanks! [EMAIL PROTECTED]:/etc# /usr/local/libexec/slapd -f /etc/ldap/slapd.conf -d 1 @(#) $OpenLDAP: slapd 2.2.26 (Oct 22 2006 14:50:40) $ [EMAIL PROTECTED]:/opt/openLdap/openldap-src/servers/slapd daemon_init: listen on ldap:/// daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap:///) daemon: initialized ldap:/// daemon_init: 2 listeners opened slapd init: initiated server. ==>backsql_initialize() <==backsql_initialize() >>> dnNormalize: => ldap_bv2dn(cn=Subschema,0) ldap_err2string <= ldap_bv2dn(cn=Subschema)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(cn=subschema)=0 Success <<< dnNormalize: ==>backsql_db_init() ==>backsql_init_db_env() <==backsql_init_db_env()=0 <==backsql_db_init() >>> dnPrettyNormal: => ldap_bv2dn(o=sql,c=RU,0) ldap_err2string <= ldap_bv2dn(o=sql,c=RU)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(o=sql,c=RU)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(o=sql,c=ru)=0 Success <<< dnPrettyNormal: , >>> dnPrettyNormal: => ldap_bv2dn(cn=root,o=sql,c=RU,0) ldap_err2string <= ldap_bv2dn(cn=root,o=sql,c=RU)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(cn=root,o=sql,c=RU)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(cn=root,o=sql,c=ru)=0 Success <<< dnPrettyNormal: , ==>backsql_db_config() <==backsql_db_config(): dbname=PgSQL ==>backsql_db_config() <==backsql_db_config(): dbuser=ldap ==>backsql_db_config() <==backsql_db_config(): dbpasswd= ==>backsql_db_config() <==backsql_db_config(): insentry_query=insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from ldap_entries),?,?,?,?) ==>backsql_db_config() <==backsql_db_config(): upper_func=upper ==>backsql_db_config() <==backsql_db_config(): strcast_func=text ==>backsql_db_config() <==backsql_db_config(): concat_pattern="?||?" ==>backsql_db_config() <==backsql_db_config(): has_ldapinfo_dn_ru=no matching_rule_use_init 1.2.840.113556.1.4.804 (integerBitOrMatch): matchingRuleUse: ( 1.2.840.113556.1.4.804 NAME 'integerBitOrMatch' APPLIES ( mailPreferenceOption $ supportedLDAPVersion ) ) 1.2.840.113556.1.4.803 (integerBitAndMatch): matchingRuleUse: ( 1.2.840.113556.1.4.803 NAME 'integerBitAndMatch' APPLIES ( mailPreferenceOption $ supportedLDAPVersion ) ) 1.3.6.1.4.1.1466.109.114.2 (caseIgnoreIA5Match): matchingRuleUse: ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' APPLIES ( janetMailbox $ cNAMERecord $ sOARecord $ nSRecord $ mXRecord $ mDRecord $ aRecord $ email $ associatedDomain $ dc $ mail $ altServer ) ) 1.3.6.1.4.1.1466.109.114.1 (caseExactIA5Match): matchingRuleUse: ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' APPLIES ( janetMailbox $ cNAMERecord $ sOARecord $ nSRecord $ mXRecord $ mDRecord $ aRecord $ email $ associatedDomain $ dc $ mail $ altServer ) ) 2.5.13.35 (certificateMatch): matchingRuleUse: ( 2.5.13.35 NAME 'certificateMatch' APPLIES ( cACertificate $ userCertificate ) ) 2.5.13.34 (certificateExactMatch): matchingRuleUse: ( 2.5.13.34 NAME 'certificateExactMatch' APPLIES ( cACertificate $ userCertificate ) ) 2.5.13.30 (objectIdentifierFirstComponentMatch): matchingRuleUse: ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' APPLIES ( supportedApplicationContext $ ldapSyntaxes $ supportedFeatures $ supportedExtension $ supportedControl ) ) 2.5.13.29 (integerFirstComponentMatch): matchingRuleUse: ( 2.5.13.29 NAME 'integerFirstComponentMatch' APPLIES ( mailPreferenceOption $ supportedLDAPVersion ) ) 2.5.13.27 (generalizedTimeMatch): matchingRuleUse: ( 2.5.13.27 NAME 'generalizedTimeMatch' APPLIES ( modifyTimestamp $ createTimestamp ) ) 2.5.13.24 (protocolInformationMatch): matchingRuleUse: ( 2.5.13.24 NAME 'protocolInformationMatch' APPLIES protocolInformation ) 2.5.13.23 (uniqueMemberMatch): matchingRuleUse: ( 2.5.13.23 NAME 'uniqueMemberMatch' APPLIES uniqueMember ) 2.5.13.22 (presentationAddressMatch): matchingRuleUse: ( 2.5.13.22 NAME 'presentationAddressMatch' APPLIES presentationAddress ) 2.5.13.20 (telephoneNumberMatch): matchingRuleUse: ( 2.5.13.20 NAME 'telephoneNumberMatch' APPLIES ( pager $ mobile $ homePhone $ telephoneNumber ) ) 2.5.13.17 (octetStringMatch): matchingRuleUse: ( 2.5.13.17 NAME 'octetStringMatch' APPLIES userPassword ) 2.5.13.16 (bitStringMatch): matchingRuleUse: ( 2.5.13.16 NAME 'bitStringMatch' APPLIES x500UniqueIdentifier ) 2.5.13.14 (integerMatch): matchingRuleUse: ( 2.5.13.14 NAME 'integerMatch' APPLIES ( mailPreferenceOption $ supportedLDAPVersion ) ) 2.5.13.13 (booleanMatch): matchingRuleUse: ( 2.5.1
[BUGS] BUG #2702: odbc driver cannot connect
The following bug has been logged online: Bug reference: 2702 Logged by: Ergin Ozekes Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: ubuntu Description:odbc driver cannot connect Details: [EMAIL PROTECTED]:/etc# /usr/local/libexec/slapd -f /etc/ldap/slapd.conf -d 1 @(#) $OpenLDAP: slapd 2.2.26 (Oct 22 2006 14:50:40) $ [EMAIL PROTECTED]:/opt/openLdap/openldap-src/servers/slapd daemon_init: listen on ldap:/// daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap:///) daemon: initialized ldap:/// daemon_init: 2 listeners opened slapd init: initiated server. ==>backsql_initialize() <==backsql_initialize() >>> >>> dnNormalize: => ldap_bv2dn(cn=Subschema,0) ldap_err2string <= ldap_bv2dn(cn=Subschema)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(cn=subschema)=0 Success <<< dnNormalize: ==>backsql_db_init() ==>backsql_init_db_env() <==backsql_init_db_env()=0 <==backsql_db_init() >>> >>> dnPrettyNormal: => ldap_bv2dn(o=sql,c=RU,0) ldap_err2string <= ldap_bv2dn(o=sql,c=RU)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(o=sql,c=RU)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(o=sql,c=ru)=0 Success <<< dnPrettyNormal: , >>> >>> dnPrettyNormal: => ldap_bv2dn(cn=root,o=sql,c=RU,0) ldap_err2string <= ldap_bv2dn(cn=root,o=sql,c=RU)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(cn=root,o=sql,c=RU)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(cn=root,o=sql,c=ru)=0 Success <<< dnPrettyNormal: , ==>backsql_db_config() <==backsql_db_config(): dbname=PgSQL ==>backsql_db_config() <==backsql_db_config(): dbuser=ldap ==>backsql_db_config() <==backsql_db_config(): dbpasswd= ==>backsql_db_config() <==backsql_db_config(): insentry_query=insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from ldap_entries),?,?,?,?) ==>backsql_db_config() <==backsql_db_config(): upper_func=upper ==>backsql_db_config() <==backsql_db_config(): strcast_func=text ==>backsql_db_config() <==backsql_db_config(): concat_pattern="?||?" ==>backsql_db_config() <==backsql_db_config(): has_ldapinfo_dn_ru=no matching_rule_use_init 1.2.840.113556.1.4.804 (integerBitOrMatch): matchingRuleUse: ( 1.2.840.113556.1.4.804 NAME 'integerBitOrMatch' APPLIES ( mailPreferenceOption $ supportedLDAPVersion ) ) 1.2.840.113556.1.4.803 (integerBitAndMatch): matchingRuleUse: ( 1.2.840.113556.1.4.803 NAME 'integerBitAndMatch' APPLIES ( mailPreferenceOption $ supportedLDAPVersion ) ) 1.3.6.1.4.1.1466.109.114.2 (caseIgnoreIA5Match): matchingRuleUse: ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' APPLIES ( janetMailbox $ cNAMERecord $ sOARecord $ nSRecord $ mXRecord $ mDRecord $ aRecord $ email $ associatedDomain $ dc $ mail $ altServer ) ) 1.3.6.1.4.1.1466.109.114.1 (caseExactIA5Match): matchingRuleUse: ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' APPLIES ( janetMailbox $ cNAMERecord $ sOARecord $ nSRecord $ mXRecord $ mDRecord $ aRecord $ email $ associatedDomain $ dc $ mail $ altServer ) ) 2.5.13.35 (certificateMatch): matchingRuleUse: ( 2.5.13.35 NAME 'certificateMatch' APPLIES ( cACertificate $ userCertificate ) ) 2.5.13.34 (certificateExactMatch): matchingRuleUse: ( 2.5.13.34 NAME 'certificateExactMatch' APPLIES ( cACertificate $ userCertificate ) ) 2.5.13.30 (objectIdentifierFirstComponentMatch): matchingRuleUse: ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' APPLIES ( supportedApplicationContext $ ldapSyntaxes $ supportedFeatures $ supportedExtension $ supportedControl ) ) 2.5.13.29 (integerFirstComponentMatch): matchingRuleUse: ( 2.5.13.29 NAME 'integerFirstComponentMatch' APPLIES ( mailPreferenceOption $ supportedLDAPVersion ) ) 2.5.13.27 (generalizedTimeMatch): matchingRuleUse: ( 2.5.13.27 NAME 'generalizedTimeMatch' APPLIES ( modifyTimestamp $ createTimestamp ) ) 2.5.13.24 (protocolInformationMatch): matchingRuleUse: ( 2.5.13.24 NAME 'protocolInformationMatch' APPLIES protocolInformation ) 2.5.13.23 (uniqueMemberMatch): matchingRuleUse: ( 2.5.13.23 NAME 'uniqueMemberMatch' APPLIES uniqueMember ) 2.5.13.22 (presentationAddressMatch): matchingRuleUse: ( 2.5.13.22 NAME 'presentationAddressMatch' APPLIES presentationAddress ) 2.5.13.20 (telephoneNumberMatch): matchingRuleUse: ( 2.5.13.20 NAME 'telephoneNumberMatch' APPLIES ( pager $ mobile $ homePhone $ telephoneNumber ) ) 2.5.13.17 (octetStringMatch): matchingRuleUse: ( 2.5.13.17 NAME 'octetStringMatch' APPLIES userPassword ) 2.5.13.16 (bitStringMatch): matchingRuleUse: ( 2.5.13.16 NAME 'bitStringMatch' APPLIES x500UniqueIdentifier ) 2.5.13.14 (integerMatch): matchingRuleUse: ( 2.5.13.14 NAME 'integerMatch' APPLIES ( mailPreferenceOption $ supportedLDAPVersion ) ) 2.5.13.13 (booleanMatch): matchingRuleUse: ( 2.5.13.13 NAME 'booleanMatch' APPLIES hasSubordinates ) 2.5.13.11 (caseIgnoreListMatch): matchingRuleUse: ( 2.5.13.11 NAME 'caseIgnoreListMatch' AP
[BUGS] BUG #2701: PQserverVersion function missing
The following bug has been logged online: Bug reference: 2701 Logged by: Seth Gordon Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.7 Operating system: Linux (Debian stable) Description:PQserverVersion function missing Details: The 8.0/8.1 documentation for libpq says the following about PQserverVersion: "Applications may use this to determine the version of the database server they are connected to. The number is formed by converting the major, minor, and revision numbers into two-decimal-digit numbers and appending them together. For example, version 7.4.2 will be returned as 70402, and version 8.1 will be returned as 80100 (leading zeroes are not shown). Zero is returned if the connection is bad." But libpq for 7.4.7 does not have this function. So this is either a bug in the 7.4 code or a bug in the 8.1 documentation. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #2699: Delete table alias not supported
The following bug has been logged online: Bug reference: 2699 Logged by: Lachhman Dass Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: Windows 2000 Professional Description:Delete table alias not supported Details: Delete table alias is not supported. Exact syntax should be DELETE FROM [ ONLY ] table [alias] [ WHERE condition ] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2695: Randomly repeated query execution
On Mon, 16 Oct 2006, Jakub wrote: > > The following bug has been logged online: > > Bug reference: 2695 > Logged by: Jakub > Email address: [EMAIL PROTECTED] > PostgreSQL version: Postgres 7.4 > Operating system: Linux > Description:Randomly repeated query execution > Details: > > Sometimes, randomly single query execution is repeated twice or more in > 2-5 second. > > Thanks, > Jakub > Jakub, I've seen this type of thing before, but it wasn't Postgres' fault. In the examples I've seen (on many different occasions, in differing circumstances) the application was actually issuing the query multiple times and usually the cause of that was improper (multiple) event handling by the application's GUI. In particular, if the language is Java, look for errant event-handling methods. I've also seen this type of error caused by error handling packages that attempt to auto-recover based on various errors when they have a bug regarding what kinds of errors are recoverable and which are not. As examples, a lost network link may be recoverable, but an attribute not existing in a table/relation is not. Try some very careful coding around the suspect queries to log in your own code whether queries are being repeated or not. Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [BUGS] BUG #2683: spi_exec_query in plperl returns
On Sun, Oct 15, 2006 at 06:15:27PM -0400, Tom Lane wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> > I am also wondering, now that it's been raised, if we need to issue a "use
> > utf8;" in the startup code, so that literals in the code get the right
> > encoding.
>
> Good question. I took care to ensure that the code strings passed to
> Perl are marked as UTF8; perhaps that makes it happen implicitly?
> If not, are there any downsides to issuing "use utf8"?
What "use utf8" does is allow the *source* to be in utf8, thus affecting
what's a valid identifier and such. It doesn't affect the data, for
that you need "use encoding 'utf8'".
It's clear whether you actually want to allow people to put utf8
characters directly into their source (especially if the database is
not in utf8 encoding anyway). There is always the \u{} escape.
The perlunicode man page describe it better, though I only have
perl5.8. In know the perl5.6 model was different and somewhat more
awkward to use.
Have a nice day,
--
Martijn van Oosterhout http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to
> litigate.
signature.asc
Description: Digital signature
Re: [BUGS] BUG #2693: Abut SQL ASCII through JDBC
Delight Chen wrote: > Initdb with SQL_ASCII is work. If you do that, most of the encoding stuff won't work correctly. Use some other encoding. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] 8.1.5 rpms for FC5
Hi, On Mon, 2006-10-16 at 19:29 +0200, stig erikson wrote: > There seems to be files missing in the rpm packages for postgresql 8.1.5. > > [] rpm -Uvh postgresql*.rpm > error: Failed dependencies: > libpq.so is needed by postgresql-server-8.1.5-2PGDG.i686 > libpq.so is needed by postgresql-tcl-1.5.2-4PGDG.i686 > Ooops :-( It is my bad. Sorry. We are giving a respin to the 8.1.5 RPMs. They will be in main FTP site in two hours and will be tagged as 8.1.5-3PGDG. BTW... The problem was the wrong dependency in the postgresql-server rpm; it was not a missing file. Regards, - The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
Re: [BUGS] 8.2beta1 (w32): server process crash (tsvector)
the following query will crash the server process:
INSERT INTO news.news
SELECT * FROM news.news2;
This is undoubtedly data-dependent. Can you supply some sample data
that makes it happen?
it's not only happening with INSERTS, but also updates. as thats easier to
test, here's how i can reproduce the error:
1. create new database (encoding: UTF8) with tsearch2 on 8.2b1 win32 (system
locale: de_CH.1252)
2. insert the data from the zip file
[http://alternize.com/pgsql/tsearch2test.zip] (be sure to also update
pg_ts_cf /
pg_ts_cfgmap as we have WIN1252 locale)
3. execute UPDATE test SET idxFTI = to_tsvector('default', "sometext"); or
similar queries
4. hopefully see the process crashing as i do ;-)
2006-10-17 17:23:44 LOG: server process (PID 4584) exited with exit
code -1073741819
2006-10-17 17:23:44 LOG: terminating any other active server processes
2006-10-17 17:23:44 WARNING: terminating connection because of crash of
another server process
2006-10-17 17:23:44 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.
{snipp}
2006-10-17 17:23:44 LOG: all server processes terminated; reinitializing
2006-10-17 17:23:44 LOG: database system was interrupted at 2006-10-17
17:23:41 W. Europe Daylight Time
2006-10-17 17:23:44 LOG: Windows fopen("recovery.conf","r") failed: code 2,
errno 2
2006-10-17 17:23:44 LOG: Windows fopen("pg_xlog/0001.history","r")
failed: code 2, errno 2
2006-10-17 17:23:44 LOG: Windows fopen("backup_label","r") failed: code 2,
errno 2
2006-10-17 17:23:44 LOG: checkpoint record is at 0/E2ECA728
2006-10-17 17:23:44 LOG: redo record is at 0/E2ECA728; undo record is at
0/0; shutdown FALSE
2006-10-17 17:23:44 LOG: next transaction ID: 0/514299; next OID: 6276957
2006-10-17 17:23:44 LOG: next MultiXactId: 1; next MultiXactOffset: 0
2006-10-17 17:23:44 LOG: database system was not properly shut down;
automatic recovery in progress
2006-10-17 17:23:44 LOG: redo starts at 0/E2ECA778
2006-10-17 17:23:44 LOG: unexpected pageaddr 0/DB0CC000 in log file 0,
segment 227, offset 835584
2006-10-17 17:23:44 LOG: redo done at 0/E30CBE78
2006-10-17 17:23:45 LOG: database system is ready
2006-10-17 17:23:45 LOG: Windows fopen("global/pg_fsm.cache","rb") failed:
code 2, errno 2
2006-10-17 17:23:45 LOG: transaction ID wrap limit is 2147484172, limited
by database "postgres"
2006-10-17 17:23:45 LOG: Windows fopen("global/pgstat.stat","rb") failed:
code 2, errno 2
i've also tried to update each record on its own in a for-loop. here the
crash happens as well, sometimes after 10 updates, sometimes after 100
updates, sometimes even after 1 update. but eventually every record can be
updated. so i do not think its entierly content-related...
for what its worth, here's the output of pg_controldata:
pg_control version number:822
Catalog version number: 200609181
Database system identifier: 4986650172201464825
Database cluster state: in production
pg_control last modified: 17.10.2006 17:44:29
Current log file ID: 0
Next log file segment:230
Latest checkpoint location: 0/E4E0F978
Prior checkpoint location:0/E46BF420
Latest checkpoint's REDO location:0/E4E03098
Latest checkpoint's UNDO location:0/0
Latest checkpoint's TimeLineID: 1
Latest checkpoint's NextXID: 0/531333
Latest checkpoint's NextOID: 6285149
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0
Time of latest checkpoint:17.10.2006 17:43:45
Minimum recovery ending location: 0/0
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 131072
WAL block size: 8192
Bytes per WAL segment:16777216
Maximum length of identifiers:64
Maximum columns in an index: 32
Date/time type storage: floating-point numbers
Maximum length of locale name:128
LC_COLLATE: German_Switzerland.1252
LC_CTYPE: German_Switzerland.1252
let me know if more information / data is needed.
on a sidenote: are those fopen() errors debug-code-leftovers or something
one should worry about? i can't find those files on the file system.
- thomas
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[BUGS] BUG #2704: pg_class.relchecks overflow problem
The following bug has been logged online: Bug reference: 2704 Logged by: Toru SHIMOGAKI Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4 Operating system: Red Hat Enterprise Linux AS 4 Description:pg_class.relchecks overflow problem Details: Hi, pg_class.relchecks is defined as int2. But the upper bound of this value is not checked and it overflows. I found it at the following case: 1. I tried to add check constraints: "alter table test_a add check (aaa > i);" (0 <= i <= 32767) 2. When I added the 32768th check constraint, the value of pg_class.relchecs became -32768. postgres=# alter table test_a add check ( aaa > 32768 ); ALTER TABLE postgres=# select relname, relchecks from pg_class where relname = 'test_a'; relname | relchecks -+--- test_a | -32768 (1 row) 3. The following error message was found when I added the next one: postgres=# alter table test_a add check ( aaa > 32769 ); ERROR: unexpected constraint record found for rel test_a postgres=# select relname, relchecks from pg_class where relname = 'test_a'; relname | relchecks -+--- test_a | -32768 (1 row) Best regards, ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
