because the cache will be emptied by high priority multiple new rows,
thus writing to the end anyways.
Yes, but this only happens when you don't have enought spare idle CPU
time. If you are in such situation for long periods, there's nothing you
can do, you already have problems.
I
cusejoua=# update journaleintrag set txt_funktion=trim(txt_funktion);
FATAL 2: write(logfile 0 seg 2 off 4612096) failed: No such file or directory
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or
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
Well,
we found an answer ourserlves. Patch for 7.0.3 is included below.
Credits to Teodor Sigaev ([EMAIL PROTECTED])
Some comments:
From src/backend/access/gist/gist.c
/*
** Take a compressed entry, and install it on a page. Since we now know
** where the entry will live, we decompress it and
It looks like other people just didn't use index decompression function
(at least in Gene's code decompression function just do return ) and
that's why this bug was not discovered. We could make a patch for
upcoming 7.1 if hackers desired. I consider this patch as a bugfix
not a new feature
Michael Richards wrote:
Okay,
Where would I find a definition of the tuple data? I didn't see anything
promising in include/storage?
I've found a definition for the page inside pagebuf.h That clears up all the
page stuff. I'm still having a little trouble decoding the tuple data
Hi there,
I went thru all the mailing list archives and other
documentation and found the way to increase the max
tuple size clearly as " change the BLCKSZ to "
I did that and even created a new data directory and
cluster by using init_db but the error
psql:ins.sql:173: ERROR: Tuple is too
Hi,
Can anyone help me .
I want to know how
to write triggers.
i am using java and postgresql
---
From:- |
Ms. Manika Dey.|Ph.No:--
Engineer-SC (Comp. Tech.) | IPR -- 02712 -
The Hermit Hacker wrote:
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
But i'm not making any compare.
I just wrote delete from table; and i receive that message.
Hmm. We will need to know more about your setup, since a simple
delete from table;
in psql does not involve *any* comparisons, and should never provoke the
message you are receiving.
Perhaps
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 the
constraint. I'm working on adding a check for that now.
Or for that matter, any other rules or
Bruce Momjian [EMAIL PROTECTED] writes:
Totally agree. In the old days, we posted all our patches to the list
so people could see. We used to make cvs commits only on the main
server, so we had the patch handy, and it made sense to post it. Now
that we have remote cvs, we don't do it as
On Fri, 15 Dec 2000, Alfred Perlstein wrote:
* Bruce Momjian [EMAIL PROTECTED] [001215 10:34] wrote:
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
It seems that Tom has committed his fixups but we're still waiting
on Vadim?
Sorry guys, I'm busy with WAL issues currently.
CRC will require initdb, so it's better to implement it
first...
Also, is TOAST-table vacuuming fixed now?
Vadim
"Oliver Elphick" wrote:
In the creation below, the column parent_id has ended up with a NOT NULL
constraint that I didn't ask for and don't want.
If I change the order of the columns, the NOT NULL constraint always ends
up on the last column.
This is not the only table to be affected.
Bruce Momjian [EMAIL PROTECTED] writes:
If you like I'll post the patch, but it strikes me as a waste of list
bandwidth --- anyone who is likely to actually review it is perfectly
capable of doing cvs diff for themselves ...
Posting patch is only useful if you want people to review it. They
* Bruce Momjian [EMAIL PROTECTED] [001215 10:34] wrote:
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
Also, is TOAST-table vacuuming fixed now?
Still broken. Hiroshi had muttered something about fixing
the internal commit of VACUUM so that it's more like a real
commit --- including advancing the transaction ID --- but
still doesn't release the exclusive lock held by VACUUM.
Basically
[ Charset ISO-8859-1 unsupported, converting... ]
It seems that Tom has committed his fixups but we're still waiting
on Vadim?
Sorry guys, I'm busy with WAL issues currently.
CRC will require initdb, so it's better to implement it
first...
Also, is TOAST-table vacuuming fixed now?
Can
Bruce Momjian [EMAIL PROTECTED] writes:
If you like I'll post the patch, but it strikes me as a waste of list
bandwidth --- anyone who is likely to actually review it is perfectly
capable of doing cvs diff for themselves ...
Posting patch is only useful if you want people to review it.
Sorry guys, I'm busy with WAL issues currently.
CRC will require initdb, so it's better to implement it
first...
Also, is TOAST-table vacuuming fixed now?
Can someone please remind me? CRC allows us to know of WAL log is
corrupt?
Currently WAL has no means to know is log data
I can't reproduce this --- I get
Constraints: ((ptype = 0) AND (ptype = 8))
structure = 'L'::bpchar) OR (structure = 'C'::bpchar)) OR (structure
= 'U'::bpchar)) OR (structure = 'O'::bpchar))
(((department ISNULL) AND (parent_id ISNULL)) OR ((department ''::text)
OK, I see the problem. You have:
CREATE TABLE person (
id CHAR(10)
);
CREATE TABLE organisation (
...,
PRIMARY KEY (id)
)
INHERITS (person);
ie, a PRIMARY KEY declaration on an inherited column. Normally a
PRIMARY KEY declaration causes the key column to become marked
NOT
peter=# select 1 as current;
old
-
1
This is now the inverse of what it used to do, but it's still not what it
*should* do. I see someone already tried to fix that (keywords.c 1.76 -
1.77, TODO list), but he should try again.
--
Peter Eisentraut [EMAIL PROTECTED]
peter=# select 1 as current;
old
-
1
This is now the inverse of what it used to do, but it's still not what it
*should* do. I see someone already tried to fix that (keywords.c 1.76 -
1.77, TODO list), but he should try again.
That was me. The old code did old - current, so I
We'd still want XID keys for the locks that are used to wait for a
particular transaction to complete (eg when waiting to update
a tuple). I think that's OK since VACUUM doesn't need to hold any
such locks, but it'd probably mean making separate lmgr API entry
points for those locks as
Tom, I see from the CVS logs you say:
Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias.
(Don't forget that an alias is required.) Views reimplemented as expanding
to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually
work now (he says
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, I see from the CVS logs you say:
Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias.
(Don't forget that an alias is required.) Views reimplemented as expanding
to subselect-in-FROM. Grouping, aggregates, DISTINCT in views
Peter Eisentraut [EMAIL PROTECTED] writes:
peter=# select 1 as current;
old
-
1
This is now the inverse of what it used to do, but it's still not what it
*should* do. I see someone already tried to fix that (keywords.c 1.76 -
1.77, TODO list), but he should try again.
We should
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
We'd still want XID keys for the locks that are used to wait for a
particular transaction to complete (eg when waiting to update
a tuple). I think that's OK since VACUUM doesn't need to hold any
such locks, but it'd probably mean making separate
Bruce Momjian [EMAIL PROTECTED] writes:
That was me. The old code did old - current, so I changed it to do
current - old. How else can I fix this? Attached is the old patch.
But CURRENT was strictly an internal token name, not a string the user
could actually see. So there's no need to
Tom Lane wrote:
...
Short of a major restructuring of inherited-column creation, I see
no good solution to this. I see two bad solutions:
1. Require that the referenced column be marked NOT NULL already,
so that the constraint will be inherited properly from the parent.
In other
I've been getting these for about 6 hours now:
cvs server: [18:58:27] waiting for anoncvs's lock in /home/projects/pgsql/cvsroot/pgsql
Can someone kill off this lock so I can commit?
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
In recent months there has been a great deal of speculation,
confusion and concern raised in the open source community over
the roles of commercial companies and the PostgreSQL project.
There has also been a lot of curiosity and noise around who
and what PostgreSQL, Inc. (PgSQL) is...
As a
"mike" [EMAIL PROTECTED] writes:
Is ther any info on using toast as of yet, and if so where is it hidden to?
There isn't any yet, but you don't really need it. Just declare
your tables and away you go. No User-Serviceable Parts Inside ;-)
regards, tom lane
http://www.heartlight.org/cgi-shl/todaysverse.cgi?day=20001215
===
Created by Mail2Sig - http://pdunford.godzone.net.nz/software/mail2sig/
Thomas Lockhart [EMAIL PROTECTED] writes:
It works for me:
regression=# select t1.*, t2.* from t1 natural left outer join t2;
id | id2 | id
+-+
1 | 1 | 1
My recollection is that SQL9x requires that the join result lose the
link to the original table names. That is,
The first and second items here seem to be perfectly clear that the
names t1 and t2 have scope across the whole SELECT statement and are not
hidden within the joined table formed by the OUTER JOIN clause.
You are right. If there is a "correlation name", then those underlying
table names
38 matches
Mail list logo
