Gregory Stark wrote:
Bruce Momjian 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. R
>> 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
2009/1/15 Bruce Momjian :
>
> 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.
tuplestore_advance seems
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 c
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 .
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.
> > >>> Sho
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
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 _
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 database
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 pu
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?
> >
> >
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
Is there anything to do with the below issue?
---
Pavan Deolasee wrote:
> On Wed, Dec 17, 2008 at 7:11 PM, Tom Lane wrote:
> >
> >
> > I think what you are suggesting is that we should set the visibility map
> > bit while d
Is this something for 8.4 CVS?
---
Pavan Deolasee wrote:
> On Mon, Dec 8, 2008 at 11:33 AM, Pavan Deolasee
> wrote:
>
> >
> >
> > On Sat, Dec 6, 2008 at 8:08 PM, Heikki Linnakangas <
> > heikki.linnakan...@enterprisedb.com
Bruce Momjian 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 it to,
say, 80
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
> autovacuu
Has this been addressed?
---
Hitoshi Harada wrote:
> 2008/12/3 Tom Lane :
> > If this means a lot of contortion/complication in the upper-level code,
> > seems like it'd be better to address the performance issue within
> >
Martijn van Oosterhout wrote:
> On Wed, Jan 14, 2009 at 09:52:20AM -0500, Tom Lane wrote:
>> Martijn van Oosterhout 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 w
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 :
> Koichi Suzuki wrote:
>> Pg_readahead is
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
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 approp
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 'dist
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 http://m
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
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:
>
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,
Magnus Hagander wrote:
> Tom Lane wrote:
> > Magnus Hagander 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?
> >
> > Hmm.
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-
> Has
Bruce Momjian writes:
> Tom Lane wrote:
>> Bruce Momjian 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
Tom Lane wrote:
> Bruce Momjian 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 b
Bruce Momjian 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 work
around what
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, inclu
Bruce Momjian wrote:
> Merlin Moncure wrote:
> > On 1/14/09, Bruce Momjian 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?
> > http:/
> 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 p
On Wed, Jan 14, 2009 at 09:52:20AM -0500, Tom Lane wrote:
> Martijn van Oosterhout 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 :
> 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 is
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 an
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/
--
S
> 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 sequ
Merlin Moncure wrote:
> On 1/14/09, Bruce Momjian 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?
> http://archives.free.net.ph/message/20081
On 1/14/09, Bruce Momjian 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?
http://archives.free.net.ph/message/20081116.053100.15b5801d.fi.html
We ha
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 c
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 format
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. Na
"Robert Haas" 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 it's kind of
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 be
On Wed, Jan 14, 2009 at 10:00 AM, Tom Lane wrote:
> Bruce Momjian 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
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
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);
> A
Bruce Momjian 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 portable: they work
Martijn van Oosterhout 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.
Wrong. W
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 a
Tom Lane wrote:
> Alvaro Herrera 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 table foo set (test
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 pre
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 p
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 a
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
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 plpgsq
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
> > t
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 tol
60 matches
Mail list logo
