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
previou
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
[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 writing the postmaster's SIGCHLD routine in the
same style currently used for SIGHUP --- ie,
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 a
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 o
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 wr
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?" (runs o
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.
Basical
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
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.
>
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> What you really want, of course, is a version of select which lets you
> atomically control the signal blocking mask.
Yeah, that would be a much cleaner solution. Someday pselect() may even
be portable enough ...
regards, to
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:
>http://www.postgre
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 p
OK, now I understand the situation. Another question:
Who is a maintainer of Rtree code ? We have a problem with
handling NULL values in GiST. Any thought how NULL values
are handle in Rtree.
regards,
Oleg
On Sun, 17 Dec 2000, Bruce Momjian wrote:
> Date: Sun, 17 Dec 2000
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> We have a problem with
> handling NULL values in GiST. Any thought how NULL values
> are handle in Rtree.
AFAIR, none of the index access methods except btree handle NULLs at
all --- they just ignore NULL values and don't store them in the index.
Feel f
> 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: PageRepairFragmentatio
Tom Lane wrote:
>
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > We have a problem with
> > handling NULL values in GiST. Any thought how NULL values
> > are handle in Rtree.
>
> AFAIR, none of the index access methods except btree handle NULLs at
> all --- they just ignore NULL values and don'
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 reas
"Mikheev, Vadim" wrote:
>
> > 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.
>
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
(plz cc me on your replies, i'm not on pgsql-hackers for some reason.)
http://www.vix.com/~vixie/results-psql.png shows a gnuplot of the wall time
of 70K executions of "pgcat" (shown below) using a CIDR key and TEXT value.
(this is for storing the MAPS RSS, which we presently have in flat files.)
Hiroshi Inoue wrote :
[ ... ]
> Column order isn't essential in rdbms.
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. Period.
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
27 matches
Mail list logo
