Introduction
I wrote small java program which performs some selects in
one transaction (and thread) and one delete in another transaction and
thread on the same table holding one record initially.
ENVIRONMENT
OS:
Centos 5.5 kernel 2.6.18-194.32.1.el5
Postgresql: 9.0.4
jdbc driver:
9.0-801 JDBC
Jan Snelders wrote:
> I wrote small java program which performs some selects in one
> transaction (and thread) and one delete in another transaction and
> thread on the same table holding one record initially.
> The DELETE transaction commits.
> The program now selects and
> prints the record
On 30/08/2011 9:18 PM, Jan Snelders wrote:
The program now selects and prints the records from the SELECT
transaction. (0 records printed, we expected one record since we are
still within the SELECT transaction which started while this record was
still available)
This isn't a bug. You're using
The following bug has been logged online:
Bug reference: 6184
Logged by: Ding Yuan
Email address: ding.yuan...@hotmail.com
PostgreSQL version: 8.4.8
Operating system: All
Description:Inconsistencies in log messages
Details:
Hi Postgres developers,
(I reported this a
The following bug has been logged online:
Bug reference: 6185
Logged by: Isaac Jurado
Email address: ijur...@econcept.es
PostgreSQL version: 8.4.8
Operating system: Ubuntu 10.04.03 LTS (x86_64)
Description:Segmentation fault with NULL string columns
Details:
Here's
On 30.08.2011 11:51, Isaac Jurado wrote:
The following bug has been logged online:
Bug reference: 6185
Logged by: Isaac Jurado
Email address: ijur...@econcept.es
PostgreSQL version: 8.4.8
Operating system: Ubuntu 10.04.03 LTS (x86_64)
Description:Segmentation fault
Excerpts from Isaac Jurado's message of mar ago 30 05:51:55 -0300 2011:
>
> The following bug has been logged online:
>
> Bug reference: 6185
> Logged by: Isaac Jurado
> Email address: ijur...@econcept.es
> PostgreSQL version: 8.4.8
> Operating system: Ubuntu 10.04.03 LTS (x8
The following bug has been logged online:
Bug reference: 6186
Logged by: Lampa
Email address: lamp...@gmail.com
PostgreSQL version: 9.0.4/8.4.8
Operating system: Linux Debian testing 32bit
Description:out of memory while analyze
Details:
Trying analyze table (ANALYZ
The following bug has been logged online:
Bug reference: 6187
Logged by: Bhavesh Dangi
Email address: dangi.bhaves...@gmail.com
PostgreSQL version: PostgreSQL8.0.1
Operating system: i686-pc-linux-gnu
Description:Select query stuck
Details:
Hello,
Here the problem i
On 30.08.2011 14:28, Bhavesh Dangi wrote:
PostgreSQL version: PostgreSQL8.0.1
That version is over 6 years old. PostgreSQL 8.0 major version is no
longer supported, see
http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy. Even
if it was, the latest (and last) minor release from
On 30.08.2011 14:20, Lampa wrote:
Trying analyze table (ANALYZE TABLE table or VACUUM ANALYZE table) with
3051316 rows (displayed size 2521MB in \dt+)
Log:
...
Analyze: 2236767256 total in 279 blocks; 18080 free (423 chunks);
2236749176 used
> ...
Hmm, that looks like a memory like in A
"Lampa" writes:
> Trying analyze table (ANALYZE TABLE table or VACUUM ANALYZE table) with
> 3051316 rows (displayed size 2521MB in \dt+)
What have you got maintenance_work_mem set to? shared_buffers might
also be interesting.
regards, tom lane
--
Sent via pgsql-bugs ma
On Tue, Aug 30, 2011 at 8:21 PM, Heikki Linnakangas
wrote:
>
> to_ascii_encname is marked as STRICT, which means that it returns NULL
> on NULL input, without ever calling the underlying C function. The
> "to_ascii" function that you created is not marked as STRICT, so the
> to_ascii_encname C fun
On Tue, Aug 30, 2011 at 8:22 PM, Alvaro Herrera
wrote:
>
> Seems you neglected to mark the function STRICT.
Yes, that was it. Sorry for the invalid bug report.
Best regards.
--
Isaac Jurado
Internet Busines Solutions eConcept
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
T
Hello,
table design http://pastebin.com/RW6vLAVP
And configuration:
ssl = false
shared_buffers = 900MB # min 128kB
work_mem = 100MB# min 64kB
maintenance_work_mem = 524MB# min 1MB
fsync = off # turns forced
On 08/30/11 10:25 PM, Lampa wrote:
Also tried change maintenance_work_mem to 2G and same result.
Imposible to set over 2GB (FATAL: 3145728 is outside the valid range
for parameter "maintenance_work_mem" (1024 .. 2097151))
is this a 32bit postgres ?
--
john r pierce
16 matches
Mail list logo