On 30.03.2011 21:06, Jon Nelson wrote:
The short version is that if a postgresql backend is killed (by the Linux
OOM handler, or kill -9, etc...) while operations are
taking place in a *different* backend, corruption is introduced in the other
backend. I don't want to say it happens 100% of the
On Thu, Mar 31, 2011 at 2:58 AM, Heikki Linnakangas
wrote:
> On 30.03.2011 21:06, Jon Nelson wrote:
>>
>> The short version is that if a postgresql backend is killed (by the Linux
>> OOM handler, or kill -9, etc...) while operations are
>> taking place in a *different* backend, corruption is intro
The following bug has been logged online:
Bug reference: 5961
Logged by: Martin Handsteiner
Email address: martin.handstei...@sibvisions.com
PostgreSQL version: 9.0 Build 801
Operating system: All Operating Systems
Description:JDBC Driver acceptURL does not check 'jdb
I figured out the reason.
I had installed ZendStudio 8.0 in the directory /usr/local for experimental
things.
The ZendStudio runs fine, but since this time I got always mysterious
messages after closing vi. Vi could not find a python library.
So I deleted (rm -rf ...) all this stuff.
Now my vi w
On Thu, 31 Mar 2011, Martin Handsteiner wrote:
The following bug has been logged online:
Bug reference: 5961
PostgreSQL version: 9.0 Build 801
Description:JDBC Driver acceptURL does not check 'jdbc:postgresql:'
Details:
JDBC Driver acceptURL does not check 'jdbc:postgresql:'
On Wed, Mar 30, 2011 at 7:32 PM, Lawrence Cohan wrote:
> Please see updated attachment that includes the tables involved in the simple
> query below and all their indexes. We believe that the performance issue is
> due to the query not using any index but doing seq scans instead and this is
> v
On 3/31/2011 8:50 AM, DI Martin Handsteiner wrote:
thank you very much for your fast response.
The problem with the current implementation of acceptsURL in the the
postgres driver is, that it also returns true if the connection url is like:
jdbc:oraclethin:..
jdbc:hsqldb:..
That is t
Greg Stark wrote:
> your query does require reading all the data.
Huh? It requires reading all the data from at least *one* of the
tables. I could conceivably be faster to read all the data from the
table with 23,980 rows and randomly pick out the necessary 33,768
rows from the table with 33
On Thu, Mar 31, 2011 at 11:33 PM, Kevin Grittner
wrote:
> Greg Stark wrote:
>
>> your query does require reading all the data.
>
> Huh? It requires reading all the data from at least *one* of the
> tables.
The query he posted a plan for was:
EXPLAIN ANALYZE select oi.id from order_items oi inn
On 22/03/2011 2:34 PM, Vincent Chan wrote:
The following bug has been logged online:
Bug reference: 5939
Logged by: Vincent Chan
Email address: joy717@gmail.com
PostgreSQL version: 9.0
Operating system: Win7 x64
Description:About bytea
Details:
when saving a by
10 matches
Mail list logo