Martijn van Oosterhout wrote:
On Tue, Jan 13, 2009 at 10:05:45AM -0300, Alvaro Herrera wrote:
pgace.h: you have a bunch of static inline functions in here. As far
as I know this doesn't work in compilers other than GCC :-( See
pg_list.h (list_head) for an example. I think we can tolerate
On Wed, 2009-01-14 at 08:27 +0200, Heikki Linnakangas wrote:
Thanks for picking this up, despite my report was so vague.
Simon Riggs wrote:
Best way seems to be to do (almost) the same thing as ExtendSubtrans()
during recovery, so we zero out pages at the point that recovering
Tom Lane wrote:
So what I'm thinking is:
1. We can't redefine the SPI interface in back branches, so there's
probably little alternative but to remove those Asserts there.
Committed this.
2. In HEAD, I think we should have SPI return a new SPI_OK_REWRITTEN
code for this case, and have
Martijn van Oosterhout wrote:
On Tue, Jan 13, 2009 at 10:05:45AM -0300, Alvaro Herrera wrote:
pgace.h: you have a bunch of static inline functions in here. As far
as I know this doesn't work in compilers other than GCC :-( See
pg_list.h (list_head) for an example. I think we can tolerate
Andrew Chernow wrote:
The problem with the current check is its only an AC_CHECK_FUNCS. We
need an AC_SEARCH_LIBS first so the proper -llibrary is appended to
LIBS, which is used by AC_CHECK_FUNCS.
AC_SEARCH_LIBS(gethostbyname_r, c nsl)
Just don't put c in there. You usually don't want an
AC_SEARCH_LIBS(gethostbyname_r, c nsl)
Just don't put c in there. You usually don't want an explicit -lc to
appear in your link commands.
Correct. Copied that from an internal project, which I should fix.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via
Koichi Suzuki wrote:
Pg_readahead is a tool to prefetch data pages before redoing, based on
the contents of archive/active WAL segment. For 8.3 and 8.4 without
sync.rep, this works together with restore_command. Pg_readahead
analyze WAL segment, schedule and issue posix_fadvise() to
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
This uses a new parse node.
You need at least equalfuncs.c support for that, and outfuncs would be
advisable.
Added.
One possible disadvantage is that a command
like this works, but does nothing:
alvherre=# alter
KaiGai Kohei wrote:
Martijn van Oosterhout wrote:
On Tue, Jan 13, 2009 at 10:05:45AM -0300, Alvaro Herrera wrote:
pgace.h: you have a bunch of static inline functions in here. As far
as I know this doesn't work in compilers other than GCC :-( See
pg_list.h (list_head) for an example. I
Martijn van Oosterhout klep...@svana.org writes:
On Tue, Jan 13, 2009 at 10:05:45AM -0300, Alvaro Herrera wrote:
pgace.h: you have a bunch of static inline functions in here. As far
as I know this doesn't work in compilers other than GCC :-(
Really? C99 requires it and MSVC does support it.
Bruce Momjian br...@momjian.us writes:
KaiGai Kohei wrote:
However, it also seems to me that PostgreSQL implementation tend to
avoid to use inline functions actively.
I thought one advantage of using macros is that we force the inlining,
The (only) good thing about macros is they're
Alvaro Herrera escreveu:
I wasn't sure of the best place to add a check. I have added it to
transformRelOptions; I am not entirely comfortable with it, because it
works, but it still allows this:
IMHO it's the appropriate place.
alvherre=# alter index f set (toast.fillfactor = 20);
ALTER
Tom Lane wrote:
If you ran the current sepostgres patch through an actual C99 compiler,
it would fail.
The current one (r1408) is reworked to use normal functions, and inlines
are eliminated. :-)
http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/include/security/sepgsql.h
On Wed, Jan 14, 2009 at 10:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
KaiGai Kohei wrote:
However, it also seems to me that PostgreSQL implementation tend to
avoid to use inline functions actively.
I thought one advantage of using macros is that we force
Euler Taveira de Oliveira wrote:
Alvaro Herrera escreveu:
I wasn't sure of the best place to add a check. I have added it to
transformRelOptions; I am not entirely comfortable with it, because it
works, but it still allows this:
IMHO it's the appropriate place.
I think the best place
Robert Haas robertmh...@gmail.com writes:
Just out of curiosity, does C89, or whatever standard we follow, allow this?
int
somefunc(int x)
{
int foo[x];
/* use foo[] for scratch space */
}
It's not in C89 but look up alloca.
We don't use it anywhere in postgres currently so
On Wednesday 14 January 2009 05:23:53 Tom Lane wrote:
However, since there's no standard strftime escape for epoch,
Robert's proposal to rip out the functionality would break any existing
code that still depends on this formatting option.
If it came down to this, then I'd say rip it out.
On Wed, 2009-01-14 at 18:37 +0200, Peter Eisentraut wrote:
On Wednesday 14 January 2009 05:23:53 Tom Lane wrote:
However, since there's no standard strftime escape for epoch,
Robert's proposal to rip out the functionality would break any existing
code that still depends on this formatting
Andrew Chernow wrote:
Forgot to mention, there is an easy fix:
~]# LDFLAGS=-lnsl ./configure --enable-thread-safety
But I assume that only works if I use gethostbyname_r(), right?
No, works for gethostbyname as well. They are all in libnsl.
But we do check for that in
On 1/14/09, Bruce Momjian br...@momjian.us wrote:
OK, patch attached and applied to CVS HEAD. The nsl (not 'nls') library
check was removed in Postgres 8.2 here:
As long as you are looking at this, can you take a peek at this patch?
Merlin Moncure wrote:
On 1/14/09, Bruce Momjian br...@momjian.us wrote:
OK, patch attached and applied to CVS HEAD. The nsl (not 'nls') library
check was removed in Postgres 8.2 here:
As long as you are looking at this, can you take a peek at this patch?
If it came down to this, then I'd say rip it out. Naming log files by epoch
isn't exactly a user-friendly practice anyway, and there are equivalent but
more readable formatting options available.
There are other alternatives but they're all ugly. For example, we
could make %0 (or some
Bruce Momjian wrote:
Also the
calling of the function with all null pointers seems dangerous,
Its only trying to compile it, AC_TRY_COMPILE, not execute it. I don't
think? the NULL pointers could ever raise havoc.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The attached patch put invocations of markColumnForSelectPriv()
at transformJoinUsingClause() to mark those columns are used.
Thanks for the update!
Attached is a patch which:
- incorporates KaiGai's latest patches to deal with JOINs and
It's not in C89 but look up alloca.
I know about alloca...
We don't use it anywhere in postgres currently so it's kind of unlikely we
would start now.
:-(
Obviously this is a bad plan if x can be a big number because you
might crash your stack, but suppose we know that's not an issue? It
On Wed, Jan 14, 2009 at 09:52:20AM -0500, Tom Lane wrote:
Martijn van Oosterhout klep...@svana.org writes:
On Tue, Jan 13, 2009 at 10:05:45AM -0300, Alvaro Herrera wrote:
pgace.h: you have a bunch of static inline functions in here. As far
as I know this doesn't work in compilers other
Here is a cleaned-up version. I fixed a number of whitespace issues,
improved a few comments, and rearranged one set of nested if-else
statements (hopefully without breaking anything in the process).
Josh / eggyknap -
Can you rerun your performance tests with this version of the patch?
Bruce Momjian wrote:
Merlin Moncure wrote:
On 1/14/09, Bruce Momjian br...@momjian.us wrote:
OK, patch attached and applied to CVS HEAD. The nsl (not 'nls') library
check was removed in Postgres 8.2 here:
As long as you are looking at this, can you take a peek at this patch?
What is the status on this?
---
Marcus Kempe wrote:
This patch adds the ability to retrieve async notifications using dblink,
via the addition of the function dblink_get_notify.
It is written against cvs head, includes
Bruce Momjian br...@momjian.us writes:
Is there any objection to applying this to 8.4?
Yes. I don't think we should bother with a one-operating-system patch
for an OS version that was obsolete ten years ago. (Even if I am still
running it ;-).) If we do this, the next thing will be trying to
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Is there any objection to applying this to 8.4?
Yes. I don't think we should bother with a one-operating-system patch
for an OS version that was obsolete ten years ago. (Even if I am still
running it ;-).) If we do this, the next
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Is there any objection to applying this to 8.4?
Yes. I don't think we should bother with a one-operating-system patch
for an OS version that was obsolete ten years ago. (Even if I am still
Added to TODO:
Have statement-level triggers fire for all tables in an
inheritance hierarchy
---
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
-BEGIN PGP SIGNED MESSAGE-
Hash:
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
I've noticed that pg_stat_all_tables returns NULL for idx_scan and
idx_tup_fetch if there are no indexes present on a table.
Is this actually intended, or is that something that should be fixed?
Bruce Momjian wrote:
Log Message:
---
Make 'find' syntax consistent; add .git exclusion to make_ctags.
Should this consider the distdir target in /GNUmakefile.in too?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting,
Would someone tell me why 'autovacuum_freeze_max_age' defaults to 200M
when our wraparound limit is around 2B?
Also, is anything being done about the concern about 'vacuum storm'
explained below?
---
Gregory Stark wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Log Message:
---
Make 'find' syntax consistent; add .git exclusion to make_ctags.
Should this consider the distdir target in /GNUmakefile.in too?
It only is looking for _directories_ to put 'tags' into.
--
Bruce Momjian
Alvaro Herrera wrote:
Bruce Momjian wrote:
Log Message:
---
Make 'find' syntax consistent; add .git exclusion to make_ctags.
Should this consider the distdir target in /GNUmakefile.in too?
Oh, I get it now, 'distdir'. Let me look.
--
Bruce Momjian br...@momjian.us
Alvaro Herrera wrote:
Bruce Momjian wrote:
Log Message:
---
Make 'find' syntax consistent; add .git exclusion to make_ctags.
Should this consider the distdir target in /GNUmakefile.in too?
Uh, I usually run the tag program from the /src directory where there is
no 'distdir',
Alvaro Herrera escreveu:
Euler Taveira de Oliveira wrote:
Alvaro Herrera escreveu:
I wasn't sure of the best place to add a check. I have added it to
transformRelOptions; I am not entirely comfortable with it, because it
works, but it still allows this:
IMHO it's the appropriate place.
Bruce Momjian wrote:
Would someone tell me why 'autovacuum_freeze_max_age' defaults to 200M
when our wraparound limit is around 2B?
Presumably because of this (from the docs):
The commit status uses two bits per transaction, so if
autovacuum_freeze_max_age has its maximum allowed value
Pg_readahead uses posix_fadvise, which is included in Greg's patch and
I've already posted pg_readahead patch integrated into the core.
Integration with snc.rep. will be a separate patch which will be
posted in a couple of days.
2009/1/14 Bruce Momjian br...@momjian.us:
Koichi Suzuki wrote:
Martijn van Oosterhout wrote:
On Wed, Jan 14, 2009 at 09:52:20AM -0500, Tom Lane wrote:
Martijn van Oosterhout klep...@svana.org writes:
On Tue, Jan 13, 2009 at 10:05:45AM -0300, Alvaro Herrera wrote:
pgace.h: you have a bunch of static inline functions in here. As far
as I know this doesn't
Has this been addressed?
---
Hitoshi Harada wrote:
2008/12/3 Tom Lane t...@sss.pgh.pa.us:
If this means a lot of contortion/complication in the upper-level code,
seems like it'd be better to address the performance
Andrew Dunstan wrote:
Bruce Momjian wrote:
Would someone tell me why 'autovacuum_freeze_max_age' defaults to 200M
when our wraparound limit is around 2B?
Presumably because of this (from the docs):
The commit status uses two bits per transaction, so if
Bruce Momjian br...@momjian.us writes:
Would someone tell me why 'autovacuum_freeze_max_age' defaults to 200M
when our wraparound limit is around 2B?
I suggested raising it dramatically in the post you quote and Heikki pointed
it controls the maximum amount of space the clog will take. Raising
Is this something for 8.4 CVS?
---
Pavan Deolasee wrote:
On Mon, Dec 8, 2008 at 11:33 AM, Pavan Deolasee
pavan.deola...@gmail.comwrote:
On Sat, Dec 6, 2008 at 8:08 PM, Heikki Linnakangas
Is there anything to do with the below issue?
---
Pavan Deolasee wrote:
On Wed, Dec 17, 2008 at 7:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think what you are suggesting is that we should set the visibility map
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Log Message:
---
Make 'find' syntax consistent; add .git exclusion to make_ctags.
Should this consider the distdir target in /GNUmakefile.in too?
Uh, I usually run the tag program from the /src directory
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Log Message:
---
Make 'find' syntax consistent; add .git exclusion to make_ctags.
Should this consider the distdir target in /GNUmakefile.in too?
Uh, I usually run the tag
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Log Message:
---
Make 'find' syntax consistent; add .git exclusion to make_ctags.
Should this consider the distdir target in /GNUmakefile.in too?
It only is looking for _directories_ to put 'tags' into.
I
Stephen, I could find a strange behavior unfortunatelly. :-)
(But it is obvious one, don't worry.)
postgres=# CREATE TABLE t1 (a int, b int, c int);
CREATE TABLE
postgres=# ALTER TABLE t1 DROP COLUMN c;
ALTER TABLE
postgres=# \c - ymj
psql (8.4devel)
You are now connected to
Alvaro Herrera escreveu:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Log Message:
---
Make 'find' syntax consistent; add .git exclusion to make_ctags.
Should this consider the distdir target in /GNUmakefile.in too?
It only is looking for _directories_ to put
Euler Taveira de Oliveira wrote:
Alvaro Herrera escreveu:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Log Message:
---
Make 'find' syntax consistent; add .git exclusion to make_ctags.
Should this consider the distdir target in /GNUmakefile.in too?
It
Bruce Momjian wrote:
Euler Taveira de Oliveira wrote:
Alvaro Herrera escreveu:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Log Message:
---
Make 'find' syntax consistent; add .git exclusion to make_ctags.
Should this consider the distdir target
Alvaro Herrera wrote:
Bruce Momjian wrote:
Euler Taveira de Oliveira wrote:
Alvaro Herrera escreveu:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Log Message:
---
Make 'find' syntax consistent; add .git exclusion to make_ctags.
Should
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Stephen, I could find a strange behavior unfortunatelly. :-)
Glad you're finding these, honestly. Better to find them and deal with
them now than after a release.
It is a case to be failed because 'ymj' has no privileges on t1
and its
2009/1/15 Bruce Momjian br...@momjian.us:
Has this been addressed?
It is mentioned at
http://archives.postgresql.org/pgsql-hackers/2008-12/msg01849.php
* Look at tuplestore performance issues. The tuplestore_in_memory()
thing is just a band-aid, we ought to try to solve it properly.
BTW, what is the official reviewer's opinion?
It seems to me most of the issues on column-level privileges are
resolved, so it is almost ready for getting merged.
I tend to doubt Tom's had a chance to review it again yet, which is
fine, though I'm certainly hopeful the recent focus and our
Gregory Stark wrote:
Bruce Momjian br...@momjian.us writes:
Would someone tell me why 'autovacuum_freeze_max_age' defaults to 200M
when our wraparound limit is around 2B?
I suggested raising it dramatically in the post you quote and Heikki pointed
it controls the maximum amount of space the
60 matches
Mail list logo
