recurred through deadlock.
client1:
create table test(a int);
create index id on test using hash(a);
insert into test values(1);
insert into test values(2);
set enable_seqscan=off;
begin;
update test set a=a+1 where a=1;
client2:
set enable_seqscan=off;
begin;
update test set a=a+1 wher
The following bug has been logged online:
Bug reference: 4018
Logged by:
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.6
Operating system: Windows XP Professional Service Pack 2
Description:Installation failure
Details:
The installer for PostgreSQL 8.2.6
The following bug has been logged online:
Bug reference: 4019
Logged by: Jan Strube
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: openSUSE Linux 10.2
Description:Comparison of user defined domain doesn't work
Details:
Hi,
I think when c
ykhuang wrote:
recurred through deadlock.
client1:
create table test(a int);
create index id on test using hash(a);
insert into test values(1);
insert into test values(2);
set enable_seqscan=off;
begin;
update test set a=a+1 where a=1;
client2:
set enable_seqscan=off;
begin;
update te
"Jan Strube" <[EMAIL PROTECTED]> writes:
> Description:Comparison of user defined domain doesn't work
I can't reproduce this here --- the test case gives the expected output
on both 8.2 and 8.3. (I'm checking CVS tip not the 8.3.0 release, but
there surely haven't been any bug fixes that
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I can reproduce this, with --enable-cassert. It crashes when aborting
> the transaction, in ReleaseResources_hash. The HashScanList items are
> allocated in ExecutorState memory context, but that context has already
> been deleted by the time we
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
I can reproduce this, with --enable-cassert. It crashes when aborting
the transaction, in ReleaseResources_hash. The HashScanList items are
allocated in ExecutorState memory context, but that context has already
been deleted by t
Version: 8.3
Platform: Windows
Installation: Clicked the pl/java checkbox on installation
Postgresql.conf changes
custom_variable_classes = 'pljava'
pljava.classpath='C:\\Program
Files\\PostgreSQL\\8.3\\share\\pljava.jar'
OS Path: I added C:\Program Files\Java\jdk1.6.0_02\jre\bin\client a
I wrote:
> Ouch. So this has been broken (by me, I think :-() since 8.0. Tells
> you something about how many people use hash indexes :-(
Actually it's not that bad --- this particular test case doesn't crash
in 8.0 or 8.1. I'm guessing we rearranged the order of transaction
abort processing in
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Ouch. So this has been broken (by me, I think :-() since 8.0. Tells
>> you something about how many people use hash indexes :-(
> Yeah. Also, this is very hard to trigger without --enable-cassert (or
> just CLOBBER_FREED_MEMO
On Fri, 7 Mar 2008, Tom Lane wrote:
> "Jan Strube" <[EMAIL PROTECTED]> writes:
> > Description:Comparison of user defined domain doesn't work
>
> I can't reproduce this here --- the test case gives the expected output
> on both 8.2 and 8.3. (I'm checking CVS tip not the 8.3.0 release, bu
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Fri, 7 Mar 2008, Tom Lane wrote:
>> "Jan Strube" <[EMAIL PROTECTED]> writes:
Description:Comparison of user defined domain doesn't work
>>
>> I can't reproduce this here --- the test case gives the expected output
>> on both 8.2 and 8.3.
Added to TODO:
* Add a function like pg_get_indexdef() that report more detailed index
information
http://archives.postgresql.org/pgsql-bugs/2007-12/msg00166.php
---
Dave Page wrote:
> Tom Lane wrote:
> >> We use the
I wrote:
> Anyway, it seems that we cannot raise the minimum value of
> shared_buffers to 200, or even 100, unless we are prepared to blow off
> SHMMAX = 2MB or do something about the fixed SLRU allocation.
After further thought I propose that we just eliminate the interlock
between -N and -B. I
The following bug has been logged online:
Bug reference: 4020
Logged by: Joseph S
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: CentOS 5
Description:RFE: have way to log autovacuum activity
Details:
When autovacuum decides to vacuum on
Joseph S wrote:
> When autovacuum decides to vacuum one of our large tables, the whole site
> slows down, but it is not always obvious why. It would be nice if there was
> an option to log autovacuum activity so I know how often a vacuum runs and
> how long it takes.
Yeah, we have a configurable
16 matches
Mail list logo
