Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > The problem is that session 2 sees a not yet deleted( by session 1)
> > session row and an already updated( by session 1) sis_user row at
> > the same time. There's no such snapshot that could see both rows.
>
> Running in SERIAL
With only a minor slap on the wrist, we now officially own port #5432.
regards, tom lane
--- Forwarded Message
Date:Wed, 14 Nov 2001 13:31:18 -0800
From:"IANA" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: RE: Application for port-number (5432)
D
"Alexei Barantsev" <[EMAIL PROTECTED]> writes:
> UPDATE buggy SET field1 = field1+1;
> psql:/home/barancev/tmp/pg_bug.sql:17: ERROR: Cannot insert a duplicate key
> into unique index buggy_field1_key
Unfortunately, that's never worked, as our unique constraints are tested
immediately not at end
>On page xv (antepenultimate line), "Gnu Project" should be "GNU
>Project".
Fixed. Thanks.
>On page 78, the "Release date" is listed as "2001-??-??".
This is a tough one. We generate the docs before we know the date of
final release. Does anyone have a suggestion on how to fix th
I am not a PostgreSQL user, just an editor who has looked over some
of your printable documentation. I found some problems and thought
you'd like to know about them...
-r
PostreSQL 7.1 Administrator's Guide
On page iii (2nd line), something is printing as a square (?).
On page xv (ante
Hi!
I have found that some of my queries stop working after upgrade from 7.0 to
7.1.3.
Some investigation show that UPDATE queries grow to crash.
Here is my SQL code that produces error (it is supposed to be in pg_bug.sql
file):
--
\connect template1 postgres
CREATE DATABASE "pg_bug
[EMAIL PROTECTED] writes:
> Now we have "sameuser=r" !
This appears to be fixed in 7.2.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister Y
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> The problem is that session 2 sees a not yet deleted( by session 1)
> session row and an already updated( by session 1) sis_user row at
> the same time. There's no such snapshot that could see both rows.
Running in SERIALIZABLE mode would guarantee co
vic ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
REVOKE delete set select grant to user
Long Description
create table a;
grant select on a to public;
revoke delete on a from sameuser;
Now we have "sameuser=r" !
Sample Code
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > What I meant is
> > Session 2 invokes the session_del rule and really
> > updates a sis_user row by the rule though it deletes
> > no session row.
>
> Hmmm ... that's a
10 matches
Mail list logo
