On 07.01.2011 08:42, yulei wrote:
The following bug has been logged online:
Bug reference: 5818
Logged by: yulei
Email address: yu...@hotmail.com
PostgreSQL version: 9.0.2
Operating system: Windows XP Service Pack 3
Description:initdb lose the single quote of locale
On Wed, Apr 06, 2011 at 11:17:42PM +, Ricardo Solanilla wrote:
> -- try this
>
> select (extract(epoch from (date('2011-03-20'))) - extract(epoch from
> (date('2011-03-19' / 3600
>
> -- it must be 24 (hours), only occurs in march 19,2011
> -- in v. 8.0 work fine!!
Are you sure this isn't
The following bug has been logged online:
Bug reference: 5988
Logged by: Marko Tiikkaja
Email address: marko.tiikk...@2ndquadrant.com
PostgreSQL version: git master
Operating system: Linux
Description:CTINE duplicates constraints
Details:
CREATE TABLE IF NOT EXISTS
Dewin writes:
>> But if that theory is correct, this isn't a new
>> problem in 9.1, it goes back to 8.3. Have you been running this script
>> successfully on older versions?
> On 9.0.
Thanks. On reflection I concluded that this is a new bug in 9.1 --- or
at least, this manifestation is new in
The following bug has been logged online:
Bug reference: 5989
Logged by: Marko Tiikkaja
Email address: marko.tiikk...@2ndquadrant.com
PostgreSQL version: git master
Operating system: Linux
Description:Assertion failure on UPDATE of big value
Details:
Test case:
=#
"Marko Tiikkaja" writes:
> =# create table foo(a int[]);
> CREATE TABLE
> =# insert into foo select array(select i from generate_series(1,1) i);
> INSERT 0 1
> =# update foo set a = a||1;
> TRAP: FailedAssertion("!(((bool) (((void*)(&(newTuple->t_self)) != ((void
> *)0)) && ((&(newTuple->t_
On 20.04.2011 17:26, Tom Lane wrote:
"Marko Tiikkaja" writes:
=# create table foo(a int[]);
CREATE TABLE
=# insert into foo select array(select i from generate_series(1,1) i);
INSERT 0 1
=# update foo set a = a||1;
TRAP: FailedAssertion("!(((bool) (((void*)(&(newTuple->t_self)) !=
Heikki Linnakangas writes:
> On 20.04.2011 17:26, Tom Lane wrote:
>> Why is predicate.c getting called at all when transaction_isolation is
>> not SERIALIZABLE? (Although the same crash happens when it is ...)
> Because another serializable transaction that reads/updates the tuple
> later needs
On 20.04.2011 17:51, Tom Lane wrote:
Heikki Linnakangas writes:
On 20.04.2011 17:26, Tom Lane wrote:
Why is predicate.c getting called at all when transaction_isolation is
not SERIALIZABLE? (Although the same crash happens when it is ...)
Because another serializable transaction that reads
On 20.04.2011 17:51, Tom Lane wrote:
... which means that the first transaction is completed and
can no longer be holding any locks.
Predicate locks are held after transaction commit. They can only be
cleaned once the xid is older than the oldest xmin among all active
serializable transaction
"Marko Tiikkaja" wrote:
> TRAP: FailedAssertion("!(((bool) (((void*)(&(newTuple->t_self)) !=
> ((void *)0)) && ((&(newTuple->t_self))->ip_posid != 0", File:
> "predicate.c", Line: 2282)
Am investigating, and have alerted Dan, in case he hasn't noticed
this thread.
-Kevin
--
Sent via pg
Heikki Linnakangas writes:
> There's *three* transactions here. The first one is serializable, and
> reads the tuple. The second one is not serializable, and updates it. The
> third one is serializable and updates it again.
> The second transaction needs to copy the predicate lock held by the
On 20.04.2011 18:08, Kevin Grittner wrote:
"Marko Tiikkaja" wrote:
TRAP: FailedAssertion("!(((bool) (((void*)(&(newTuple->t_self)) !=
((void *)0))&& ((&(newTuple->t_self))->ip_posid != 0", File:
"predicate.c", Line: 2282)
Am investigating, and have alerted Dan, in case he hasn't noticed
Heikki Linnakangas writes:
> The immediate fix is trivial:
> --- a/src/backend/access/heap/heapam.c
> +++ b/src/backend/access/heap/heapam.c
> @@ -2859,7 +2859,7 @@ l2:
> * Any existing SIREAD locks on the old tuple must be linked to
> the new
> * tuple for conflict detection
Heikki Linnakangas wrote:
> On 20.04.2011 17:26, Tom Lane wrote:
>> Why is predicate.c getting called at all when
>> transaction_isolation is not SERIALIZABLE? (Although the same
>> crash happens when it is ...)
>
> Because another serializable transaction that reads/updates the
> tuple later
Heikki Linnakangas wrote:
> But the question Tom raised about doing this even for
> non-serializable transactions is more serious..
This particular call from heapam.c went in much later than most of
the code, since we had trouble proving that anything needed to be
done there in the first place
Tom Lane wrote:
> Egad. If that's it, my confidence in the amount of testing SSI
> has gotten has just dropped dramatically.
If I'm reading this correctly, it would appear that nobody has
updated anything to a TOASTed value in a build against HEAD in
testing *anything* in the last two and a h
"Kevin Grittner" writes:
> If I'm reading this correctly, it would appear that nobody has
> updated anything to a TOASTed value in a build against HEAD in
> testing *anything* in the last two and a half months. And the
> regression tests don't include a single UPDATE to a TOASTed value
> anywhere
Tom Lane wrote:
> Hmm, is there much regression coverage for TOAST inserts or
> deletes either?
I'll check.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Tom Lane wrote:
> "Kevin Grittner" writes:
>> If I'm reading this correctly, it would appear that nobody has
>> updated anything to a TOASTed value in a build against HEAD in
>> testing *anything* in the last two and a half months. And the
>> regression tests don't include a single UPDATE to a T
The following bug has been logged online:
Bug reference: 5990
Logged by: Allen Sooredoo
Email address: allen_soore...@carrefour.com
PostgreSQL version: 8.4
Operating system: Windows Server 2003
Description:100% CPU reached
Details:
Hi,
we are facing a performance is
The following bug has been logged online:
Bug reference: 5991
Logged by: Kananda Silveira
Email address: kanandasilva...@hotmail.com
PostgreSQL version: 9.0.3-1-windows
Operating system: Windows 7
Description:Bug restore .backup
Details:
Recently, I change postgreSQ
"Allen Sooredoo" wrote:
> we are facing a performance issue on Postgres 8.4, the CPU reaches
> 100% with less than 50 simultaneous users.
>
> We were thinking to migrate the HR system from Oracle to Postgres
> but now that we have those big performance problems on relatively
> small application
On 20.04.2011 22:22, Kananda Silveira wrote:
The following bug has been logged online:
Bug reference: 5991
Logged by: Kananda Silveira
Email address: kanandasilva...@hotmail.com
PostgreSQL version: 9.0.3-1-windows
Operating system: Windows 7
Description:Bug restore
Heikki Linnakangas wrote:
> The immediate fix is trivial:
>
> [patch changing one line of code]
I have confirmed that without this patch the new regression tests I
have proposed will fail, and with the patch they succeed. I have
also confirmed that the isolation test suite continues to succe
I wrote:
> "Daniel Grace" writes:
>> One such file (contents listed below, admittably not 100% useful without a
>> full schema and data) makes a bunch of alterations to a table but fails when
>> it reaches CLUSTER:
>> psql:D:/SVN/wings/wings/branches/devpg/db/lib/course.sql:38: ERROR: index
>> 1
"Marko Tiikkaja" writes:
> CREATE TABLE IF NOT EXISTS duplicates some constraints if the new table
> isn't created:
What this means is that the feature was implemented in the wrong place,
ie the short-circuit is after rather than before parse_utilcmds.c splits
up the CREATE TABLE command into mul
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> > Could you please provide us some support regarding this issue?
[...]
> Please read this and post to the pgsql-performance list:
>
> http://wiki.postgresql.org/wiki/SlowQueryQuestions
If that looks like a lot of complication/effort, let's
28 matches
Mail list logo
