[BUGS] Bug #846: Oncurrent transactions about select for update
zeng yubo ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Oncurrent transactions about select for update
Long Description
Two concurrent transactions control by "select for update", they can shared the
data with insert ?
Sample Code
The table Name is num_center .
select count(*) from num_center ;
we support the result execute is 100.
--(1) first , transaction A exceute:
begin work;
select * from num_center where type='lock_row' for update ;
insert into num_center( type , currval ) values ('test1',100);
--(2) then Transaction B exceute:
begin work;
select * from num_center where type='lock_row' for update ;
select count(*) from num_center ;
--(3) Transaction A exceute:
commit;
--(4) Transaction B exceute:
commit;
--the Transaction B Result is 100 .
why not be : 100 + 1 = 101 ?
No file was uploaded with this report
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[BUGS] OpenOffice loops calling SQLForeignKeys
Hi all, when using the new PostgreSQL ODBC driver version 7.02.00.05 OpenOffice loops when calling SQLForeignKeys. This doesn't happen when the old driver 7.02.00.3 was used. Best regards, Ocke -- dba.openoffice.org Example isn't another way to teach, it is the only way to teach. Albert Einstein ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] OpenOffice loops calling SQLForeignKeys
> -Original Message- > From: Ocke Janssen > > Hi all, > > when using the new PostgreSQL ODBC driver version 7.02.00.05 OpenOffice > loops when calling SQLForeignKeys. This doesn't happen when the old > driver 7.02.00.3 was used. Could you send me the example ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] initdb segfaulting.
On Wed, 11 Dec 2002, Tom Lane wrote: > Rudy Lippan <[EMAIL PROTECTED]> writes: > > postgres@war PGDATA $ date > > Sat Dec 14 02:12:00 Local time zone must be set--see zic manual page 2002 > > You've got a moderately broken platform there, IMHO. Everyone else in > the world defaults to GMT behavior if no recognizable timezone is set. I don't know about that. I just screwed up the time zone when setting up the system, and keep forgetting to fix it -- it acts as if it is set to GMT; however, the timezone name indicates that you have not configured the timezone on your system. I submitted the bug because I thought it might be indicative of a larger problem. IMO segfault == bug. And there is that tendency for bugs to live together. > But if you can provide a stack trace showing just where the backend is > choking, we could try to defend against this. > #0 0x0811bac8 in AtEOXact_Buffers (isCommit=1 '\001') at bufmgr.c:914 914 if (PrivateRefCount[i] != 0) (gdb) bt #0 0x0811bac8 in AtEOXact_Buffers (isCommit=1 '\001') at bufmgr.c:914 #1 0x08087980 in CommitTransaction () at xact.c:1018 #2 0x08087c52 in CommitTransactionCommand (forceCommit=1) at xact.c:1304 #3 0x0808cf04 in do_end () at bootparse.y:66 #4 0x0808d231 in Int_yyparse () at bootparse.y:143 #5 0x0808ef68 in BootstrapMain (argc=7, argv=0x823dbe4) at bootstrap.c:445 #6 0x080e94a1 in main (argc=8, argv=0xbcd4) at main.c:218 #7 0x401c2671 in __libc_start_main () from /lib/libc.so.6 (gdb) print i $1 = 59320 (gdb) print NBuffers $2 = 762602867 = Update: Just thought to play with this a bit more and: TZ="AA" ../pgsql7.3/bin/initdb <-- segfault TZ="A" ../pgsql7.3/bin/initdb <-- initdb failed TZ="" ../pgsql7.3/bin/initdb <-- works. Looks like a simple buffer overrun. -r ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] postmaster segfaults when pg_hba.cof is missing
POSTGRESQL BUG REPORT TEMPLATE Your name : Rudy Lippan Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : PII-400x4 Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.19-gentoo-r9 PostgreSQL version (example: PostgreSQL-7.3): PostgreSQL-7.3 Compiler used (example: gcc 2.95.2) : 2.95.3 Please enter a FULL description of your problem: I know this is a broken install, but postmaster should not segfault when it can't find a file. postgres@war PGDATA $ ../pgsql7.3/bin/postmaster LOG: load_hba: Unable to open authentication config file "/usr/local/PGDATA/pgsql7.3/pg_hba.conf": No such file or directory Segmentation fault (core dumped) Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- rm pg_hba.conf 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] initdb segfaulting.
Rudy Lippan <[EMAIL PROTECTED]> writes: > Just thought to play with this a bit more and: > TZ="AA" ../pgsql7.3/bin/initdb <-- segfault > TZ="A" ../pgsql7.3/bin/initdb <-- initdb failed > TZ="" ../pgsql7.3/bin/initdb <-- works. > Looks like a simple buffer overrun. Yeah, I think so. I cannot replicate a problem here, but that may just be a matter of how the linker chose to lay out static variables in my build. Please apply the attached patch against 7.3 and see if it fixes things for you. regards, tom lane *** src/backend/utils/adt/nabstime.c.orig Mon Nov 11 19:39:36 2002 --- src/backend/utils/adt/nabstime.cThu Dec 12 14:17:04 2002 *** *** 130,143 * XXX FreeBSD man pages indicate that this should work - thomas * 1998-12-12 */ ! strcpy(CTZName, tm->tm_zone); #elif defined(HAVE_INT_TIMEZONE) tm = localtime(&now); CDayLight = tm->tm_isdst; CTimeZone = ((tm->tm_isdst > 0) ? (TIMEZONE_GLOBAL - 3600) : TIMEZONE_GLOBAL); ! strcpy(CTZName, tzname[tm->tm_isdst]); #else /* neither HAVE_TM_ZONE nor * HAVE_INT_TIMEZONE */ CTimeZone = tb.timezone * 60; --- 130,143 * XXX FreeBSD man pages indicate that this should work - thomas * 1998-12-12 */ ! StrNCpy(CTZName, tm->tm_zone, MAXTZLEN+1); #elif defined(HAVE_INT_TIMEZONE) tm = localtime(&now); CDayLight = tm->tm_isdst; CTimeZone = ((tm->tm_isdst > 0) ? (TIMEZONE_GLOBAL - 3600) : TIMEZONE_GLOBAL); ! StrNCpy(CTZName, tzname[tm->tm_isdst], MAXTZLEN+1); #else /* neither HAVE_TM_ZONE nor * HAVE_INT_TIMEZONE */ CTimeZone = tb.timezone * 60; *** *** 212,225 * XXX FreeBSD man pages indicate that this should work - thomas * 1998-12-12 */ ! strcpy(CTZName, tm->tm_zone); #elif defined(HAVE_INT_TIMEZONE) tm = localtime(&now); CDayLight = tm->tm_isdst; CTimeZone = ((tm->tm_isdst > 0) ? (TIMEZONE_GLOBAL - 3600) : TIMEZONE_GLOBAL); ! strcpy(CTZName, tzname[tm->tm_isdst]); #else /* neither HAVE_TM_ZONE nor * HAVE_INT_TIMEZONE */ CTimeZone = tb.timezone * 60; --- 212,225 * XXX FreeBSD man pages indicate that this should work - thomas * 1998-12-12 */ ! StrNCpy(CTZName, tm->tm_zone, MAXTZLEN+1); #elif defined(HAVE_INT_TIMEZONE) tm = localtime(&now); CDayLight = tm->tm_isdst; CTimeZone = ((tm->tm_isdst > 0) ? (TIMEZONE_GLOBAL - 3600) : TIMEZONE_GLOBAL); ! StrNCpy(CTZName, tzname[tm->tm_isdst], MAXTZLEN+1); #else /* neither HAVE_TM_ZONE nor * HAVE_INT_TIMEZONE */ CTimeZone = tb.timezone * 60; ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Bug #847: plpgsql 'raise notice' > 4000 chars disconnects pgsql backend 7.2.1
stephen dee (ala_frosty@yaho#nospam#o.com) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
plpgsql 'raise notice' > 4000 chars disconnects pgsql backend 7.2.1
Long Description
Try this:
It will cause you (et al) to get disconnected from the back end. Very cool if you want
to annoy people.
SD
Sample Code
DROP FUNCTION sp_crashpg();
CREATE FUNCTION sp_crashpg() RETURNS varchar AS '
DECLARE
message varchar;
counts int4;
BEGIN
-- Do not crash yet:
message := repeat(''I am going to crash!'',200);
raise notice ''No crash: %'',message;
-- Okay, now bring it on HAL:
message := repeat(''I am going to crash!'',201);
raise notice ''Crash here: %'',message;
FOR counts IN 1..3 LOOP
-- DO NOTHING
END LOOP;
RETURN ''I told you so'';
END;'
LANGUAGE 'plpgsql';
No file was uploaded with this report
---(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] postmaster segfaults when pg_hba.cof is missing
On Thu, 2002-12-12 at 13:13, Rudy Lippan wrote:
> I know this is a broken install, but postmaster should not segfault when
> it can't find a file.
>
> postgres@war PGDATA $ ../pgsql7.3/bin/postmaster
> LOG: load_hba: Unable to open authentication config file
> "/usr/local/PGDATA/pgsql7.3/pg_hba.conf": No such file or directory
> Segmentation fault (core dumped)
Good catch. Here's a patch against CVS HEAD that fixes the problem.
The actual segfault was caused by a double pfree(), but ISTM that
failing to find pg_hba.conf should be a fatal error anyway, so I
increased the priority of the elog() from LOG to FATAL and refactored
the code a little bit.
Bruce: unless anyone has an objection, please apply.
Thanks for the report.
Cheers,
Neil
Index: src/backend/libpq/hba.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/libpq/hba.c,v
retrieving revision 1.90
diff -c -r1.90 hba.c
*** src/backend/libpq/hba.c 6 Dec 2002 04:37:02 - 1.90
--- src/backend/libpq/hba.c 12 Dec 2002 22:45:59 -
***
*** 841,856
file = AllocateFile(conf_file, "r");
if (file == NULL)
{
! /* The open of the config file failed. */
! elog(LOG, "load_hba: Unable to open authentication config file \"%s\": %m",
conf_file);
- pfree(conf_file);
- }
- else
- {
- hba_lines = tokenize_file(file);
- FreeFile(file);
}
pfree(conf_file);
}
--- 841,853
file = AllocateFile(conf_file, "r");
if (file == NULL)
{
! elog(FATAL,
! "load_hba: Unable to open authentication config file \"%s\": %m",
conf_file);
}
+
+ hba_lines = tokenize_file(file);
+ FreeFile(file);
pfree(conf_file);
}
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Bug #847: plpgsql 'raise notice' > 4000 chars
On Thu, 2002-12-12 at 17:18, [EMAIL PROTECTED] wrote: > plpgsql 'raise notice' > 4000 chars disconnects pgsql backend 7.2.1 > It will cause you (et al) to get disconnected from the back end. Works for me (i.e. no crash, a long elog() is returned to the client as expected), using CVS HEAD as of a couple days ago. Stephen: can you reproduce the problem with PostgreSQL 7.3 or 7.4-devel? Cheers, Neil ---(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] ecpg Oracle compatibility issue
I applied the attached patch. Your version looked like it would have doubled the double-quotes. As you mentioned, you couldn't get bison to work, so you weren't able to test it. Please look over this patch and make sure it is correct. Also check the other use of ECPGdisconnect(). Is that correct? Does it need "CURRENT"? --- Roland Karch wrote: > Hello together, > > While porting my TPC-C implementation from Oracle, I discovered the > attached problem with the EXEC SQL COMMIT RELEASE statement. > > Bye, > Roland > [ Attachment, skipping... ] > > ---(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 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug #847: plpgsql 'raise notice' > 4000 chars disconnects pgsql backend 7.2.1
[EMAIL PROTECTED] writes: > plpgsql 'raise notice' > 4000 chars disconnects pgsql backend 7.2.1 This is fixed in 7.2.2 and later. regards, tom lane ---(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] OpenOffice loops calling SQLForeignKeys
The call looks like SQLRETURN nRetcode = N3SQLForeignKeys(m_aStatementHandle, (SDB_ODBC_CHAR *) pPKQ, (catalog.hasValue() && aPKQ.getLength()) ? SQL_NTS : 0, (SDB_ODBC_CHAR *) pPKO, pPKO ? SQL_NTS : 0, (SDB_ODBC_CHAR *) pPKN, pPKN ? SQL_NTS : 0, (SDB_ODBC_CHAR *) pFKQ, (catalog2.hasValue() && aFKQ.getLength()) ? SQL_NTS : 0, (SDB_ODBC_CHAR *) pFKO, pFKO ? SQL_NTS : 0, (SDB_ODBC_CHAR *) pFKN, SQL_NTS ); where the first 3 arguments are NULL. The last 3 contains the information about one table. Another way to reproduce the bug would be to install the SRX643C version of OpenOffice. I just heard from the [EMAIL PROTECTED] mailing list that the snapshot 7.03.0001 shouldn't have the bug anymore. Best regards, Ocke Hiroshi Inoue wrote: -Original Message- From: Ocke Janssen Hi all, when using the new PostgreSQL ODBC driver version 7.02.00.05 OpenOffice loops when calling SQLForeignKeys. This doesn't happen when the old driver 7.02.00.3 was used. Could you send me the example ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- dba.openoffice.org Example isn't another way to teach, it is the only way to teach. Albert Einstein ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] possible INSERT bug
i have the following utility function, which I use to easily return the OID
of an the new row created by an INSERT query:
---
CREATE FUNCTION insert_record_return_oid(text) RETURNS int4 AS
' DECLARE
s_query ALIAS FOR $1;
oid int4;
BEGIN
EXECUTE s_query;
GET DIAGNOSTICS oid = RESULT_OID;
RETURN oid;
END;
' LANGUAGE 'plpgsql' with (ISSTRICT);
---
Which correctly returns the OID of the inserted row.
usage example:
---
insert_record_return_oid('insert into sys_states (s_state) values(''po'')
');
---
However, if I get tricky, and imbed this into a select to return the
inserted row, I get an error:
---
select * from sys_states
where oid= insert_record_return_oid('insert into sys_states (s_state)
values(''po'') ');
---
"Cannot insert duplicate key" and the insert query never happens.
This is not a problem - I just do things another way, but I was wondering
what caused this?
Cheers,
Mathew
postgresql 7.2, btw
---(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] time and current_time default formats
i haven't seen this covered, yet, so i thought i'd ask: is there a reason that the default behavior for the time data type is without timezone, while the default behavior for current_time is to return timetz? indirectly, this reveals what might be a bug (in 7.2.3): db# create table timetable (timecol time); db# insert into timetable select current_time; -- works just fine db# create temporary table timetable_tmp as select current_time from timetable; db# copy timetable_tmp to '/tmp/timetable_tmp.sql'; db# drop table timetable; db# create table timetable (timecol time); db# copy timetable from '/tmp/timetable_tmp.sql'; ERROR: copy: line 1, Bad time external representation why does the casting work when inserted via a select but not a copy? -tfo ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Bug #838: SSL problems in 7.3
Nathan Mueller wrote:
> Ok, I tested this out with TLSv1 and it worked fine. I found that the
> same mistake was being made on the client side of things too so I
> included a patch for that too.
OK, attached is the patch that I applied. It does strerror() but no
elog(ERROR) on the server side if SSL_get_error() returns
SSL_ERROR_SYSCALL and SSL_read() returns 0 rather than -1. This logic
matches the SSL_get_error() manual page.
I found a few cases you missed.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/backend/libpq/be-secure.c
===
RCS file: /cvsroot/pgsql-server/src/backend/libpq/be-secure.c,v
retrieving revision 1.16
diff -c -c -r1.16 be-secure.c
*** src/backend/libpq/be-secure.c 7 Nov 2002 18:45:51 - 1.16
--- src/backend/libpq/be-secure.c 12 Dec 2002 22:37:32 -
***
*** 288,294
case SSL_ERROR_WANT_READ:
break;
case SSL_ERROR_SYSCALL:
! elog(ERROR, "SSL SYSCALL error: %s", strerror(errno));
break;
case SSL_ERROR_SSL:
elog(ERROR, "SSL error: %s", SSLerrmessage());
--- 288,297
case SSL_ERROR_WANT_READ:
break;
case SSL_ERROR_SYSCALL:
! if (n == -1)
! elog(ERROR, "SSL SYSCALL error: %s",
strerror(errno));
! else
! strerror(errno));
break;
case SSL_ERROR_SSL:
elog(ERROR, "SSL error: %s", SSLerrmessage());
***
*** 337,343
case SSL_ERROR_WANT_WRITE:
break;
case SSL_ERROR_SYSCALL:
! elog(ERROR, "SSL SYSCALL error: %s", strerror(errno));
break;
case SSL_ERROR_SSL:
elog(ERROR, "SSL error: %s", SSLerrmessage());
--- 340,349
case SSL_ERROR_WANT_WRITE:
break;
case SSL_ERROR_SYSCALL:
! if (n == -1)
! elog(ERROR, "SSL SYSCALL error: %s",
strerror(errno));
! else
! strerror(errno));
break;
case SSL_ERROR_SSL:
elog(ERROR, "SSL error: %s", SSLerrmessage());
Index: src/interfaces/libpq/fe-secure.c
===
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-secure.c,v
retrieving revision 1.16
diff -c -c -r1.16 fe-secure.c
*** src/interfaces/libpq/fe-secure.c7 Nov 2002 18:45:51 - 1.16
--- src/interfaces/libpq/fe-secure.c12 Dec 2002 22:37:34 -
***
*** 270,276
case SSL_ERROR_WANT_READ:
break;
case SSL_ERROR_SYSCALL:
! printfPQExpBuffer(&conn->errorMessage,
libpq_gettext("SSL
SYSCALL error: %s\n"),
SOCK_STRERROR(SOCK_ERRNO));
break;
--- 270,277
case SSL_ERROR_WANT_READ:
break;
case SSL_ERROR_SYSCALL:
! if (n == -1)
! printfPQExpBuffer(&conn->errorMessage,
libpq_gettext("SSL
SYSCALL error: %s\n"),
SOCK_STRERROR(SOCK_ERRNO));
break;
***
*** 315,321
case SSL_ERROR_WANT_WRITE:
break;
case SSL_ERROR_SYSCALL:
! printfPQExpBuffer(&conn->errorMessage,
libpq_gettext("SSL
SYSCALL error: %s\n"),
SOCK_STRERROR(SOCK_ERRNO));
break;
--- 316,323
case SSL_ERROR_WANT_WRITE:
br
