This is now the first entry on the new 8.4 Open Items list:
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Tom Lane wrote:
I would think this is overkill, except I've made the same darn mistake
one time too many. It seems clear to me that a lot of other people will
make it too, and if the error message isn't more helpful a lot of time
will get wasted. Barring loud objections, I'm gonna go change
On Tue, 2008-10-07 at 11:46 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-10-07 at 10:35 -0400, Tom Lane wrote:
I wonder whether this could be helped if we refactored pg_constraint.
Sounds better. Doesn't make much sense as it is now.
I looked at the code
Simon Riggs wrote:
(That in itself is painful, surely DDL should fail if
it sees another DDL statement in progress trying to do same thing).
Surely not. The other transaction doing the DDL might roll back.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via
Heikki Linnakangas [EMAIL PROTECTED] writes:
Yes, please. At least DB2 allows recursive queries without the
RECURSIVE keyword, just WITH is enough. Without a hint, anyone
migrating from such a system will spend hours looking at the query,
seeing nothing wrong.
Huh, interesting ... so
Hi all,
I am building Postgres using Eclipse with the CDT plugins (pre-packaged
distrib from eclipse.org). I am wondering if anyone else is using
Eclipse here?
If I am not the only one, we could setup a page on the Wiki explaining
how to setup the project under Eclipse and share our settings.
I am sorry - It was noise, probably some fedora update issue, after
restart all compilation is done.
Regards
Pavel Stehule
2008/10/8 Markus Wanner [EMAIL PROTECTED]:
Hi,
Pavel Stehule wrote:
compilation pg8.4 finished with error
Have you tried 'make distclean'?
What gcc version is
Pavel Stehule [EMAIL PROTECTED] writes:
compilation pg8.4 finished with error
In file included from ../../../../src/include/access/xlog.h:20,
from ../../../../src/include/access/hash.h:24,
from catcache.c:19:
../../../../src/include/utils/timestamp.h:312:
On Wed, Oct 8, 2008 at 1:51 PM, Emmanuel Cecchet [EMAIL PROTECTED] wrote:
Hi all,
I am building Postgres using Eclipse with the CDT plugins (pre-packaged
distrib from eclipse.org). I am wondering if anyone else is using Eclipse
here?
If I am not the only one, we could setup a page on the
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
What we can do is keep a list of not yet parsed WITH-names in ParseState,
and check through that list when about to fail for relation-not-found, and
issue a suitable message hinting that maybe you forgot RECURSIVE if we
iihero [EMAIL PROTECTED] writes:
But I found new issues now. (the latest code from cvs)
1. file : contrib\fuzzystrmatch\dmetaphone.c,
line: 1040 and line: 464, both look like as below,
case '?:
There is no the matched single quote, and the content is repeated. This
cause build always
Hello
compilation pg8.4 finished with error
make[4]: Leaving directory `/home/pavel/src/pgsql/src/backend/utils/adt'
make -C cache all
make[4]: Entering directory `/home/pavel/src/pgsql/src/backend/utils/cache'
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement
Dave Page wrote:
I don't know of anyone else actually working that way, but I've
certainly heard of people wanting to. It would be good if you can
document what you've done for their benefit.
Any recommendation where I should setup the page?
manu
--
Sent via pgsql-hackers mailing list
Heikki Linnakangas wrote:
I was thinking of a transaction that's just prepared (1st phase), but
not committed or rolled back:
postgres=# CREATE TEMP TABLE foo (bar int);
CREATE TABLE
postgres=# BEGIN;
BEGIN
postgres=# DROP TABLE foo;
DROP TABLE
postgres=# PREPARE TRANSACTION '2pc';
PREPARE
Simon Riggs wrote:
* optional recovery_safe_start_location parameter now provided in
recovery.conf, to allow a consistency point to be manually defined if a
base backup was not taken using standard pg_start/stop backup functions
Do we want to cater for that? It only seems safe if you have
Minor bug fix for pg_stop_backup() to prevent it waiting longer than
necessary in certain circumstances.
Was originally part of recovery_infrastructure patch.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Index: src/backend/access/transam/xlog.c
Emmanuel Cecchet [EMAIL PROTECTED] writes:
Thanks for the example, I get it now. Does it make sense to allow any
request execution between PREPARE TRANSACTION and the subsequent COMMIT
or ROLLBACK?
Yes. Don't even think of trying to disallow that. The COMMIT doesn't
even have to happen in
On Tue, Oct 7, 2008 at 9:58 PM, Tom Lane [EMAIL PROTECTED] wrote:
* Instead of the above, we could try to make
ROW(some columns) = ANY (array variable)
work. This is shorter than the above syntax and would presumably have
a lot less overhead too. But it doesn't work right now, not
On Wed, 2008-10-08 at 11:24 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
(That in itself is painful, surely DDL should fail if
it sees another DDL statement in progress trying to do same thing).
Surely not. The other transaction doing the DDL might roll back.
Maybe so, but trying
On Wed, 2008-10-08 at 14:43 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
* optional recovery_safe_start_location parameter now provided in
recovery.conf, to allow a consistency point to be manually defined if a
base backup was not taken using standard pg_start/stop backup functions
Emmanuel Cecchet wrote:
Also, even if the table is created and dropped in the same
transaction, a subsequent transaction that tries to create and drop
the table gets blocked on the lock. I suppose we could just say that
that's the way it works, but I'm afraid it will come as a nasty
surprise,
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2008-10-08 at 11:24 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
(That in itself is painful, surely DDL should fail if
it sees another DDL statement in progress trying to do same thing).
Surely not. The other transaction doing the DDL
Hi,
Pavel Stehule wrote:
compilation pg8.4 finished with error
Have you tried 'make distclean'?
What gcc version is shipped with fc10? I'm building CVS HEAD just fine
on debian lenny with gcc 4.3.1. The buildfarm doesn't show any such
failure either with various other gcc versions.
Regards
On Wed, Oct 8, 2008 at 2:11 PM, Emmanuel Cecchet [EMAIL PROTECTED] wrote:
Dave Page wrote:
I don't know of anyone else actually working that way, but I've
certainly heard of people wanting to. It would be good if you can
document what you've done for their benefit.
Any recommendation where
Tom Lane wrote:
Emmanuel Cecchet [EMAIL PROTECTED] writes:
Thanks for the example, I get it now. Does it make sense to allow any
request execution between PREPARE TRANSACTION and the subsequent COMMIT
or ROLLBACK?
Yes. Don't even think of trying to disallow that. The COMMIT doesn't
I am building Postgres using Eclipse with the CDT plugins (pre-packaged
distrib from eclipse.org). I am wondering if anyone else is using
Eclipse here?
I've been using Eclipse to build and debug postgres for the past couple
of years. There's nothing to it really, since all it does is call
Emmanuel Cecchet [EMAIL PROTECTED] writes:
Ok, so actually I don't see any different behavior between a temp table
or a regular table. The locking happens the same way and as long as the
commit prepared happens (potentially in another session), the lock is
released at commit time which
So I gave up waiting for someone else to do the reloptions patch for
autovacuum and started work on it myself. What I soon discovered is
that on first blush it seems a lot easier than I had expected.
On second look, however, the problem is that I seem to be
forced to declare all the
Alvaro Herrera [EMAIL PROTECTED] writes:
On second look, however, the problem is that I seem to be
forced to declare all the autovacuum-related options and their parsing
properties in reloptions.c. This seems very ugly.
That was in fact the intended design, and is why the functions exist in
a
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On second look, however, the problem is that I seem to be
forced to declare all the autovacuum-related options and their parsing
properties in reloptions.c. This seems very ugly.
That was in fact the intended design, and is why
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, OK. However, given that the various AMs amoptions also use
default_reloptions, they are going to accept the autovacuum options too.
Is that OK?
Well, we might want to split default_reloptions into two versions,
one for heaps and the other for
Alvaro Herrera [EMAIL PROTECTED] writes:
Before we waste too much time thinking how this registering is to be
done, does anybody think that the current approach is OK and thus I
should just add the autovacuum options directly into StdRdOptions and
default_reloptions?
Given Simon's suggestion
The thread here
http://archives.postgresql.org/pgsql-performance/2008-10/msg00031.php
illustrates an undesirable side effect of the recent patch to delay
table file unlinks to the next checkpoint. What is evidently happening
is that copydir() fetches a block of a directory, and by the time it
Gregory Stark [EMAIL PROTECTED] writes:
I wonder if we could piggy-back on guc parameters.
God, no. GUC is hopelessly complex already, we should *not* try to make
it track different values of a parameter for different tables.
Attaching a reloptions-like column to pg_tablespace might not be
Please checkout the patch that adds the PLUGINS functionality in
src/makefiles/pgxs.mk it covers the Unix side of functionality. Thanks.
Date: Sat, 13 Sep 2008 10:33:30 +0300
To: [EMAIL PROTECTED]
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] PLUGINS Functionlity in Win32 build
KaiGai Kohei wrote:
Robert Haas wrote:
Can you *do* the row-level permission?
I don't think there's any consensus on a design.
Yes, unfortunatelly.
No one replied to my proposed design:
http://marc.info/?l=pgsql-hackersm=12470930544w=2
Yes, we got stuck on the covert channels
Bruce Momjian wrote:
To summarize, 70% of the SE-Linux patch is in stand-alone C files, which
has little disruption, but 30% are changes to the core backend code,
which will be disruptive, so we would like to have SQL-level permissions
that everyone uses to be that disruption, and have
Tom Lane wrote:
The thread here
http://archives.postgresql.org/pgsql-performance/2008-10/msg00031.php
illustrates an undesirable side effect of the recent patch to delay
table file unlinks to the next checkpoint. What is evidently happening
is that copydir() fetches a block of a directory, and
On Mon, 2008-10-06 at 17:25 +0900, KaiGai Kohei wrote:
What should I do during the remaining 25 days?
I haven't been following this much, but I note that there is lots of
confusion over the international standards, guidelines, recommendations,
specifications etc that we should be following.
Heikki Linnakangas [EMAIL PROTECTED] writes:
Another thought is to ignore ENOENT in copydir.
Yeah, I thought about that too, but it seems extremely dangerous ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Hi,
Trigger functions are supposed to be able to be called only as triggers,
but apparently the check is not working in CVS HEAD:
alvherre=# create or replace function foo () returns trigger as $$ begin
perform 1; return new; end; $$ language plpgsql;
CREATE FUNCTION
alvherre=# select foo();
I get the same thing on 8.2.9.
...Robert
On Wed, Oct 8, 2008 at 2:29 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Hi,
Trigger functions are supposed to be able to be called only as triggers,
but apparently the check is not working in CVS HEAD:
alvherre=# create or replace function foo ()
am Wed, dem 08.10.2008, um 14:29:23 -0400 mailte Alvaro Herrera folgendes:
Hi,
Trigger functions are supposed to be able to be called only as triggers,
but apparently the check is not working in CVS HEAD:
alvherre=# create or replace function foo () returns trigger as $$ begin
perform
On Wed, Oct 8, 2008 at 3:56 PM, A. Kretschmer
[EMAIL PROTECTED] wrote:
am Wed, dem 08.10.2008, um 14:29:23 -0400 mailte Alvaro Herrera folgendes:
Hi,
Trigger functions are supposed to be able to be called only as triggers,
but apparently the check is not working in CVS HEAD:
alvherre=#
A. Kretschmer wrote:
am Wed, dem 08.10.2008, um 14:29:23 -0400 mailte Alvaro Herrera folgendes:
Hi,
Trigger functions are supposed to be able to be called only as triggers,
but apparently the check is not working in CVS HEAD:
alvherre=# create or replace function foo () returns
Merlin Moncure [EMAIL PROTECTED] writes:
On Tue, Oct 7, 2008 at 9:58 PM, Tom Lane [EMAIL PROTECTED] wrote:
* Instead of the above, we could try to make
ROW(some columns) = ANY (array variable)
work. This is shorter than the above syntax and would presumably have
a lot less overhead too. But
Tom Lane wrote:
It seems like something like that could work. I'd be inclined to change
the ereport() macro itself, not errmsg/errdetail/etc. The domain name
could be passed in at ereport and then used when evaluating the
messages.
This seems to work fine. Modules would provide their
Alvaro Herrera [EMAIL PROTECTED] writes:
Now, the obvious big problem I have with this patch is that I have to
pass plpgsql's locale path to bindtextdomain(), but I'm not seeing any
decent way to do that ... ideas?
Shouldn't it just use the same locale path as the backend? Or are you
stuck
Alvaro Herrera wrote:
Now, the obvious big problem I have with this patch is that I have to
pass plpgsql's locale path to bindtextdomain(), but I'm not seeing any
decent way to do that ... ideas?
I think the best way to do this is to stash the library path being
loaded where _PG_init can find
Alvaro Herrera [EMAIL PROTECTED] writes:
Trigger functions are supposed to be able to be called only as triggers,
but apparently the check is not working in CVS HEAD:
Hmm, some experimentation shows that 7.4 is the only active branch that
throws an error for that. Did we change it
(i586)
VERSION = 9
PATCHLEVEL = 3
[EMAIL PROTECTED]:~ /usr/local/pgsql-8.4dev-20081008/bin/pg_config
BINDIR = /usr/local/pgsql-8.4dev-20081008/bin
DOCDIR = /usr/local/pgsql-8.4dev-20081008/share/doc
HTMLDIR = /usr/local/pgsql-8.4dev-20081008/share/doc
INCLUDEDIR = /usr/local/pgsql-8.4dev-20081008
Alvaro Herrera [EMAIL PROTECTED] writes:
Trigger functions are supposed to be able to be called only as triggers,
but apparently the check is not working in CVS HEAD:
I traced through this, and what is happening is that the validator's
trial compilation of the function doesn't complain (as
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Now, the obvious big problem I have with this patch is that I have to
pass plpgsql's locale path to bindtextdomain(), but I'm not seeing any
decent way to do that ... ideas?
Shouldn't it just use the same locale path as the
Alvaro Herrera [EMAIL PROTECTED] writes:
Would anybody object to this?
I don't think this will work desirably at all ... get_locale_path
assumes that it's given a path to $installdir/bin/someexecutable,
not wherever shared libraries might have come from.
regards, tom
Kevin Grittner [EMAIL PROTECTED] writes:
I've got the database down to the minimum database objects needed for
the query (three tables, five views on them, and a bunch of domains),
and gotten those tables down to 10% of their original size, with all
confidential data turned to meaningless
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Would anybody object to this?
I don't think this will work desirably at all ... get_locale_path
assumes that it's given a path to $installdir/bin/someexecutable,
not wherever shared libraries might have come from.
Hmm, OK, I'll see
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
--- this looks like it could result in passing a NULL to dgettext,
somewhere along the line. Probably safer to pass postgres.
Hmm, I was trusting that dgettext is documented to accept a NULL as
meaning use the domain previously set
Attached are two and a half fixes for problems in psql's
describeOneTableDetails function.
1) After PQclear(res) we must null res out, so that later error handling
cleanup doesn't try to PQclear it again.
2) In error cleanup we cannot call printTableCleanup unless we've called
All,
I was discussing WITH RECURSIVE the other day, and realized that one thing
which we're not getting with this patch is a simplest-case simple syntax
which 75% of users are looking for. You know, the ones with simple
proximity trees who just want to find all children of one parent.
Would
Tom Lane wrote:
Another way, which would save some amount of string constant space,
is to have both elog_finish and the ereport macro pass NULL, and let
errstart insert the default:
+ edata-domain = domain ? domain : postgres;
Otherwise we'll have at least one copy of postgres per
... and here it is with equivalent definitions added for plperl,
plpython and pltcl. (Notably missing in this patch are the necessary
nls.mk files).
I note that this opens the door to contrib modules (and others) wanting
to provide translations, but I'm not going there for now.
--
Alvaro
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Another way, which would save some amount of string constant space,
is to have both elog_finish and the ereport macro pass NULL, and let
errstart insert the default:
Hmm, true. I think this means we need to redefine ereport(), not
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, true. I think this means we need to redefine ereport(), not just
TEXTDOMAIN, in each module (in fact it makes TEXTDOMAIN goes away as a
symbol). Same number of lines on each module though, so it's not a
considerable
Bruce Momjian wrote:
Yes, I have had similar experiences in Linux kernel development for
several years.
The amount of time to get consensus is one of the reason why I want
to move the SQL based row-level security to v8.5 development cycle.
As I stated before, I think doing an SE-Linux version
Simon Riggs wrote:
On Mon, 2008-10-06 at 17:25 +0900, KaiGai Kohei wrote:
What should I do during the remaining 25 days?
I haven't been following this much, but I note that there is lots of
confusion over the international standards, guidelines, recommendations,
specifications etc that we
iihero wrote:
Thanks. Now the header file include issues resolved. I fetch the latest
code and no such issues.
But I found new issues now. (the latest code from cvs)
1. file : contrib\fuzzystrmatch\dmetaphone.c,
line: 1040 and line: 464, both look like as below,
case '?:
There is
Alvaro Herrera [EMAIL PROTECTED] wrote:
So I gave up waiting for someone else to do the reloptions patch for
autovacuum and started work on it myself.
Is it needed to keep backward compatibility?
I'd like to suggest to keep pg_catalog.pg_autovacuum as a system view
even after the options is
Josh Berkus escreveu:
All,
I was discussing WITH RECURSIVE the other day, and realized that one thing
which we're not getting with this patch is a simplest-case simple syntax
which 75% of users are looking for. You know, the ones with simple
proximity trees who just want to find all
Alvaro Herrera wrote:
Tom Lane wrote:
No, you could have TEXTDOMAIN be defined as NULL by default, and let
modules redefine it as foo.
Doh, right.
So this'd seem to be the version ready to be applied (plus the needed
nls.mk files).
--
Alvaro Herrera
Hello
2008/10/9 Josh Berkus [EMAIL PROTECTED]:
All,
I was discussing WITH RECURSIVE the other day, and realized that one thing
which we're not getting with this patch is a simplest-case simple syntax
which 75% of users are looking for. You know, the ones with simple
proximity trees who
Alvaro Herrera [EMAIL PROTECTED] writes:
So this'd seem to be the version ready to be applied (plus the needed
nls.mk files).
I'm down to two seriously trivial nitpicks:
* preferably has one r.
+ const char *domain; /* message domain, NULL if
default */
This
Hello all,
Here is a proof-of-concept patch for reducing the alignment
requirement for heap tuples on 64-bit systems.
This patch passes the regression tests and a couple of other data sets
I have thrown at it.
I am hoping to get some early feedback on this patch so I have time to
make any
On Wed, Oct 08, 2008 at 04:11:45PM -0700, Josh Berkus wrote:
All,
I was discussing WITH RECURSIVE the other day, and realized that one thing
which we're not getting with this patch is a simplest-case simple syntax
which 75% of users are looking for. You know, the ones with simple
73 matches
Mail list logo
