"Luiz Henrique" <[EMAIL PROTECTED]> writes:
> On 8/21/06, Jim Nasby <[EMAIL PROTECTED]> wrote:
>> What version are you using? In recent versions, indexes are supposed
>> to be safe from corruption, even through crashes.
> It's Postgresql 7.2.1, installed with stable version of Debian Woody, at the
It's Postgresql 7.2.1, installed with stable version of Debian Woody, at the time.On 8/21/06, Jim Nasby <[EMAIL PROTECTED]
> wrote:On Aug 15, 2006, at 8:50 AM, Luiz Henrique wrote:> my problem was problably corrupted index files. I recreated the
> index and it's ok now. The hardware was being unplu
On Aug 15, 2006, at 8:50 AM, Luiz Henrique wrote:
my problem was problably corrupted index files. I recreated the
index and it's ok now. The hardware was being unpluged from power
source without shuthing down, I guess that's the cause.
What version are you using? In recent versions, indexes
Hi, my problem was problably corrupted index files. I recreated the index and it's ok now. The hardware was being unpluged from power source without shuthing down, I guess that's the cause.I used the fallowing commands to recreate index:
/etc/init.d/postgresql stop
su postgres
/usr/lib/postgresql/b
On Fri, 4 Aug 2006, Luiz Henrique wrote:
> Hi, could you tell me how postgresql look for a referenced key? It looks in
> table index? Maybe only the index is corrupted?
It basically runs a query like:
SELECT * FROM parenttable WHERE keycol1 = ? [AND keycol2 = ? ...] FOR
SHARE
It should act lik
Hi, could you tell me how postgresql look for a referenced key? It looks in table index? Maybe only the index is corrupted?Thanks!On 8/2/06, Stephan Szabo
<[EMAIL PROTECTED]> wrote:
On Wed, 2 Aug 2006, Luiz Henrique wrote:> Hi,>> I'm running Postgresql 7.3 in Debian Woody OS.>> After some time wor
On Wed, 2 Aug 2006, Luiz Henrique wrote:
> Hi,
>
> I'm running Postgresql 7.3 in Debian Woody OS.
>
> After some time working properly, insert's statements related this error:
>
>
> referential integrity violation - key referenced from xxx not found in yyy
>
>
> This error would be norma
Hi,I'm running Postgresql 7.3 in Debian Woody OS.After some time working properly, insert's statements related this error:referential integrity violation - key referenced from xxx not found in yyy
This error would be normal, if the key really doesn't exist, but the key exist.The insert's wo
Title: Referential Integrity
This was originally logged under pgsql-sql, as "[SQL] Referential Integrity", but after some discussion it seems that this is a bug.
I have the following scenario in pg7.3.1.:
CREATE TABLE alex (aid varchar(40) NOT NULL,
bid varchar(100) NO
This is probably more like an "undesired feature" than a software bug, but
it was behaviour that I did not expect.
thanks!
Your name : Josh Goldberg
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel P
Stephan Szabo <[EMAIL PROTECTED]> writes:
> As a related side note. The other part of the original patch (the NOT
> EXISTS in the upd/del no action trigger) was rejected. For match
> full and match unspecified the same result can be reached by doing another
> query which may be better than the s
On 2002.06.11 at 14:43:17 -0400, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > It should work (and does in current sources). If you look in the archives
> > you should be able to get info on how to patch 7.2 (it came up recently,
> > I'm not sure which list, and Tom Lane sent t
On Tue, 11 Jun 2002, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Mon, 10 Jun 2002, Stephen R. van den Berg wrote:
> >> ERROR: referential integrity violation - key referenced
> >> from b not found in a
> >> Or should it work because the check is deferred and in the
> >> e
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Mon, 10 Jun 2002, Stephen R. van den Berg wrote:
>> ERROR: referential integrity violation - key referenced
>> from b not found in a
>> Or should it work because the check is deferred and in the
>> end no violations are present?
> It should work (a
>From billy Tue Jun 11 13:38:51 2002
Date: Tue, 11 Jun 2002 10:54:27 -0700 (PDT)
From: Stephan Szabo <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
On Mon, 10 Jun 2002, Stephen R. van den Berg wrote:
> Should the following piece of code cause an:
On Mon, 10 Jun 2002, Stephen R. van den Berg wrote:
> Should the following piece of code cause an:
> ERROR: referential integrity violation - key referenced
> from b not found in a
> Or should it work because the check is deferred and in the
> end no violations are present?
It should work (a
On Tue, 11 Jun 2002, [ISO-8859-1] Matej Hollý wrote:
> /*
> If a table contains two or more foreign keys referencing the same
> table and they reference the same record in the other table, the
> record's primary key cannot be changed even if the keys have the
> "ON UPDATE CASCADE" clause
/*
If a table contains two or more foreign keys referencing the same
table and they reference the same record in the other table, the
record's primary key cannot be changed even if the keys have the
"ON UPDATE CASCADE" clause (see example below). It will say that
"referential integrity e
Should the following piece of code cause an:
ERROR: referential integrity violation - key referenced
from b not found in a
Or should it work because the check is deferred and in the
end no violations are present?
create table a(ia int primary key);
create table b(ia int references a initially
Tom Lane wrote:
>
> [EMAIL PROTECTED] writes:
> > -- Rule over the referenced table
> > -- which breaks referential integrity
> > create rule nodelrel
> > as on delete to rel
> > where old.ref > 3 and user = 'prueba'
> > do instead nothing;
>
Hi Tom,
first of all, my congratulations to
On Fri, 6 Jul 2001 [EMAIL PROTECTED] wrote:
> José María Fernández González ([EMAIL PROTECTED]) reports a bug with a severity
>of 1
> The lower the number the more severe it is.
>
> Short Description
> Referential Integrity corrupted sometimes by Rules
>
> Long Description If you define an em
[EMAIL PROTECTED] writes:
> -- Rule over the referenced table
> -- which breaks referential integrity
> create rule nodelrel
> as on delete to rel
> where old.ref > 3 and user = 'prueba'
> do instead nothing;
This rule is preventing the foreign key triggers from performing the
DELETEs implied by
José María Fernández González ([EMAIL PROTECTED]) reports a bug with a severity
of 1
The lower the number the more severe it is.
Short Description
Referential Integrity corrupted sometimes by Rules
Long Description
If you define an empty rule with a condition over a table which references to an
On Mon, 18 Jun 2001 [EMAIL PROTECTED] wrote:
> Denis Sbragion ([EMAIL PROTECTED]) reports a bug with a severity of 3
> The lower the number the more severe it is.
>
> Short Description
> Referential integrity problem
>
> Long Description It looks like performing operation in two steps on
> tabl
Please take my name off of this email list.
Thank you!
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 18, 2001 12:49 PM
To: [EMAIL PROTECTED]
Subject: [BUGS] Referential integrity problem
Denis Sbragion ([EMAIL PROTECTED]) reports a bug with a
This is a known problem. We don't have a fix yet.
> Hi,
> We think we have found a problem when deleting and inserting in
> the same transaction with constraints deferred:
>
>
> machine=> create table foo (bar int4 primary key, ref int4 references foo
> deferrable
Hi,
We think we have found a problem when deleting and inserting in
the same transaction with constraints deferred:
machine=> create table foo (bar int4 primary key, ref int4 references foo
deferrable);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index
On Wed, 30 Aug 2000 [EMAIL PROTECTED] wrote:
> Short Description
> referential integrity requires write permission to a table which only needs to be
>read
Yes, this is a known problem.
> And, why is the trigger trying to select WITH UPDATE? (locking?)
Yes, if you don't grab a row lock, anothe
Dave E Martin ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
referential integrity requires write permission to a table which only needs to be read
Long Description
I have two tables:
create table NAS_MAKE
(
id int8 no
POSTGRESQL BUG REPORT TEMPLATE
Your name : Marco Morandini
Your email address : [EMAIL PROTECTED]
System Configur
30 matches
Mail list logo
