I really have constraints of foreign keys but not on delete, only on update
Stephan Szabo wrote:
Did you perhaps have foreign key constraints with an on delete
clause defined on a table that referenced this one? Postgres doesn't
currently check that the types are comparable before making
A heap page corruption is not very likely in PostgreSQL because of the
underlying page design. Not even on flakey hardware/ossoftware.
(I once read a page design note from pg 4 but don't exactly remember
were or when)
The point is, that the heap page is only modified in places that were
Hiroshi Inoue [EMAIL PROTECTED] writes:
To make it usable for inherited tables requires truly
horrendous kluges (as you well know).
Logical/physical attribute numbers solves it naturally.
Maybe. At this point that's a theory without experimental evidence
to back it up ;-). I'm still
Actually, it's not going to matter since all foreign keys have a delete
portion (realized after seeing your response) that checks to make sure
the one you are deleting is not being referenced.
I'm surprised you're not seeing this on inserts into the fk table or
on updates to the pk table. What
Date: Sun, 17 Dec 2000 22:47:55 -0500
From: Tom Lane [EMAIL PROTECTED]
BUT: I think there's a race
condition here, at least on systems where errno is not saved and
restored around a signal handler. Consider the following scenario:
Postmaster is waiting at the select()
Ian Lance Taylor [EMAIL PROTECTED] writes:
Therefore, the scenario you describe is possible, but only if there
happens to be both a timer interrupt and a SIGCHLD signal within a
couple of instructions after the select returns.
Right. A small failure window would explain the infrequency of
Date: Mon, 18 Dec 2000 10:41:47 -0500
From: Tom Lane [EMAIL PROTECTED]
[EMAIL PROTECTED] (Nathan Myers) writes:
Sounds like a TODO list item: eliminate syscalls from signal handlers.
After looking at it some more, I think that's a lot easier said than
done. We could try
Peter Bierman [EMAIL PROTECTED] writes:
Just now I went to http://www.postgresql.org/mhonarc/pgsql-hackers/
typed 'foo' in the search field, and I get a dialog a few seconds later:
"The attempt to load:"Accessing URL:
http://www.postgresql.org/mhonarc/pgsql-hackers/search.mpl?stuff" (runs
Ian Lance Taylor [EMAIL PROTECTED] writes:
Any thoughts on a cleaner solution?
One way to avoid this race condition is to set a timeout on the
select. What is the maximum acceptable time for a timely response?
I thought about that, but it doesn't seem like a cleaner solution.
Basically
Date: Mon, 18 Dec 2000 13:18:26 -0500
From: Tom Lane [EMAIL PROTECTED]
Ian Lance Taylor [EMAIL PROTECTED] writes:
Any thoughts on a cleaner solution?
One way to avoid this race condition is to set a timeout on the
select. What is the maximum acceptable time for a timely
Thanks. Applied.
Ok, sorry but now I use cvs diff instead of difforig (which use -c by
default). Here the same with -c.
thanks
cyril
Sorry, I need a context diff, diff -c. It makes sure that the lines are
added to the proper places. Thanks.
[ Charset
On Mon, 18 Dec 2000, Tom Lane wrote:
Peter Bierman [EMAIL PROTECTED] writes:
Just now I went to http://www.postgresql.org/mhonarc/pgsql-hackers/
typed 'foo' in the search field, and I get a dialog a few seconds later:
"The attempt to load:"Accessing URL:
Mathijs Brands [EMAIL PROTECTED] writes:
I've worked around the situation by running a small script that continually
monitors postgres and takes appropriate action if postgres shuts down. I'm
assuming this problem won't lead to any data corruption.
Hm. The problem here is that when the
The point is, that the heap page is only modified in places that were
previously empty (except header). All previous row data stays exactly
in the same place. Thus if a page is only partly written
(any order of page segments) only a new row is affected.
Exception: PageRepairFragmentation()
Hannu Krosing [EMAIL PROTECTED] writes:
and I can't see why btree stores them (as it seems to do judging by the
index file size) - at least it does not use it for searching for "IS
NULL"
That's another thing that needs improvement ;-). Seems to me it should
be able to do that.
The reason
On Sat, 16 Dec 2000, Bruce Momjian wrote:
Here is the list of features in 7.1.
One thing that I think ought to be added is that with 7.1,
PostgreSQL will compile out of the box (i.e. without any extra patches)
for Linux/Alpha. This might not be a big deal for most people, but for
those
Hiroshi Inoue wrote :
[ ... ]
Column order isn't essential in rdbms.
Nitpicking
A relation (a table) is a subset of the Cartesain cross-product of the
definition domains of the attributes (columns). Cartesian product being
a commutative operation, "order of columns" does not really exists.
Hi
On LM 7.2-devel pgsql7.03 needs libc.so.6 GLIB2_2.
Would anybody reply what packages do I need to download with
glibc-2.2.21.rpm ?
Thanks
Lucian
Thanks. Applied.
Here is a patch for the beos port (All regression tests are OK).
Cyril, what version(s) of BeOS should be listed for our "ports list"?
- Thomas
Hi folks,
Reading the documentation, I see that OIDs are unique through the
whole database.
But since OIDs are int4, does that limit the number of rows I can
have in a database to 2^32 = 4 billion ?
Best Regards,
Howe
20 matches
Mail list logo
