On Fri, Dec 3, 2010 at 4:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Even if you're willing to
assume that the dictionary being used is the one defined by this
module, that dictionary depends on external configuration files
which are easily changeable.
Don't we have precedent for this in
Hi Alexia-san.
About it, I was not able to do the support as which various problems are
sufficient.
However, It tried hard in order to offer the comfortable environment in windows.
http://www.ossp.org/pkg/lib/uuid/
I have not done putting in the last patch there yet. sorry...
Greg Stark gsst...@mit.edu writes:
On Fri, Dec 3, 2010 at 4:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Even if you're willing to
assume that the dictionary being used is the one defined by this
module, that dictionary depends on external configuration files
which are easily changeable.
Don't
Hello,
I'm running into a problem with truncate causing my test application to
fail. I've noticed some similar
problems posted but noting that quite lines up with what I'm seeing.
I have a partitioned table. Storing m records per partition, where I use a
sequence table
to keep track of the over
tmoore wrote:
Running this test, a deadlock can be created without fail.
You haven't shown any evidence of a deadlock -- just blocking.
That's not at all the same thing.
postgres 16990 26837 44 11:20 ? 00:28:51 postgres: postgres uisdb
127.0.0.1(34405) idle in transaction
postgres
Can I ask you to elaborate on one of your comments before I move to the
general thread ?
You mention committing the 'idle thread'. The test is not doing
any transaction based work, the write functions just do sql insert, no begin
commit blocks at the application level.
Any tips on
tmoore wrote:
The test is not doing any transaction based work, the write
functions just do sql insert, no begin commit blocks at the
application level.
Well something is starting transactions; otherwise you wouldn't have
a transaction sitting idle in transaction. Are you perhaps
Thanks for the link.
Yes, the test is java with autocommit false, on the localhost is involved.
To clarify the no blocking comment, let me describe the test again.
Three threads of executions, java writer, java reader, and psql via
cron for truncation. As an experiment, the java reader was
I'm a little tired. I just indicated autocommit false, that was incorrect.
Autocommit is true.
Sorry.
Thanks again for the comment.s
Tom
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/TRUNCATE-HANGS-tp3292333p3292468.html
Sent from the PostgreSQL - bugs mailing list
tmoore wrote:
I'm a little tired. I just indicated autocommit false, that was
incorrect. Autocommit is true.
I would double-check that. As I said, what you showed us indicates
that something logging in through TCP on localhost is using
transactions, and not committing them when needed.
The following bug has been logged online:
Bug reference: 5783
Logged by: Adrian Klaver
Email address: adrian.kla...@gmail.com
PostgreSQL version: 9.0.1
Operating system: Linux Ubuntu 10.04
Description:plpythonu bool behavior change
Details:
Seems there was a change
The following bug has been logged online:
Bug reference: 5784
Logged by: Martin Atukunda
Email address: matl...@gmail.com
PostgreSQL version: 8.4
Operating system: Linux
Description:CREATE INDEX USING GIN complains about array containing
null values yet none exist
12 matches
Mail list logo
