Ok, thanks, roger you.
But one question still cause my misunderstanding:
> > 2. If i create trigger FOR EACH STATEMENT, it will work ok for
> > insert, update and delete.
>
> You mean FOR EACH ROW, no?
Yes, confused. FOR EACH ROW.
"FOR EACH ROW"-trigger successfully fires in inherited
table "xte
Also another bug and usecase connected with subj.
It creates parent table "xtest", inherited table "xtest_inh" with
some data, and a trigger BEFORE INSERT/UPDATE/DELETE on table "xtest".
After, it deletes one row.
**
CREATE TABLE xtest (id serial, data varchar, prim
Version: postgresql 9.0.1
Step to reproduce: use following code. It creates two tables (parent
"xtest" and inherited "xtest_inh"), creates trigger function, creates
BEFORE INSERT/UPDATE/DELETE trigger.
*
CREATE TABLE xtest (id serial, data varchar, primary key(i
The following bug has been logged online:
Bug reference: 5552
Logged by: Konstantin Kulikov
Email address: k.e.kuli...@gmail.com
PostgreSQL version: 8.3
Operating system: unix
Description:incorrect returned value of time
Details:
select current_timestamp at time
* Tom Lane [Thu, 12 Feb 2009 19:10:34 -0500]:
[ shrug... ] The "implementation artifact" is that you didn't get a
deadlock *earlier*.
I agree that such behavior is more plain rather than current.
You can't expect to update referenced rows and
referencing rows in the same transaction and not
* Heikki Linnakangas [Thu, 12 Feb
2009 19:34:46 +0200]:
It's certainly not ideal. It's an implementation artifact of the way
MVCC and RI triggers work. The purpose is to protect from this
potential
bug:
As I can see you are agree with problem existence and problem will not
be solved soo
* Tom Lane [Thu, 12 Feb 2009 10:54:34 -0500]:
Heikki Linnakangas writes:
> Hmm, the first UPDATE should've blocked already. It should've fired
a
RI
> trigger to lock the parent tuple in shared mode, but it looks like
> that's not happening for some reason.
Read the special code in AfterTrig
* Heikki Linnakangas [Thu, 12 Feb
2009 13:54:11 +0200]:
Hmm, the first UPDATE should've blocked already. It should've fired a
RI
trigger to lock the parent tuple in shared mode, but it looks like
that's not happening for some reason.
To tell the truth I expected another behavior.
Consider ex
The following bug has been logged online:
Bug reference: 4648
Logged by: Konstantin
Email address: kostya2...@rambler.ru
PostgreSQL version: 8.1.16
Operating system: Red Hat Enterprise Linux 4
Description:needless deadlock on tables having foreign-key
Details
The following bug has been logged online:
Bug reference: 2727
Logged by: Konstantin Pelepelin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: RHEL4
Description:pg_restore error on BLOB COMMENTS
Details:
I think, it is part of bug #2452
# port install postgresql---> Building postgresql with target allError: Target com.apple.build returned: shell command "cd"/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_databases_postgresql/work/postgresql-
7.4.12"&& gnumake all" return
The following bug has been logged online:
Bug reference: 2123
Logged by: Konstantin S. Zhinko [tIT]
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0
Operating system: CentOS 3.5
Description:join between stored procedures
Details:
Hi all!
I have a very
structure
vacuum;
select count(*) from r2;
Aggregate (cost=100010594.30..100010594.30 rows=1 width=0)
-> Seq Scan on r2 (cost=1.00..19620.04 rows=389704 width=0)
Why not used primary key index?
(But select * from r2 where r2_id=111; uses this index)
--
Konstan
13 matches
Mail list logo
