Christopher Kings-Lynne wrote:
Hi,
I have just tried using the ILIKE function in 7.0.3. I assume that it is
just a case-insensitive version of LIKE. (Please correct me if I am wrong
on this assumption.)
AFAIK postgres 7.0.3 does not have it, ILIKE appeared in 7.1
But you could use
Hello all,
sorry, but I haven't received any replies to my previous message... and
it's important for me to solve it.
When I perform an action on a psql database (e.g. insert into a table),
some more action could be induced, via trigger firing:
- is it possible to know at any time the exact
Hi!
I download, configure and install postgresql-7.1beta1 _exactly_ the
same way as my previous version - 7.0.2:
./configure --enable-multibyte=KOI8 --enable-locale
gmake
gmake install
initdb
But it seems to me locale support gone out. In particulary
select upper('òÕÓÓËÉÊ ÔÅËÓÔ -
I stated this before, but I did not get a helpful answer. I might have
misunderstood tghe documentation on foreign keys:
create table global(id serial);
create table child(anything text) inherits(global);
insert into child(anything) values ('test);
Now, a select * from child shows
id
hi, there!
test=# create table a(id int primary key);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'a_pkey' for
table 'a'
CREATE
test=# create table b(id int references a);
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
check(s)
CREATE
test=# insert into a
create unique index child_id_index on child (id);
Thanks a lot. You saved my day :-)))
Always feels good to be able to help :-)
CREATE TABLE will create implicit trigger(s) for FOREIGN
KEY check(s)
ERROR: UNIQUE constraint matching given keys for referenced
table "child"
Mikheev, Vadim wrote:
So, I've run simple test (below) to check this. Seems that 7.1
is faster than 7.0.3 (nofsync), and that SELECT FOR UPDATE in RI
triggers is quite bad for performance.
Also, we should add new TODO item: implement dirty reads
and use them in RI triggers.
Hi,
we are getting a bit close to add index support for int arrays using
GiST interface. This will really drive up performance of our full text
search fully based on postgresql. We have a problem with broken index
and couldn't find a reason. I attached archive with sources
for GiST functions and
"Christopher Kings-Lynne" [EMAIL PROTECTED] writes:
However, is it possible to create a type that has different parameters
wherever it is used.
For instance - the varchar type takes as a parameter the max characters in
the field. Although there is only one varchar type, it has different
Hi!
My name is Daniel Åkerud, a swedish studen, writing an essay for my exam.
The label will be something like: "Database algorithms".
I know it is a complex task, and will ofcourse, as soon as possible,
specify more preciesly what it will be about.
I have thoughts about writing about, for
Tom Lane writes:
I take it from the smiley that you're not serious, but actually it seems
like it might not be a bad idea. I could see appending a CRC to each
tuple record. Comments anyone?
I think I missed the point here. With CRC you typically want to detect
data corruption. Where's
Christopher Kings-Lynne writes:
I have just tried using the ILIKE function in 7.0.3.
There is no ILIKE function in 7.0.3.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Bruce Momjian writes:
ERROR: triggered data change violation on relation "primarytest2"
We're getting this report about once every 48 hours, which would make it a
FAQ. (hint, hint)
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Interesting comments. I can see using the STL framework for iterating
through result sets being one way to go. Would something like:
vectorpgrowstable = pgdb.exec("Select * from foo");
vectorpgrows::iterator row;
vectorpgrows::iterator end = table.end();
for( row = table.begin(); row != end;
I found it in the PostgreSQL Administrator manual under "Managing Kernel
Resources".
Wade Oberpriller
Hi,
I have been using Postgres-7.0.2 on Solaris 8 for the past few months, and
was about to upgrade to 7.1-test, and after following carefully the docs, I
get this:
Martin A. Marques writes:
IpcSemaphoreCreate: semget(key=5432004, num=17, 03600) failed: No space left
on
device
http://www.postgresql.org/devel-corner/docs/postgres/kernel-resources.htm#SYSVIPC
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Hi,
Where can I find documentation on WAL, TOAST and how to configure the
pg_hda.conf file?
Saludos... ;-)
--
System Administration: It's a dirty job,
but someone told I had to do it.
-
Martín Marqués
Database research papers at berkeley are at:
http://s2k-ftp.CS.Berkeley.EDU:8000/postgres/papers/
On Wednesday 13 December 2000 12:16, DÅ wrote:
Hi!
My name is Daniel Åkerud, a swedish studen, writing an essay for my exam.
The label will be something like: "Database algorithms".
I know it
On Wed, Dec 13, 2000 at 03:16:28PM -0500, Randy Jonasz wrote:
On Tue, 12 Dec 2000, Nathan Myers wrote:
On Tue, Dec 12, 2000 at 05:28:46PM -0500, Bruce Momjian wrote:
I was co-architect of the Rogue Wave Dbtools.h++ interface design
... The design is really showing its age.
Can you
On Wed, 13 Dec 2000, mlw wrote:
Assuming all my assumptions are correct, (and I can't see how that is
possible ;-), I should also call the Init function at this time.
The big problem is calling the "Exit" function. I am sure that will not
be easily done, or even doable, but we can dream.
I noticed the other day that one of my pg databases was slow, so I ran
vacuum on it, which brought a question to mind: why the need? I looked
at my oracle server and we aren't doing anything of the sort (that I can
find), so why does pg need it? Any info?
Thanks,
- brandon
b. palmer,
I've been looking into Brian Hirt's complaint that 7.0.3 and 7.1 are
lots slower than 7.0.2 in planning big joins. The direct cause is that
since we now deduce implied equality clauses, the system has more
potential join paths than it used to --- for example, given "WHERE
a.x = b.y AND b.y =
* Martin A. Marques [EMAIL PROTECTED] [001213 15:15] wrote:
El Mié 13 Dic 2000 16:41, bpalmer escribió:
I noticed the other day that one of my pg databases was slow, so I ran
vacuum on it, which brought a question to mind: why the need? I looked
at my oracle server and we aren't doing
bpalmer wrote:
I noticed the other day that one of my pg databases was slow, so I ran
vacuum on it, which brought a question to mind: why the need? I looked
at my oracle server and we aren't doing anything of the sort (that I can
find), so why does pg need it? Any info?
Hi,
I'm one
I need a little help on the format of the postgres tables.
I've got this wonderfully corrupted database where just about everything is
fubar. I've tried a number of things to get it back using postgres and
related tools with no success. It looks like most of the data is there, but
there may
* Tom Lane [EMAIL PROTECTED] [001213 15:18] wrote:
I'm trying to resist the temptation to make this change right now :-).
It's not quite a bug fix --- well, maybe you could call it a performance
bug fix --- so I'm kind of thinking it shouldn't be done during beta.
OTOH I seem to have lost
sorry, meant to respond to the original and deleted it too fast ...
Tom, if the difference between 7.0 and 7.1 is such that there is a
performance decrease, *please* apply the fix ... with the boon that OUTER
JOINs will provide, would hate to see us with a performance hit reducing
that impact
I still don't see how dirty reads can solve the RI problems.
If Xact A deletes a PK while Xact B inserts an FK, one of
them will either see the new reference or the PK gone. But
from a transactional POV it depends on if the opposite Xact
finally commits or not
Hi.
I need a little help on the format of the postgres tables.
I've got this wonderfully corrupted database where just about everything is
fubar. I've tried a number of things to get it back using postgres and
related tools with no success. It looks like most of the data is there, but
there may
Alfred Perlstein [EMAIL PROTECTED] writes:
If you're saying that you're OK with the work Vadim has done please
let him know, I'm assuming he hasn't committed out of respect for your
still standing objection.
Well, I'm still against committing it now, but I only have one core
vote, and I seem
I seem to miss the announce of beta testing of 7.1. Could someone
please give me a copy of the announcement?
--
Tatsuo Ishii
pg_options.sample coming with 7.0.x does not work because:
1) it exceeds 4096 bytes while read_pg_options() reads only first 4096
bytes of it.
2) it allows spaces around "=" while parese_options() does not.
Apparently the sample file was brought in without enough testings when
7.0 was
Thanks for responding. I've made some comments below.
On Wed, 13 Dec 2000, Nathan Myers wrote:
On Wed, Dec 13, 2000 at 03:16:28PM -0500, Randy Jonasz wrote:
On Tue, 12 Dec 2000, Nathan Myers wrote:
On Tue, Dec 12, 2000 at 05:28:46PM -0500, Bruce Momjian wrote:
I was co-architect of
beta1 was very low key ... it was announced here on the list as "its
packaged, try it out" ... there was no big hype about this one, but there
will be for beta2, which will most likely be after Vadim gets those vacuum
fixes in place, and Tom gets those planner fixes ...
On Thu, 14 Dec 2000,
Tatsuo Ishii [EMAIL PROTECTED] writes:
pg_options.sample coming with 7.0.x does not work because:
1) it exceeds 4096 bytes while read_pg_options() reads only first 4096
bytes of it.
Oliver Elphick posted a patch for this recently (pghackers 28-Nov)
and noted that it seemed already fixed in
I have this nasty problem too, in early time, I don't know the problem, but we used
it for a while,
than we found our table growing too fast without insert any record( we use update),
this behaviour
most like M$ MSACCESS database I had used a long time ago which don't reuse deleted
record
* xuyifeng [EMAIL PROTECTED] [001213 18:54] wrote:
I have this nasty problem too, in early time, I don't know the problem, but we used
it for a while,
than we found our table growing too fast without insert any record( we use update),
this behaviour
most like M$ MSACCESS database I had
On Wed, 13 Dec 2000, bpalmer wrote:
Yes, postgresql requires vacuum quite often otherwise queries and
updates start taking ungodly amounts of time to complete. If you're
having problems because vacuum locks up your tables for too long
you might want to check out:
But why? I don't
But why? I don't know of other databases that need to be 'vacuum'ed. Do
all others just do it internaly on a regular basis?
What am I missing here?
Plenty of other databases need to be 'vacuumed'. For instance, if you have
an ms access database with 5 MB of data in it, and then delete all
On Thu, 14 Dec 2000, Christopher Kings-Lynne wrote:
Plenty of other databases need to be 'vacuumed'. For instance, if you have
an ms access database with 5 MB of data in it, and then delete all the data,
leaving only the forms, etc - you will be left with a 5MB mdb file still!
If you then
Bruce Momjian writes:
ERROR: triggered data change violation on relation "primarytest2"
We're getting this report about once every 48 hours, which would make it a
FAQ. (hint, hint)
First time I heard of it. Does anyone know more details?
--
Bruce Momjian
"Michael Richards" [EMAIL PROTECTED] writes:
Following that I find the 2 word tuple pointers.
The first word appears to be the offset in the page where the tuple can be
found but the MSB has to be stripped off (haven't found it's function in the
source yet).
The second is the transactionid
Althoug this happens on old 6.5.3, I would like to know if this has
been already fixed...
Here is the scenario:
1) before vacuum, table A has 8850 tuples.
2) vacuum on table A makes postgres crashed.
3) it crashes at line 1758:
Assert(num_moved == checked_moved);
I examined
43 matches
Mail list logo
