OK, I have committed changes to release.sgml so most complex entries
have a paragraph describing the change. You can see the result at:
http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-7-4
I need people to check this and help me with the items marked 'bjm'. I
am
Bruce Momjian wrote:
http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-7-4
I need people to check this and help me with the items marked 'bjm'. I
am confused about the proper text for those sections.
Allow polymorphic SQL functions (Joe)
bjm ??
What isn't clear about this?
Jan Wieck wrote:
Confirmed, that's a bug - pgsql-hackers CC'd and scipt for full
reproduction attached.
Assumptions where correct, bug fixed in REL7_3_STABLE and HEAD. I also
added a slightly modified version of the script that reproduced the bug
to the foreign_key regression test.
Jan
This
Confirmed, that's a bug - pgsql-hackers CC'd and scipt for full
reproduction attached.
This can also be reproduced in 7.4-beta5.
My guess out of the blue would be, that the rewriter expands the insert
into one insert with the where clause, one update with the negated where
clause. Executed in
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Philip Yarra [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, October 29, 2003 10:58 PM
Subject: Re: Fwd: Re: [HACKERS] Call for port reports
Philip Yarra [EMAIL PROTECTED] writes:
I've just tried the latest CVS on
Am So, den 26.10.2003 schrieb Bruce Momjian um 02:38:
All 93 tests passed.
...
Linux pergolesi 2.4.22 #1 SMP Mon Aug 25 20:56:25 CEST 2003 i686 GNU/Linux
It says i686 but its AMD Opteron:
[EMAIL PROTECTED]:~/pgsql$ cat /proc/cpuinfo |more
...
model name : AMD Opteron(tm)
--On Wednesday, October 29, 2003 15:26:39 -0500 Tom Lane
[EMAIL PROTECTED] wrote:
[snip]
Is this a bug, or is it correct-per-spec behavior? It's surely likely
to confuse people. I wonder whether superusers shouldn't be allowed to
revoke privileges granted by other people. As the code stands,
Okay, the cause of the permissions regression failure is this:
Larry is running the regression tests as a superuser, but not as the
original postgres superuser. This means that when the privileges
regression test does
REVOKE ALL PRIVILEGES ON LANGUAGE sql FROM PUBLIC;
nothing happens,
I didn't see this come back in, so, I'm resending it.
LER
Forwarded Message
Date: Wednesday, October 29, 2003 22:26:43 -0600
From: Larry Rosenman [EMAIL PROTECTED]
To: PostgreSQL Hackers Mailing List [EMAIL PROTECTED]
Cc:
Subject: SCO released UP3 today...
which means
Bruce Momjian writes:
Bug tracking systems have the same limitation as incremental release
notes --- youi have to do a lot of piecemeal work to get complete output
at the end, rather than doing it more efficiently in one batch.
Most people working on PostgreSQL are volunteers, and one of my
Bruce Momjian writes:
I have added my first release note detail item. I used footnote to
add a description to the first release note item.
Please don't use footnotes. They make things really hard to read. There
are plenty of other mechanisms to organize information.
--
Peter Eisentraut
Greg Stark wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
One problem for WAL is that O_DIRECT would disable the write cache -
each operation would block until the data arrived on disk, and that might block
other backends that try to access WALWriteLock.
Perhaps a dedicated backend that does
DB2 supports cooked and raw file systems - SMS (System Manged Space)
and DMS (Database Managed Space) tablespaces.
The DB2 experience is that DMS tends to outperform SMS but requires
considerable tuning and administrative overhead to see these wins.
--
Pip-pip
Sailesh
Peter Eisentraut wrote:
Bruce Momjian writes:
I have added my first release note detail item. I used footnote to
add a description to the first release note item.
Please don't use footnotes. They make things really hard to read. There
are plenty of other mechanisms to organize
I've have a MAJOR crash an hour ago and postgresql doesn't start anymoe
(version 7.3.4).
Here's the error log:
Oct 30 17:16:20 server postgres[4135]: [1-2]This probably means that some data
blocks are corrupted
Oct 30 17:16:20 server postgres[4135]: [1-3]and you will have to use the
Someething to consider for after the 7.4 release, perhaps...
As per today's CVS version, PQunescapeBytea() does the following when
it encounters an escaped character (i.e., a backslash) in the escaped
string strtext at offset i:
[if (strtext[i] == '\\')]
i++;
if (strtext[i] == '\\')
On Thu, Oct 30, 2003 at 08:24:13PM +0100, Jeroen T. Vermeulen wrote:
Then the whole loop could become something like this:
Okay, that code wasn't entirely correct but it gets the idea across. In
C++ terms, what I arrived at was:
string result;
for (int i=0; iF.size(); ++i)
{
Hallo.
i just coded a new datatype named cistring, that can be
used in every function that accepts text or varchar, and has
the great ability to be ordered case insensitive in ORDER BY-
Clauses and Indices. The problem is, that its coded like the
text-type, so it is variable length completly.
I
Hi,
I am facing a strange problem and thats bugging me for a long time,
I am using postgres version 7.2.1.
I have written an application in C which tries to drop a trigger and simultaneously read from a table thats has data related to that trigger.
the whole database comes into a
On 30 Oct 2003, Vatsal Avasthi wrote:
Hi,
I am facing a strange problem and thats bugging me for a long time,
I am using postgres version 7.2.1.
Is it possible for you to upgrade to 7.2.4 just to make sure it's not a
problem that was fixed from 7.2.1 to 7.2.4?
you can also patch your kernel and when you write cat /etc/passwd system
give you only your line , whitout any others users, so exacly what you
need ,
in pgsql i think that users dont need to know about others , and also
them
databases, i call it security :)
On Mon, 27 Oct 2003, Jan Wieck wrote:
rfc 1925 (see http://www.faqs.org/rfcs/rfc1925.html ) states:
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly overhead.
You can call it
Andrew Dunstan [EMAIL PROTECTED] writes:
2. include catalog objects in expansion iff we are expanding pg_ +
optional suffix (probably best of both worlds).
That seems like the best compromise position anyone offered, so I have
made the code work that way.
regards, tom
On Thu, 30 Oct 2003, ivan wrote:
you can also patch your kernel and when you write cat /etc/passwd system
give you only your line , whitout any others users, so exacly what you
need ,
in pgsql i think that users dont need to know about others , and also
them
databases, i call it security
ivan wrote:
you can also patch your kernel and when you write cat /etc/passwd system
give you only your line , whitout any others users, so exacly what you
need ,
in pgsql i think that users dont need to know about others , and also
them
databases, i call it security :)
No, it's not security, it
[EMAIL PROTECTED] writes:
I've have a MAJOR crash an hour ago and postgresql doesn't start anymoe
(version 7.3.4).
Oct 30 17:16:21 server postgres[4135]: [7] PANIC: Invalid page header in block 6157
of 29135442
Oct 30 17:16:21 server postgres[4132]: [1] LOG: startup process (pid 4135) was
Daniel Migowski [EMAIL PROTECTED] writes:
I miss the possibility to code something like a userdifined
varchar(n).
You're out of luck on that. The data types that can have precision
parameters attached to them are hard-wired into the parser.
regards, tom lane
Vatsal Avasthi [EMAIL PROTECTED] writes:
I am using postgres version 7.2.1.
Looks like both try to have a lock and that leads to a deadlock
situation.
It's hard to believe that SELECT and DROP TRIGGER alone could deadlock;
and if they did, you should get a deadlock failure report, not an
Thanks Tom,
The answer came too late and I could'nt wait. pg_resetlog did nearly the
trick, Only one database was really hurt. So I reloaded all but this one
from pg_dumpall then the last one from backup...
I'm cursed
On Thu, 30 Oct 2003, Tom Lane wrote:
Date: Thu, 30 Oct 2003 17:25:02 -0500
Bruce Momjian [EMAIL PROTECTED] writes:
We only have a few open items left. Can we finish them so we can move
toward final release?
The list seems to be nearly down to this:
Rename dump GUC variable to be more generic
Sure, if we can agree on a name.
We have a few options here.
Actually I was looking at that code today and it does not ignore something
if it is escaped by a backslash on not on the list. It eats the backslash
and then continues the loop so next time that character will be parsed
normally. However PQunescapeBytea is _very_ slow. I am storing fairly
Barring the discovery of any major new bugs, the core committee has
agreed to release 7.4RC1 on Monday. Time to get those last-minute
fixes in place.
I currently have the following issues on my radar screen:
Force GRANT/REVOKE by superuser to act as though owner of object?
Change libpgtcl to
Hello,
I know I will probably be flamed into oblivion for this but I would
like to make a suggestion about
the upcoming release.
What if we delayed until the end of the year?
The two reasons that I can come up with are:
1. The irritating (but work around capable) bigint index issue.
Joshua D. Drake [EMAIL PROTECTED] writes:
What if we delayed until the end of the year?
Nope, not for those items. There is still some thought of a very short
release cycle (a few months) for 7.5, and we could possibly address the
vacuum issue in that timeframe, if the recent ideas about it
Sooner or later you have to say this release is done, let's ship it.
It's way too late to go back into invention mode for 7.4.
I agree with the argument. It is just that the Vacuum one... well is
very tempting.
On the 7.5 cycle though... I thought 7.5 was basically for win32?
Sincerely,
My experience with DB2 showed that properly setup DMS tablespaces provided a
significant performance benefit. I have also seen that the average DBA does
not generally understand the data or access patterns in the database. Given
that, they don't correctly setup table spaces in general,
On Thu, 30 Oct 2003, Joshua D. Drake wrote:
Hello,
I know I will probably be flamed into oblivion for this but I would
like to make a suggestion about
the upcoming release.
What if we delayed until the end of the year?
The two reasons that I can come up with are:
1.
scott.marlowe [EMAIL PROTECTED] writes:
Are these folks for whom the autovacuum daemon provides no relief?
If I understood correctly, Josh was complaining about VACUUM sucking too
much of his disk bandwidth. autovacuum wouldn't help that --- in fact
would likely make it worse, since a
-Original Message-
From: Jordan Henderson [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 4:31 PM
To: [EMAIL PROTECTED]; Doug McNaught
Cc: Christopher Kings-Lynne; PostgreSQL-development
Subject: Re: [HACKERS] O_DIRECT in freebsd
My experience with DB2 showed that
Jordan == Jordan Henderson [EMAIL PROTECTED] writes:
Jordan significantly better results. I would not say it requires
Jordan considerable tuning, but an understanding of data, storage
Jordan and access patterns. Additionally, these features did not
Jordan cause our group
If I understood correctly, Josh was complaining about VACUUM sucking too
much of his disk bandwidth. autovacuum wouldn't help that --- in fact
would likely make it worse, since a cron-driven vacuum script can at
least be scheduled for low-load times of day. autovacuum is likely to
kick in at
Nope, not for those items. There is still some thought of a very short
release cycle (a few months) for 7.5, and we could possibly address the
vacuum issue in that timeframe, if the recent ideas about it prove out.
But there is no consensus on how to fix the integer-index issues, and
I'm not
Tatsuo Ishii [EMAIL PROTECTED] writes:
The idea of very short release cycle for 7.5 is interesting. What is
the core's decision for point-in-time-recovery? Maybe the decision is
7.5 does not include point-in-time-recovery?
We'd like to have it in 7.5. Whether it will get done in time is
On Thu, 30 Oct 2003, Tom Lane wrote:
rule/foreign key interaction reported by Michele Bendazzoli
In the interests of disclosure, if the case in question for the rule
fails, almost certainly deferred fk constraints will as well which I
think makes this a must fix for 7.4 and is another push to
Adam Kavan wrote:
Actually I was looking at that code today and it does not ignore something
if it is escaped by a backslash on not on the list. It eats the backslash
and then continues the loop so next time that character will be parsed
normally. However PQunescapeBytea is _very_ slow.
Attached is an extremely crude prototype patch for making VACUUM delay
by a configurable amount between pages, in hopes of throttling its disk
bandwidth consumption. By default, there is no delay (so no change in
behavior). In some quick testing, setting vacuum_page_delay to 10
(milliseconds)
On Thu, 30 Oct 2003, David Fetter wrote:
On Thu, Oct 30, 2003 at 09:08:43PM -0400, Tom Lane wrote:
Barring the discovery of any major new bugs, the core committee has
agreed to release 7.4RC1 on Monday. Time to get those last-minute
fixes in place.
I currently have the following
On Thu, 30 Oct 2003, Joshua D. Drake wrote:
Sooner or later you have to say this release is done, let's ship it.
It's way too late to go back into invention mode for 7.4.
I agree with the argument. It is just that the Vacuum one... well is
very tempting.
On the 7.5 cycle though... I
On Fri, 31 Oct 2003, Tatsuo Ishii wrote:
Nope, not for those items. There is still some thought of a very short
release cycle (a few months) for 7.5, and we could possibly address the
vacuum issue in that timeframe, if the recent ideas about it prove out.
But there is no consensus on
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 30 Oct 2003, David Fetter wrote:
Any chance of putting up a torrent for it? I'd be happy to host, but
I'd have to get the link on the downloads page somehow :)
Put up a what ... ?
Google for BitTorrent. It's a pretty darn cool app
Does anyone have anything ready to put into CVS as soon as we start v7.5,
or shortly afterwards?
Check bruce's 7.5 patches list (can't remember the address though :) )
I have this COMMENT ON thing ready to go, except for this darn taking in
unsigned ints from the parser business that I haven't
Marc G. Fournier wrote:
On Fri, 31 Oct 2003, Tatsuo Ishii wrote:
Nope, not for those items. There is still some thought of a very short
release cycle (a few months) for 7.5, and we could possibly address the
vacuum issue in that timeframe, if the recent ideas about it prove out.
I meant related to PITR? :)
On Thu, 30 Oct 2003, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Fri, 31 Oct 2003, Tatsuo Ishii wrote:
Nope, not for those items. There is still some thought of a very short
release cycle (a few months) for 7.5, and we could possibly address
Oh, sorry, only read your part --- I have not heard anything about PITR
from Patrick. I talked to him about a month ago and he hadn't made much
headway.
---
Marc G. Fournier wrote:
I meant related to PITR? :)
On
Marc G. Fournier [EMAIL PROTECTED] writes:
Does anyone have anything ready to put into CVS as soon as we start v7.5,
or shortly afterwards?
That brings up another question, which is when to create the
REL7_4_STABLE branch in CVS. Offhand I think it would be good to do it
when we make RC1; any
On Thu, Oct 30, 2003 at 09:51:24PM -0500, Doug McNaught wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 30 Oct 2003, David Fetter wrote:
Any chance of putting up a torrent for it? I'd be happy to
host, but I'd have to get the link on the downloads page somehow
:)
Tom Lane wrote:
Daniel Migowski [EMAIL PROTECTED] writes:
I miss the possibility to code something like a userdifined
varchar(n).
You're out of luck on that. The data types that can have precision
parameters attached to them are hard-wired into the parser.
Maybe you don't need to invent a whole
The world rejoiced as [EMAIL PROTECTED] (Joshua D. Drake) wrote:
2. More importantly the recent potential discovery by Jan on vacuum.
I have several high end users that are really beating their heads
against the wall with even lazy vacuum because of how brutal it can
be on the system. If
Tatsuo Ishii wrote:
Nope, not for those items. There is still some thought of a very short
release cycle (a few months) for 7.5, and we could possibly address the
vacuum issue in that timeframe, if the recent ideas about it prove out.
But there is no consensus on how to fix the
Joshua D. Drake wrote:
Sooner or later you have to say this release is done, let's ship it.
It's way too late to go back into invention mode for 7.4.
I agree with the argument. It is just that the Vacuum one... well is
very tempting.
Since improving the buffer cache policy will not change any
Jan Wieck [EMAIL PROTECTED] writes:
Since improving the buffer cache policy will not change any visible
functionality other than performance ... maybe you want to convince some
people that if we find a substantial improvement for the cache policy
soon to put it into a 7.4.x release.
It's
Stephan Szabo [EMAIL PROTECTED] writes:
On Thu, 30 Oct 2003, Tom Lane wrote:
rule/foreign key interaction reported by Michele Bendazzoli
In the interests of disclosure, if the case in question for the rule
fails, almost certainly deferred fk constraints will as well which I
think makes this
Bruce Momjian [EMAIL PROTECTED] writes:
One other idea would be to set CFLAGS to before including template,
and just test to see if it is still after --- that might be cleaner
than saving the original value and comparing.
Yeah, that bothered me a bit too --- what if the template tries to set
Personally, I think it is useful to have features. I quite understand the
difficulties in maintaining some features however. Also having worked on
internals for commercial DB engines, I have specifically how code/data paths
can be shortened. I would not make the choice for someone to be
Tom Lane wrote:
Attached is an extremely crude prototype patch for making VACUUM delay
by a configurable amount between pages,
Cool!
Assuming that this is found to be useful, the following issues would
have to be dealt with before the patch would be production quality:
2. I only bothered to
See attached regression.diffs.
Chris
parallel group (5 tests): select_views portals_p2 cluster foreign_key rules
select_views ... ok
portals_p2 ... ok
rules... FAILED
foreign_key ... ok
cluster ... ok
parallel
On Thu, 30 Oct 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
On Thu, 30 Oct 2003, Tom Lane wrote:
rule/foreign key interaction reported by Michele Bendazzoli
In the interests of disclosure, if the case in question for the rule
fails, almost certainly deferred fk
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
See attached regression.diffs.
Looks like Jan forgot to update this expected file to match his changes.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked
Matthew T. O'Connor [EMAIL PROTECTED] writes:
Tom Lane wrote:
2. I only bothered to insert delays in the processing loops of plain
VACUUM and btree index cleanup. VACUUM FULL and cleanup of non-btree
indexes aren't done yet.
I thought we didn't want the delay in vacuum full since it locks
Hey guys,
Is there any way we could build a static version of the 7.4 pg_dump, to
make it easy to dump existing databases using the 7.4 dump? Otherwise,
it's quite difficult to arrange to have two different postgres
installations, etc...
Chris
---(end of
70 matches
Mail list logo
