[BUGS] [7.3.3] select with stable function not being optimized to index scan
Your name : Barrie Slaymaker Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Pentium Operating System (example: Linux 2.0.26 ELF) : WinXP+cygwin PostgreSQL version (example: PostgreSQL-7.3.3): PostgreSQL-7.3.3 Compiler used (example: gcc 2.95.2) : Please enter a FULL description of your problem: Stable functions aren't elevated to index scans. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- interchange=# create or replace function int8foo() returns int8 as 'BEGIN RETURN 1; END' language 'plpgsql' stable; CREATE FUNCTION mydb=# explain select * from ann where fax_key = int8foo(); QUERY PLAN - Seq Scan on ann (cost=0.00..2524.55 rows=8 width=1012) Filter: (fax_key = int8foo()) (2 rows) mydb=# explain select * from ann where fax_key = 1; QUERY PLAN Index Scan using ann_fax_key_index on ann (cost=0.00..3.11 rows=7 width=1012) Index Cond: (fax_key = 1) (2 rows) mydb=# create or replace function int8foo() returns int8 as 'select 1::int8' language 'sql' stable; CREATE FUNCTION mydb=# explain select * from ann where fax_key = int8foo(); QUERY PLAN - Seq Scan on ann (cost=0.00..2524.55 rows=8 width=1012) Filter: (fax_key = int8foo()) (2 rows) mydb=# If you know how this problem might be fixed, list the solution below: - If you know how this problem might be fixed, list the solution below: - ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] [7.3.3] select with stable function not being optimized to index scan
The underlying problem turned out to be using an function returning int8 on a column of type int. When the function is altered to return int, an index scan is used. On Dec 10 2003, Barrie Slaymaker wrote: Your name : Barrie Slaymaker Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Pentium Operating System (example: Linux 2.0.26 ELF) : WinXP+cygwin PostgreSQL version (example: PostgreSQL-7.3.3): PostgreSQL-7.3.3 Compiler used (example: gcc 2.95.2) : Please enter a FULL description of your problem: Stable functions aren't elevated to index scans. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- interchange=# create or replace function int8foo() returns int8 as 'BEGIN RETURN 1; END' language 'plpgsql' stable; CREATE FUNCTION mydb=# explain select * from ann where fax_key = int8foo(); QUERY PLAN - Seq Scan on ann (cost=0.00..2524.55 rows=8 width=1012) Filter: (fax_key = int8foo()) (2 rows) mydb=# explain select * from ann where fax_key = 1; QUERY PLAN Index Scan using ann_fax_key_index on ann (cost=0.00..3.11 rows=7 width=1012) Index Cond: (fax_key = 1) (2 rows) mydb=# create or replace function int8foo() returns int8 as 'select 1::int8' language 'sql' stable; CREATE FUNCTION mydb=# explain select * from ann where fax_key = int8foo(); QUERY PLAN - Seq Scan on ann (cost=0.00..2524.55 rows=8 width=1012) Filter: (fax_key = int8foo()) (2 rows) mydb=# If you know how this problem might be fixed, list the solution below: - If you know how this problem might be fixed, list the solution below: - ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Changing line for user pgsql connecting via UNIX socket to "ident sameuser" causes pg_ctl start -s -w to fail.
Hello. I have FreeBSD 4.9-RELEASE-p1 and upgraded to PostgreSQL 7.4 (built it from FreeBSD port databases/postgresql7). With default pg_hba.conf everything is OK. When I change line in pg_hba.conf file from local all all trust to local all pgsql trust it works. Then I change the line to local all pgsql ident sameuser and try to start server with > su -l pgsql -c "pgsql start -D /home/pgsql/data -s -w" It does not start. In logfile there are messages: > Dec 11 13:40:19 tandem1 postgres[41718]: [1-1] LOG: XX000: could not create socket > for statistics collector: Protocol not supported > Dec 11 13:40:19 tandem1 postgres[41718]: [1-2] LOCATION: pgstat_init, pgstat.c:228 > Dec 11 13:40:19 tandem1 postgres[41722]: [2-1] LOG: 0: database system was shut > down at 2003-12-11 13:39:13 MSK > Dec 11 13:40:19 tandem1 postgres[41723]: [2-1] LOG: 0: connection received: > host=[local] port= > Dec 11 13:40:19 tandem1 postgres[41722]: [2-2] LOCATION: StartupXLOG, xlog.c:2598 > Dec 11 13:40:19 tandem1 postgres[41723]: [2-2] LOCATION: BackendFork, > postmaster.c:2389 > Dec 11 13:40:19 tandem1 postgres[41722]: [3-1] LOG: 0: checkpoint record is at > 0/9B0C4C > Dec 11 13:40:19 tandem1 postgres[41723]: [3-1] FATAL: 57P03: the database system is > starting up > Dec 11 13:40:19 tandem1 postgres[41722]: [3-2] LOCATION: StartupXLOG, xlog.c:2630 > Dec 11 13:40:19 tandem1 postgres[41723]: [3-2] LOCATION: ProcessStartupPacket, > postmaster.c:1431 > Dec 11 13:40:19 tandem1 postgres[41722]: [4-1] LOG: 0: redo record is at > 0/9B0C4C; undo record is at 0/0; shutdown TRUE > Dec 11 13:40:19 tandem1 postgres[41722]: [4-2] LOCATION: StartupXLOG, xlog.c:2655 > Dec 11 13:40:19 tandem1 postgres[41722]: [5-1] LOG: 0: next transaction ID: > 541; next OID: 17142 > Dec 11 13:40:19 tandem1 postgres[41722]: [5-2] LOCATION: StartupXLOG, xlog.c:2658 > Dec 11 13:40:19 tandem1 postgres[41722]: [6-1] LOG: 0: database system is ready > Dec 11 13:40:19 tandem1 postgres[41722]: [6-2] LOCATION: StartupXLOG, xlog.c:2948 > Dec 11 13:40:20 tandem1 postgres[41728]: [2-1] LOG: 0: connection received: > host=[local] port= > Dec 11 13:40:20 tandem1 postgres[41728]: [2-2] LOCATION: BackendFork, > postmaster.c:2389 > Dec 11 13:40:20 tandem1 postgres[41728]: [3-1] LOG: 0: connection authorized: > user=pgsql database=template1 > Dec 11 13:40:20 tandem1 postgres[41728]: [3-2] LOCATION: BackendFork, > postmaster.c:2451 > Dec 11 13:40:20 tandem1 postgres[41728]: [4-1] FATAL: 08P01: invalid frontend > message type 0 > Dec 11 13:40:20 tandem1 postgres[41728]: [4-2] LOCATION: SocketBackend, > postgres.c:366 > Dec 11 13:40:21 tandem1 postgres[41732]: [2-1] LOG: 0: connection received: > host=[local] port= > Dec 11 13:40:21 tandem1 postgres[41732]: [2-2] LOCATION: BackendFork, > postmaster.c:2389 > Dec 11 13:40:21 tandem1 postgres[41732]: [3-1] LOG: 0: connection authorized: > user=pgsql database=template1 > Dec 11 13:40:21 tandem1 postgres[41732]: [3-2] LOCATION: BackendFork, > postmaster.c:2451 > Dec 11 13:40:21 tandem1 postgres[41732]: [4-1] FATAL: 08P01: invalid frontend > message type 0 > Dec 11 13:40:21 tandem1 postgres[41732]: [4-2] LOCATION: SocketBackend, > postgres.c:366 > Dec 11 13:40:22 tandem1 postgres[41718]: [2-1] LOG: 0: received fast shutdown > request > Dec 11 13:40:22 tandem1 postgres[41718]: [2-2] LOCATION: pmdie, postmaster.c:1730 > Dec 11 13:40:22 tandem1 postgres[41735]: [3-1] LOG: 0: shutting down > Dec 11 13:40:22 tandem1 postgres[41735]: [3-2] LOCATION: ShutdownXLOG, xlog.c:3092 > Dec 11 13:40:24 tandem1 postgres[41735]: [4-1] LOG: 0: database system is shut > down > Dec 11 13:40:24 tandem1 postgres[41735]: [4-2] LOCATION: ShutdownXLOG, xlog.c:3106 I pressed CTRL-C after some time. If not to press it, the log will be longer, but the result is the same (there will be more connections that fail). When I tried to change pg_hba.conf online and then to make pg_ctl reload, postgresql continued running, but su -l pgsql -c "psql -l" failed with similar effects. Now I am running PostgreSQL with local all pgsql trust but it seems that it is not appropriate for secure environment. In PostgreSQL 7.3.4 everything worked (the matter begun when I moved old pg_hba.conf after upgrading). -- Constantin Stefanov ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] dyntest.pgc not working in 7.4 ?
On Wed, Dec 10, 2003 at 03:29:44PM -0600, Seum-Lim Gan wrote: > /platdb/bin/ecpg -I /platdb/include -o dyntest74.c dyntest.pgc > cc -I/platdb/include -R/platdb/lib -L/platdb/lib -lecpg -o > lucyDyntest74 dyntest74.c This looks like a wrong library. The latest ecpg does need more that libecpg. It also needs libpgtypes. Since you don't include this i wonder if you link against an older libecpg. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Changing line for user pgsql connecting via UNIX socket to "ident sameuser" causes pg_ctl start -s -w to fail.
Constantin Stefanov <[EMAIL PROTECTED]> writes: > Then I change the line to > local all pgsql ident sameuser > and try to start server with >> su -l pgsql -c "pgsql start -D /home/pgsql/data -s -w" > It does not start. It starts fine, as the log shows. Try not using "-w" ... I suspect there is something odd about the "su" environment that prevents pg_ctl from connecting with IDENT authorization, so it fails to realize that the postmaster has started. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] invalid page header problem
Hi! We currently have a serious problem with our postgres-DB! We are using postgres now for some time and lately we expericened that tables were corrupted on the 7.3.2 Database. After recreating the Tables by copying the contents to a save-table and then dropping and recreating the original table we could at least help that withourt losing data. We then decided it couldn't hurt to upgrade to 7.4 and hope that the problems were solved, but they weren't they just changed. In fact now we are losing data because we cannot select * from the table anymore without getting the new Error. At current we get the Error "invalid page header in block 2617 of relation ""; zeroing out page" We actually tried to find out what the problem was and the table was fine till some tuple crashed with the bug. We then made a pg_filedump, and added "zero_damaged_pages" to the config so that we could make a clean dump ... since the table is mainly used for high-traffic messaging it was ok to maybe lose the one block of messages by zeroing them out. The problem is, that this keeps happening and we don't know why ... Actually this is a fresh installation of postgres 7.4 and a fresh initialized database with a dump inserted with psql -e < dumpfile, showing the problems after just 12 hours of work. The only thing changed before compiling the postgres is the INDEX_MAX_ARGS to make it possible to send more than 32 parameters to a function which work and always worked fine because we do inserts and updates encapsulated in stored procedures. We also tried to check the HDD and could not find any evidence of corruption or problems on the HDD-Side ... Any help with how to find out more WHY this problem keeps showing up and how to fix this is appreciated, because the only thing we see is that perhaps some piece of hardware may be corrupt and we have to change that, but before spending a lot of money on new hardware i'd like to rule out that this is a software-problem! Regards ... Manuel ... ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] invalid page header problem
"Tarabas (Manuel Rorarius)" <[EMAIL PROTECTED]> writes: > We currently have a serious problem with our postgres-DB! I think you've got hardware problems. Have you tried running memory and disk tests? memtest86 and badblocks are the commonly recommended tools. Past reports have suggested that badblocks is more likely to detect problems if you use the "destructive test" option. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] unsubscribe me please!
Please take me off the email list. Thank you very much! ---(end of broadcast)--- TIP 3: 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 #1005: JDBC cancelRowUpdates() sets column values to null
The following bug has been logged online:
Bug reference: 1005
Logged by: Lars Tetzlaff
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4
Operating system: linux 2.4.23 i686
Description:JDBC cancelRowUpdates() sets column values to null
Details:
this sequence sets all but "plz" and "kategorie" to null, "kategorie" is changed to 0
rs.first();
rs.updateInt( "plz", 9 );
rs.cancelRowUpdates();
rs.updateInt( "plz", 6 );
rs.updateRow();
rs.beforeFirst();
Output before update:
Kunde Lars Tetzlaff
PLZ/Ort 51702 Bergneustadt
Straße Bahnhofstr. 32 E
Kategorie 1
Output after Update
Kunde null
PLZ/Ort 6 null
Straße null
Kategorie 0
If i comment out the second updateInt, the data is OK.
java version "1.4.2_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03)
Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode)
Table:
create table kunde
(
name varchar( 30 ) not null primary key,
plz integer,
ort varchar(30),
strasse varchar( 30 ),
kategorie integer not null
);
insert into kunde values ( 'Lars Tetzlaff', 51702, 'Bergneustadt', 'Bahnhofstr. 32 E',
1 );
Programm:
import java.sql.*;
public class connect
{
public static void main( String argv[] )
{
try {
//Class.forName("org.postgresql.Driver");
Connection db = DriverManager.getConnection( "jdbc:postgresql:tetzlaff",
"tetzlaff", "");
db.setAutoCommit( false );
// PreparedStatement pst = db.prepareStatement("insert into kunde values ( ?,
" +
//"?, ?, ?, ? )");
// pst.setString( 1, "Thomas Friese" );
// pst.setInt( 2, 51580 );
// pst.setString( 3, "Reichshof-Eckenhagen" );
// pst.setString( 4, "Landwehrstr. 7" );
// pst.setInt( 5, 3 );
// pst.executeUpdate();
Statement st = db.createStatement( ResultSet.TYPE_SCROLL_SENSITIVE,
ResultSet.CONCUR_UPDATABLE );
ResultSet rs = st.executeQuery("SELECT * FROM kunde");
if( rs.isBeforeFirst() ) {
System.out.println( "Alles klar" );
}
else{
System.out.println( "Wo bin ich denn?" );
}
while (rs.next()) {
//System.out.print("Column 1 returned ");
System.out.println( "Kunde " + rs.getString(1)
+ "\nPLZ/Ort "
+ rs.getInt(2) + " " + rs.getString(3)
+ "\nStraße " +rs.getString( "STRASSE" )
+ "\nKategorie " + rs.getInt( "kategorie" )
);
}
rs.first();
rs.updateInt( "plz", 9 );
rs.cancelRowUpdates();
rs.updateInt( "plz", 6 );
rs.updateRow();
rs.beforeFirst();
while (rs.next()) {
//System.out.print("Column 1 returned ");
System.out.println( "Kunde " + rs.getString(1)
+ "\nPLZ/Ort "
+ rs.getInt(2) + " " + rs.getString(3)
+ "\nStraße " +rs.getString( "STRASSE" )
+ "\nKategorie " + rs.getInt( "kategorie" )
);
}
rs.close();
st.close();
}
catch( Exception ex ){
System.out.println( "Exception" + ex );
}
}
}
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] postmaster.pid in version 7.4
Dario Marini wrote: > My postmaster.pid is something like: > > 23479 > /export/home1/staff/marini/pgsql/data > 5432001 11703 > > I don't know if there is something wrong with my installation (I run > postgresql on Ultra-2 station with Solaris 6), for sure I cannot stop > postgrsql server using: > > kill `cat /usr/local/pgsql/data/postmaster.pid` I've fixed the installation instructions as you suggest. At one point this worked, but later we added more information to the pid file. Thanks for the report. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Web form bugs
I think the bugs entered through the web form should set headers to allow responding to the user more easily. Right now you have to copy the email address into the reply mail manually. ---(end of broadcast)--- TIP 3: 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
Re: [BUGS] dyntest.pgc not working in 7.4 ?
Hi Michael, We tried but seems this didn't solve the problem. Actually the ldd command in the log I attached yesterday has showed the link to the right libecpgtypes.so and libpg.so. Adding the -lecpgtypes and -l libpg in build did not change anything. It looks to us that the sqlca.sqlcode will never be set to non-zero value when SQL errors, warnings, not_found happen. Gan At 4:09 pm +0100 2003/12/11, Michael Meskes wrote: On Wed, Dec 10, 2003 at 03:29:44PM -0600, Seum-Lim Gan wrote: /platdb/bin/ecpg -I /platdb/include -o dyntest74.c dyntest.pgc cc -I/platdb/include -R/platdb/lib -L/platdb/lib -lecpg -o lucyDyntest74 dyntest74.c This looks like a wrong library. The latest ecpg does need more that libecpg. It also needs libpgtypes. Since you don't include this i wonder if you link against an older libecpg. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- ++ | Seum-Lim GAN email : [EMAIL PROTECTED] | | Lucent Technologies| | 2000 N. Naperville Road, 6B-403F tel : (630)-713-6665 | | Naperville, IL 60566, USA.fax : (630)-713-7272 | | web : http://inuweb.ih.lucent.com/~slgan | ++ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] libpq3 + ssl memory leak
Neil Conway <[EMAIL PROTECTED]> writes: > I can verify this locally. Unfortunately, my copy of valgrind doesn't > seem to be picking up the debugging symbols for OpenSSL Ok, some progress. I installed a development snapshot of OpenSSL, and confirmed that the problem still occurs there. The full valgrind leak trace call stack is: ==14598== 8316 bytes in 99 blocks are definitely lost in loss record 5 of 7 ==14598==at 0x4002CA5D: malloc (vg_replace_malloc.c:153) ==14598==by 0x4040340C: default_malloc_ex (mem.c:79) ==14598==by 0x40403A93: CRYPTO_malloc (mem.c:304) ==14598==by 0x4048F8A4: asn1_item_ex_combine_new (tasn_new.c:171) ==14598==by 0x4048F5E4: ASN1_item_ex_new (tasn_new.c:83) ==14598==by 0x40491A91: ASN1_item_ex_d2i (tasn_dec.c:318) ==14598==by 0x40491423: ASN1_item_d2i (tasn_dec.c:115) ==14598==by 0x404897DD: d2i_X509 (x_x509.c:125) ==14598==by 0x403AAF22: ssl3_get_server_certificate (s3_clnt.c:837) ==14598==by 0x403A9E87: ssl3_connect (s3_clnt.c:295) ==14598==by 0x403B89AD: SSL_connect (ssl_lib.c:829) ==14598==by 0x4025C5FA: open_client_SSL (fe-secure.c:898) ==14598==by 0x4025B62B: pqsecure_open_client (fe-secure.c:253) ==14598==by 0x4024D496: PQconnectPoll (fe-connect.c:1518) ==14598==by 0x4024CBB0: connectDBComplete (fe-connect.c:1060) ==14598==by 0x4024BB8D: PQconnectdb (fe-connect.c:248) ==14598==by 0x804860E: main (leak.c:11) ==14598==by 0x40279DA5: __libc_start_main (libc-start.c:242) ==14598==by 0x8048540: ??? (start.S:102) (The line numbers are against the snapshot I'm using, which you can get from ftp://ftp.openssl.org/snapshot/openssl-SNAP-20031211.tar.gz) A cursory look at the libpq SSL code doesn't reveal anything obvious that we're doing wrong (e.g. SSL_new() calls seem to be matched up with SSL_free() calls AFAICS). The problem doesn't seem to occur if I link against 7.3's libpq.so, so this does seem to be a libpq bug (and not an OpenSSL leak). BTW Sean, do you have any insight into the problem? I'll continue working on it and let the list know if I learn anything new. -Neil ---(end of broadcast)--- TIP 3: 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
Re: [BUGS] BUG #1005: JDBC cancelRowUpdates() sets column values to
On Thu, 11 Dec 2003, PostgreSQL Bugs List wrote:
> Description:JDBC cancelRowUpdates() sets column values to null
>
> this sequence sets all but "plz" and "kategorie" to null, "kategorie"
> is changed to 0
>
> rs.first();
> rs.updateInt( "plz", 9 );
> rs.cancelRowUpdates();
> rs.updateInt( "plz", 6 );
> rs.updateRow();
> rs.beforeFirst();
>
> Output before update:
>
> Kunde Lars Tetzlaff
> PLZ/Ort 51702 Bergneustadt
> Straße Bahnhofstr. 32 E
> Kategorie 1
>
>
> Output after Update
>
> Kunde null
> PLZ/Ort 6 null
> Straße null
> Kategorie 0
>
Here's a patch to fix this.
Kris Jurka
? src/interfaces/jdbc/org/postgresql/copy
? src/interfaces/jdbc/org/postgresql/jdbc2/.AbstractJdbc2ResultSet.java.swp
? src/interfaces/jdbc/org/postgresql/test/jdbc2/.UpdateableResultTest.java.swp
? src/interfaces/jdbc/org/postgresql/test/jdbc2/CopyTest.notjava
? src/interfaces/jdbc/org/postgresql/test/jdbc2/ResultSetMetaDataTest.java
Index: src/interfaces/jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java
===
RCS file:
/projects/cvsroot/pgsql-server/src/interfaces/jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java,v
retrieving revision 1.27
diff -c -r1.27 AbstractJdbc2ResultSet.java
*** src/interfaces/jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java29 Nov
2003 19:52:10 - 1.27
--- src/interfaces/jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java11 Dec
2003 22:26:02 -
***
*** 519,525
{
doingUpdates = false;
! clearRowBuffer();
}
}
--- 519,525
{
doingUpdates = false;
! clearRowBuffer(true);
}
}
***
*** 662,668
this_row = rowBuffer;
// need to clear this in case of another insert
! clearRowBuffer();
}
--- 662,668
this_row = rowBuffer;
// need to clear this in case of another insert
! clearRowBuffer(false);
}
***
*** 707,713
// make sure the underlying data is null
! clearRowBuffer();
onInsertRow = true;
doingUpdates = false;
--- 707,713
// make sure the underlying data is null
! clearRowBuffer(false);
onInsertRow = true;
doingUpdates = false;
***
*** 715,725
}
! private synchronized void clearRowBuffer()
throws SQLException
{
// rowBuffer is the temporary storage for the row
rowBuffer = new byte[fields.length][];
// clear the updateValues hashTable for the next set of updates
updateValues.clear();
--- 715,730
}
! private synchronized void clearRowBuffer(boolean copyCurrentRow)
throws SQLException
{
// rowBuffer is the temporary storage for the row
rowBuffer = new byte[fields.length][];
+
+ // inserts want an empty array while updates want a copy of the
current row
+ if (copyCurrentRow) {
+ System.arraycopy(this_row, 0, rowBuffer, 0, this_row.length);
+ }
// clear the updateValues hashTable for the next set of updates
updateValues.clear();
Index: src/interfaces/jdbc/org/postgresql/test/jdbc2/UpdateableResultTest.java
===
RCS file:
/projects/cvsroot/pgsql-server/src/interfaces/jdbc/org/postgresql/test/jdbc2/UpdateableResultTest.java,v
retrieving revision 1.7
diff -c -r1.7 UpdateableResultTest.java
*** src/interfaces/jdbc/org/postgresql/test/jdbc2/UpdateableResultTest.java 11 Sep
2002 05:38:45 - 1.7
--- src/interfaces/jdbc/org/postgresql/test/jdbc2/UpdateableResultTest.java 11 Dec
2003 22:26:02 -
***
*** 15,39
public class UpdateableResultTest extends TestCase
{
public UpdateableResultTest( String name )
{
super( name );
}
public void testUpdateable()
{
try
{
- Connection con = TestUtil.openDB();
- TestUtil.createTable(con, "updateable", "id int primary key,
name text, notselected text");
- TestUtil.createTable(con, "second", "id1 int primary key,
name1 text");
-
- // put some dummy data into second
- Statement st2 = con.createStatement();
- st2.execute( "insert into second values (1,'an
Re: [BUGS] TimeZone bug again.....
Title: Message
[Arnold
Mavromatis]
Operating system is redhat 9
Postgres is 7.3.2 binary rpm for linux
Hi
It seems that because to_timestamp does a time-zone conversion
it is upsetting are attempt to load legitimate data...
Is it possible (similar to the to_date fix that was done some
time ago by tom lane) to have a similar method like
"to_timestamp_raw" or something that will store/retrieve date-times as given
in format/data without doing any datetime timezone
conversions?
This is going to be the only way that our data which spans
form 1800 to today and any time specified can be
stored and accurately retrieved..
Daylight savings etc we handle outside the database
records...
Ie lsd stands for local standard time and tm represents UTC
time which are the two times that we store...
Any help greately appreciated...
These date-time bugs are stopping us from advancing our
climate database on the external web using postgresql at the
moment...
(If you cannot fix it can you tell me where in the src code
the time-zone conversion is done and I will comment it out or
something...)
Cheers Arn
Error Example attached... (Time-zone is AEST)
Error is:-
tczadam=> insert into onelands(stn_num,lsd,tm,ob_qual_flag)
values(1007, to_timestamp('199310310100','MMDDHH24MI'), to_timestamp('199310301300','MMDDHH24MI'),0);
INSERT 7278527 1
tczadam=> insert into onelands(stn_num,lsd,tm,ob_qual_flag)
values(1007, to_timestamp('199310310200','MMDDHH24MI'), to_timestamp('199310301300','MMDDHH24MI'),0);
ERROR: Cannot insert a duplicate key into unique index
onelands_pkey
Table is
create table tcz.ONELANDS ( STN_NUM
NUMERIC(6,0), LSD
timestamp, TM
timestamp not null, OB_QUAL_FLAG NUMERIC(1,0) not null, STN_PRES NUMERIC(7,1)
CONSTRAINT
SFC_LNDS_stn_pres_ck
CHECK (((stn_pres is
not null) and
(stn_pres between
900.0 and 1100.0))
or (stn_pres is
null)), STN_PRES_QUAL NUMERIC(2,0)
CONSTRAINT
SFC_LNDS_stn_pres_q_ck
CHECK (((stn_pres_qual
is not null) and
(stn_pres_qual between
0 and 20))
or (stn_pres_qual is
null)), primary key (stn_num,lsd)
);
Re: [BUGS] dyntest.pgc not working in 7.4 ?
Hi, On Thu, Dec 11, 2003 at 04:10:05PM -0600, Seum-Lim Gan wrote: > Hi Michael, > > We tried but seems this didn't solve the problem. > > Actually the ldd command in the log I attached yesterday > has showed the link to the right libecpgtypes.so and libpg.so. You misunderstood me. I wasn't talking about libpq but about libpgtypes. The latest libecpg should depend on libpgtypes. Since yours doesn't I wonder which on you link to your program. Could you please tell me which version of libecpg you are using? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: 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
