Re: [BUGS] BUG #2289: insert into tables not working
[Please copy the mailing list on replies.] On Wed, Mar 01, 2006 at 08:55:29AM -0800, Abhilash Krishnan wrote: > ya the transactions are commited also no error has been shown in any > of the operations How are you determining that data isn't getting inserted? If you do a select in the same transaction as the inserts, do you see the data? If you commit the transaction and then start a new transaction, does a select in the new transaction see the data? If concurrent transactions aren't able to see the data even after it's committed, what isolation level are those transactions using? A SERIALIZABLE transaction won't see data committed by other transactions after its snapshot has been taken. If none of this helps then could you post a series of steps that somebody could use to duplicate the problem? -- Michael Fuhr ---(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] FATAL: semctl(1672698088, 12, SETVAL, 0) failed
On Tue, 28 Feb 2006, Bruce Momjian wrote: > > Uh, how do we handle it now? I thought we did just that. > > OK, so how do we find the answer? > For both problems, I am uncertain (or I've sent a patch already :-(). Call more artillery support here ... Regards, Qingqing ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] FATAL: semctl(1672698088, 12, SETVAL, 0) failed
Qingqing Zhou wrote:
>
> "Bruce Momjian" wrote
> > > In port/win32.h, we have
> > >
> > > #undef EAGAIN
> > > #undef EINTR
> > > #define EINTR WSAEINTR
> > > #define EAGAIN WSAEWOULDBLOCK
> > >
> > > What's the rationale of doing so?
> >
> > We did this so that our code could refer to EINTR/EAGAIN without
> > port-specific tests.
> >
>
> AFAICS, by doing so, the EINTR/EAGAIN will be translated into
> WSAINTR/WSAEWOULDBLOCK through *all* the backend code. That's seems not
> appropriate for the code not involving any socket stuff ... I think we need
> a fix here.
Uh, how do we handle it now? I thought we did just that.
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/waitformultipleobjectsex.asp
> >
> > and it isn't clear what return failure values it has. We certainly
> > could loop on WSAEINTR. Can you test it?
> >
>
> Yeah, looking at other code of using semop(), we could plug in a loop in the
> win32 semctl():
>
>/* Quickly lock/unlock the semaphore (if we can) */
> + do
> + {
> +errStatus = semop(semId, &sops, 1);
> + } while (errStatus < 0 && errno == EINTR);
>
>if (semop(semId, &sops, 1) < 0)
> return -1;
>
> But:
> (1) The EINTR problem happens rather rare, so testing it is difficult;
> (2) I would rather not doing the above changes before we understand what's
> happened here, especially when we have seen a EAGAIN reported here.
OK, so how do we find the answer?
--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2291: int2vectorrecv() and oidvectorrecv() are wrong (SIGBUS)
The following bug has been logged online: Bug reference: 2291 Logged by: Tim Kordas Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: All Description:int2vectorrecv() and oidvectorrecv() are wrong (SIGBUS) Details: During Greenplum's ongoing effort to expand support for postgres datatypes in Bizgres-MPP; we discovered some issues with int2vectorrecv() and oidvectorrecv(). int2vectorrecv() and oidvectorrecv() both use DirectFunctionCall3 to call array_recv(). DirectFunctionCall3() leaves fcinfo->flinfo NULL. array_recv() uses fcinfo->flinfo. Calling array_recv() without a valid fcinfo->flinfo results in SIGBUS. It would be easy to modify array_recv(), but is probably better to fix the code in int2vectorrecv()/oidvectorrecv() by replacing the call to DirectFunctionCall3() with direct forwarded call (similar to int2vectorsend()): /* leave arg[0] alone, it is correct */ fcinfo->arg[1] = ObjectIdGetDatum(INT2OID); fcinfo->arg[2] = Int32GetDatum(-1); result = (int2vector *)array_recv(fcinfo); the flinfo->f_extra field used will be that passed in by array_recv()'s caller. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] FATAL: semctl(1672698088, 12, SETVAL, 0) failed
"Bruce Momjian" wrote
> > In port/win32.h, we have
> >
> > #undef EAGAIN
> > #undef EINTR
> > #define EINTR WSAEINTR
> > #define EAGAIN WSAEWOULDBLOCK
> >
> > What's the rationale of doing so?
>
> We did this so that our code could refer to EINTR/EAGAIN without
> port-specific tests.
>
AFAICS, by doing so, the EINTR/EAGAIN will be translated into
WSAINTR/WSAEWOULDBLOCK through *all* the backend code. That's seems not
appropriate for the code not involving any socket stuff ... I think we need
a fix here.
> > (2) What's happened here?
> > It may come from PGSemaphoreReset(), and win32 semop() looks like this:
> >
> > ret = WaitForMultipleObjectsEx(2, wh, FALSE, (sops[0].sem_flg &
> > IPC_NOWAIT) ? 0 : INFINITE, TRUE);
> > ...
> > else if (ret == WAIT_OBJECT_0 + 1 || ret == WAIT_IO_COMPLETION)
> > {
> >pgwin32_dispatch_queued_signals();
> >errno = EINTR;
> > }
> > else if (ret == WAIT_TIMEOUT)
> >errno = EAGAIN;
> >
> > So it seems the EINTR is caused by an incoming signal, the EAGAIN is
caused
> > by a TIMEOUT ... any ideas?
>
> I looked at the documentation for the function:
>
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/waitformultipleobjectsex.asp
>
> and it isn't clear what return failure values it has. We certainly
> could loop on WSAEINTR. Can you test it?
>
Yeah, looking at other code of using semop(), we could plug in a loop in the
win32 semctl():
/* Quickly lock/unlock the semaphore (if we can) */
+ do
+ {
+errStatus = semop(semId, &sops, 1);
+ } while (errStatus < 0 && errno == EINTR);
if (semop(semId, &sops, 1) < 0)
return -1;
But:
(1) The EINTR problem happens rather rare, so testing it is difficult;
(2) I would rather not doing the above changes before we understand what's
happened here, especially when we have seen a EAGAIN reported here.
Regards,
Qingqing
---(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
Re: [BUGS] FATAL: semctl(1672698088, 12, SETVAL, 0) failed
Qingqing Zhou wrote:
> I encountered an error when I fast shutdown 8.1.1 on Win2k:
>
> FATAL: semctl(1672698088, 12, SETVAL, 0) failed: A blocking operation
> was interrupted by a call to WSACancelBlockingCall.
>
> A similar error on 8.1/win2003 was reported on pgsql-general (sorry, I can't
> dig out the
> original post from our web archives):
>
> From: Niederland
> Date: Tues, Dec 13 2005 9:49 am
>
> 2005-12-12 20:30:00 FATAL: semctl(50884184, 15, SETVAL, 0) failed: A
> non-blocking socket operation could not be completed immediately.
>
> ---
>
> There are two problems here:
>
> (1) Why a socket error?
> In port/win32.h, we have
>
> #undef EAGAIN
> #undef EINTR
> #define EINTR WSAEINTR
> #define EAGAIN WSAEWOULDBLOCK
>
> What's the rationale of doing so?
We did this so that our code could refer to EINTR/EAGAIN without
port-specific tests.
> (2) What's happened here?
> It may come from PGSemaphoreReset(), and win32 semop() looks like this:
>
> ret = WaitForMultipleObjectsEx(2, wh, FALSE, (sops[0].sem_flg &
> IPC_NOWAIT) ? 0 : INFINITE, TRUE);
> ...
> else if (ret == WAIT_OBJECT_0 + 1 || ret == WAIT_IO_COMPLETION)
> {
>pgwin32_dispatch_queued_signals();
>errno = EINTR;
> }
> else if (ret == WAIT_TIMEOUT)
>errno = EAGAIN;
>
> So it seems the EINTR is caused by an incoming signal, the EAGAIN is caused
> by a TIMEOUT ... any ideas?
I looked at the documentation for the function:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/waitformultipleobjectsex.asp
and it isn't clear what return failure values it has. We certainly
could loop on WSAEINTR. Can you test it?
--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2290: Incorrect sequence increment after backup/restore
"Oleg Mamontov" <[EMAIL PROTECTED]> writes:
> If after CREATE TABLE with SERIAL column i'll change sequence increment to 2
> or some other value (with ALTER SEQUENCE) then always work correctly (all
> inserted rows will have values incremented by 2).
We currently consider that a serial column is a "black box" and you
should not mess with its underlying sequence directly. If you want
nondefault properties for the sequence, create it as an independent
sequence object and then just declare the column as "integer
default nextval('seq')".
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
Re: [BUGS] BUG #2289: insert into tables not working
On Tue, Feb 28, 2006 at 09:24:35AM +, Abhilash Krishnan wrote: > I am having an application using java, jsp, struts and hibernate with a > backend of postgresql. Here, during some operations, although the insert > query is generated by hibernate and can be seen in the console, the data is > not getting inserted into the database. Any idea why it happens ? Did you commit the transaction that performed the insert? The effects of a transaction's operations aren't visible to other transactions until the transaction commits. Also, if a transaction encounters an error its operations will be rolled back unless you protect them with savepoints. -- Michael Fuhr ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #2290: Incorrect sequence increment after backup/restore
The following bug has been logged online: Bug reference: 2290 Logged by: Oleg Mamontov Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.x/8.1.x Operating system: FreeBSD 4.x,5.x,6.x Description:Incorrect sequence increment after backup/restore Details: If after CREATE TABLE with SERIAL column i'll change sequence increment to 2 or some other value (with ALTER SEQUENCE) then always work correctly (all inserted rows will have values incremented by 2). But after database backup/restore (with pg_dump) this ALTER will not restored and all next inserted rows will have values incremented by 1 (default for SERIAL data type). It's seems like a bug... Changing increment value often used with replication (master database inserts has odd values and slave database inserts has even) and other situations. Sorry for my poor English. ---(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
Re: [BUGS] BUG #2286: Wrong index creation with cs_CZ locales and
No, the database was initialized new. initdb -D /var/lib/pg-8.1.3 -E latin2 I have isolated problem to new locale definition file - glibc 2.3.6 with cs_CZ definition file from 2.3.2 works ok and raises if data contain '-'. I'am still not sure if problem is in postgres (bad work with locale data) or in glibc locale data itself, older postgres than 8.1.2 still not tried. Thanks, On Mon, 27 Feb 2006 12:24:19 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: > "David Sauer" <[EMAIL PROTECTED]> writes: > > PostgreSQL version: 8.1.2, 8.1.3 > > Operating system: Linux (libc6), debian > > Description:Wrong index creation with cs_CZ locales and HYPHEN > > You've probably gotten bit by the 8.1.2 changes in locale-dependent > sorting. Try REINDEXing the affected indexes, as per the 8.1.2 release > notes. > > regards, tom lane -- David Šauer <[EMAIL PROTECTED]> www.videoplaneta.cz člen internetového nákupního centra www.123shop.cz navštivte naše obchody: www.123mp3.cz www.fotoplaneta.cz a další ... ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #2288: bad value for type timestamp using JDBC Type2 Driver version 8.1-405
The following bug has been logged online:
Bug reference: 2288
Logged by: Jonathan Albert C. Vallar
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.3
Operating system: Centronix Linux
Description:bad value for type timestamp using JDBC Type2 Driver
version 8.1-405
Details:
My program reports "bad value for type timestamp" when I am accessing a
table with a field that is defined of type "Timestamp" through a java
program that uses the JDBC of postgres. The JDBC Driver is a type2 driver
with version, 8.1-405.
Below is the stack trace of the error:
Retrieve Operation failed on the BusinessObject Bad value for type timestamp
: [EMAIL PROTECTED] Exception: java.lang.NumberFormatException: Expected time
to
be colon-separated, got ' Stack Trace: java.lang.NumberFormatException:
Expected time to be colon-separated, got ' at
org.postgresql.jdbc2.TimestampUtils.loadCalendar(TimestampUtils.java:151)
at org.postgresql.jdbc2.TimestampUtils.toTimestamp(TimestampUtils.java:307)
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getTimestamp(AbstractJdbc2Result
Set.java:419) at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getTimestamp(AbstractJdbc2Result
Set.java:2088) at
com.crossworlds.connectors.JDBC.JDBCBOhandler.doContainerRetrieve(JDBCBOhand
ler.java:3697) at
com.crossworlds.connectors.JDBC.JDBCBOhandler.doRecursiveRetrieve(JDBCBOhand
ler.java:3316) at
com.crossworlds.connectors.JDBC.JDBCBOhandler.doRetrieve(JDBCBOhandler.java:
3265) at
com.crossworlds.connectors.JDBC.JDBCBOhandler.doVerbFor(JDBCBOhandler.java:1
346) at
com.crossworlds.cwconnectorapi.CWConnectorBOHandler.doVerbFor(CWConnectorBOH
andler.java:127) at
CxCommon.BusinessObject.doVerbFor(BusinessObject.java:2128) at
com.crossworlds.cwconnectorapi.CWConnectorBusObj.doVerbFor(CWConnectorBusObj
.java:126) at
com.crossworlds.connectors.JDBC.JDBCConnectorAgent.pollForEvents(JDBCConnect
orAgent.java:1137) at
AppSide_Connector.BusObjJavaInterface.poll(BusObjJavaInterface.java:355)
at AppSide_Connector.AppCalls.poll(AppCalls.java:191) at
AppSide_Connector.AgentBusinessObjectManager.poll(AgentBusinessObjectManager
.java:719) at AppSide_Connector.AppPolling.poll(AppPolling.java:294) at
AppSide_Connector.AppPolling.doPollingContinuousWait(AppPolling.java:556)
at AppSide_Connector.AppPolling.run(AppPolling.java:121) at
java.lang.Thread.run(Thread.java:513) End of Stack Trace SQLException
{2}]
The Schema of the table is:
(1 row)
wbi_db=> \d xworlds_events;
Table "public.xworlds_events"
Column |Type | Modifiers
+-+---
event_id | bigint | not null
connector_id | character varying(40) |
object_key | character varying(80) | not null
object_name| character varying(40) | not null
object_verb| character varying(40) | not null
event_priority | real| not null
event_time | timestamp without time zone |
event_status | integer |
event_comment | character varying |
I have one record:
wbi_db=> select * from xworlds_events;
event_id | connector_id | object_key | object_name | object_verb |
event_priority |event_time | event_status | event_comment
--+--++--+-+
+---+--+---
1 | PostgreSQL | 81 | POS_to_SAP_1_WRAPPER | Create |
1 | 2006-02-27 19:51:22.58118 |0 | Test
(1 row)
Is there a problem with the JDBC Driver? Specifically in the method
loadDriver?
Thanks in advance :)
Best Regards,
Jonathan
---(end of broadcast)---
TIP 6: explain analyze is your friend
[BUGS] BUG #2289: insert into tables not working
The following bug has been logged online: Bug reference: 2289 Logged by: Abhilash Krishnan Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.2 Operating system: windows 2000 Description:insert into tables not working Details: I am having an application using java, jsp, struts and hibernate with a backend of postgresql. Here, during some operations, although the insert query is generated by hibernate and can be seen in the console, the data is not getting inserted into the database. Any idea why it happens ? ---(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
