On Sun, Apr 05, 2009 at 05:57:46PM -0700, David Fetter wrote:
> On Sun, Apr 05, 2009 at 08:55:07PM -0400, Tom Lane wrote:
> > David Fetter writes:
> > > On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:
> > >> The \df thing? That's something it'd be okay to revisit during
> > >> beta, IMH
2009/4/7 Tom Lane :
> I wrote:
>> Bruce suggested what seemed like an excellent idea, which is to make
>> this self-documenting using the new default-arguments feature ---
>> it'll look something like this in \df:
>
>> List of functions
>> Schema | Name | Result data t
Alvaro Herrera writes:
> Tom Lane wrote:
>> If you're really intent on doing something about this, my inclination
>> would be to get rid of the dependence on DLNewElem altogether. Add
>> a Dlelem field to the Backend struct and use DLInitElem (compare
>> the way catcache uses that module).
> Hmm
Alvaro Herrera writes:
> So, the reason I started the thread about postmaster dying on OOM is
> that somebody asked me on IM what could have caused a backend to die
> with this backtrace:
[ of course you realize this is a backend, not the postmaster ]
> His question was: is it possible that we'r
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> I guess I need to point out that those ereport calls already pose a far
> >> more substantial risk of palloc failure than the DLNewElem represents.
>
> > Hmm, do they? I mean, don't they use ErrorContext, which is supposed to
> >
So, the reason I started the thread about postmaster dying on OOM is
that somebody asked me on IM what could have caused a backend to die
with this backtrace:
libc.so.1`_ndoprnt+0x14()
libc.so.1`fprintf+0x11d()
AllocSetStats+0x15d()
MemoryContextStatsInternal+0x1c()
MemoryContextStats+0xb()
AllocS
Itagaki Takahiro writes:
> BTW, why the function was named pg_stat_*user*_functions ?
> even though there are no 'all' and 'sys' versions.
Well, it ignores built-in functions. Naming the view that way seems
like good future-proofing to me --- maybe someday we'll think of a
sufficiently low-overh
Josh Berkus writes:
> Bruce,
> I drafted a list of major features for the release notes:
> http://wiki.postgresql.org/wiki/84ReleaseDraft#List_of_Major_Features_for_release_notes
> See if that works for you.
I did a small amount of polishing of some of those descriptions.
As of this evening there is nothing left on the 8.4 open-items list that
looks like a beta blocker:
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
We certainly have some bugs there, but nothing that seems to require
another initdb to fix or that would really get in the way of testing.
S
Alvaro Herrera writes:
> Bruce Momjian wrote:
>> Robert Treat reported to me that \dS tab completion was not working in
>> CVS HEAD. I have adjusted the code to handle this and be more flexible
>> about \d modifiers.
> Doesn't this break completion for stuff like \daS, etc?
AFAICS \daS still wo
Alvaro Herrera writes:
> Tom Lane wrote:
>> I guess I need to point out that those ereport calls already pose a far
>> more substantial risk of palloc failure than the DLNewElem represents.
> Hmm, do they? I mean, don't they use ErrorContext, which is supposed to
> be preallocated?
Well, we'd l
Tom Lane wrote:
> Alvaro Herrera writes:
> > I think a patch to solve this is as simple as the attached.
>
> I guess I need to point out that those ereport calls already pose a far
> more substantial risk of palloc failure than the DLNewElem represents.
Hmm, do they? I mean, don't they use Erro
On Apr 6, 2009, at 5:48 PM, Tom Lane wrote:
Andrew Gierth writes:
At the VERY LEAST, can we PLEASE have the zone.tab file
INSTALLED WHERE IT BELONGS rather than simply ignored, so that even
if
further requests to include the information in a system view go
unheard by -hackers, I can at leas
Andrew Gierth writes:
> At the VERY LEAST, can we PLEASE have the zone.tab file
> INSTALLED WHERE IT BELONGS rather than simply ignored, so that even if
> further requests to include the information in a system view go
> unheard by -hackers, I can at least provide a pgfoundry module or
> something
Josh Berkus wrote:
> I drafted a list of major features for the release notes:
> http://wiki.postgresql.org/wiki/84ReleaseDraft#List_of_Major_Features_for_release_notes
s/pg_stat_functions/pg_stat_user_functions/g
BTW, why the function was named pg_stat_*user*_functions ?
even though there are
Gregory Stark writes:
> Well, not that this is appropriate at this moment, but I had been considering
> proposing we do this to most of pg_proc and pg_operator. It's really quite a
> pain to maintain these files manually, especially pg_operator.
You won't get far with doing it to pg_proc: interna
Tom Lane writes:
> So I think that's out. The only alternative that comes to mind is
> to have initdb issue an additional SQL command to establish the default
> after the bootstrap phase; that is, something like
>
> CREATE OR REPLACE FUNCTION
> pg_start_backup(label text, fast boolean DEFAULT
Bruce,
I drafted a list of major features for the release notes:
http://wiki.postgresql.org/wiki/84ReleaseDraft#List_of_Major_Features_for_release_notes
See if that works for you.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
Back before 8.2 came out, I posted:
> Any view over the full timezone names should also include the
> corresponding data from zone.tab in the timezone library source.
I got no meaningful response to this (Tom responded with an erroneous
statement and ignored my explanation of his mistake).
Back
Alvaro Herrera writes:
> Tom Lane wrote:
>> The only alternative that comes to mind is
>> to have initdb issue an additional SQL command to establish the default
>> after the bootstrap phase; that is, something like
>>
>> CREATE OR REPLACE FUNCTION
>> pg_start_backup(label text, fast boolean DEFA
Alvaro Herrera writes:
> I think a patch to solve this is as simple as the attached.
I guess I need to point out that those ereport calls already pose a far
more substantial risk of palloc failure than the DLNewElem represents.
You seem to have forgotten about releasing the DLElem if the fork fa
Tom Lane wrote:
> The only alternative that comes to mind is
> to have initdb issue an additional SQL command to establish the default
> after the bootstrap phase; that is, something like
>
> CREATE OR REPLACE FUNCTION
> pg_start_backup(label text, fast boolean DEFAULT false)
> RETURNS text L
I wrote:
> Bruce suggested what seemed like an excellent idea, which is to make
> this self-documenting using the new default-arguments feature ---
> it'll look something like this in \df:
> List of functions
> Schema | Name | Result data type | Argument data
Tom Lane wrote:
> Alvaro Herrera writes:
> > Some time ago I noticed that in postmaster.c there's a corner case which
> > probably causes postmaster to exit in out-of-memory condition. See
> > BackendStartup, near the bottom, there's a call to DLNewElem(). The
> > problem is that this function c
Alvaro Herrera writes:
> Some time ago I noticed that in postmaster.c there's a corner case which
> probably causes postmaster to exit in out-of-memory condition. See
> BackendStartup, near the bottom, there's a call to DLNewElem(). The
> problem is that this function calls palloc() and thus can
Hi,
Some time ago I noticed that in postmaster.c there's a corner case which
probably causes postmaster to exit in out-of-memory condition. See
BackendStartup, near the bottom, there's a call to DLNewElem(). The
problem is that this function calls palloc() and thus can elog(ERROR) on
OOM, but po
It appears that I need to put together a custom parser for tsearch2.
The description here:
http://www.postgresql.org/docs/8.3/interactive/textsearch-parsers.html
makes it sound as though the default can be replaced, but I haven't
found any documentation of the API. Tom's post here:
http://a
On Wednesday 01 April 2009 20:37:56 Martijn van Oosterhout wrote:
> On Tue, Mar 31, 2009 at 11:33:26PM +0300, Peter Eisentraut wrote:
> > On Saturday 28 March 2009 00:42:28 Bruce Momjian wrote:
> > > I assume directory permissions controlling access to the socket file
> > > would be enough. You ar
"Kevin Grittner" writes:
> Tom Lane wrote:
>> I'm going to go ahead and make this happen, using the arrangement
>>
>> pg_start_backup('label') -> slow checkpoint (backwards compatible)
>> pg_start_backup('label', false) -> slow checkpoint
>> pg_start_backup('label', true) -> immediate checkpoin
Tom Lane wrote:
> I'm going to go ahead and make this happen, using the arrangement
>
> pg_start_backup('label') -> slow checkpoint (backwards compatible)
> pg_start_backup('label', false) -> slow checkpoint
> pg_start_backup('label', true) -> immediate checkpoint
Probably a dumb question, but
I wrote:
> Heikki Linnakangas writes:
>> Rather than deplore that you can't expedite the checkpoint, why don't we
>> just make it possible?
> +1
>> The first question is what the default behavior should be? We've seen
>> enough complaints and I've been bitten by that myself during development
On Monday 30 March 2009 15:52:37 Heikki Linnakangas wrote:
> In CVS HEAD, we call bind_textdomain_codeset() in SetDatabaseEncoding()
> which fixes that, but we only do it on Windows. In earlier versions we
> called it on all platforms, but only for UTF-8. It seems that we should
> call bind_textdom
Bruce Momjian wrote:
> Robert Treat reported to me that \dS tab completion was not working in
> CVS HEAD. I have adjusted the code to handle this and be more flexible
> about \d modifiers.
Doesn't this break completion for stuff like \daS, etc?
--
Alvaro Herrera
Robert Treat reported to me that \dS tab completion was not working in
CVS HEAD. I have adjusted the code to handle this and be more flexible
about \d modifiers.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is
On Mon, Apr 6, 2009 at 10:49 AM, Tom Lane wrote:
> Robert Haas writes:
>> Well, I think I was pretty clear about what I was trying to
>> accomplish. I think there are more people who care about pg_dump
>> output being diffable than there are who need to set ndistinct more
>> accurately than 1 pp
This looks good to me. I tested it to the extent of verifying that
either patch individually would prevent the originally-reported failure.
I'd be inclined to keep it but reduce it to level DEBUG1 or so.
Committed in HEAD, 8.3 and 8.2. Previous versions need to be patched too but
codebase is d
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Apr 6, 2009 at 7:30 AM, Stephen Frost wrote:
> > I do such diffs pretty often, but I don't think I've *ever* done it on
> > catalog tables.. Perhaps it'll come up in the future, but I doubt it.
>
> Well the point is when you dump a
Robert Haas writes:
> Well, I think I was pretty clear about what I was trying to
> accomplish. I think there are more people who care about pg_dump
> output being diffable than there are who need to set ndistinct more
> accurately than 1 ppm and yet not as an integer.
My, you *are* paranoid abo
On Mon, Apr 6, 2009 at 7:30 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Well, I think I was pretty clear about what I was trying to
>> accomplish. I think there are more people who care about pg_dump
>> output being diffable than there are who need to set ndistinct
higepon writes:
> I found a TODO item "pg_dump Add dumping of comments on index columns"
> for large objects.
> and want to write a patch for it.
I assume you mean $subject and not what you wrote here.
> I examined contrib/lo which offers this functionality.
Yes. I wonder why the TODO item is
The MSVC++ build system is a little lacking in it's ability to build
against different versions of Perl and TCL. The attached patch doesn't
fix that (unfortunately), but does update the hard-coded library names
so we can use Perl 5.10 and TCL 8.5 with PG 8.4.
--
Dave Page
EnterpriseDB UK: http:
* Robert Haas (robertmh...@gmail.com) wrote:
> Well, I think I was pretty clear about what I was trying to
> accomplish. I think there are more people who care about pg_dump
> output being diffable than there are who need to set ndistinct more
> accurately than 1 ppm and yet not as an integer. Pe
On Mon, Apr 6, 2009 at 11:27 AM, Robert Haas wrote:
> On Mon, Apr 6, 2009 at 3:52 AM, Dave Page wrote:
>> Argh! Some of us have already made those changes and spent quite some
>> time testing them for 8.4 :-(
>
> I feel your pain, but OTOH, if it's not possible to fix a feature that
> was introdu
On Mon, Apr 6, 2009 at 3:52 AM, Dave Page wrote:
> Argh! Some of us have already made those changes and spent quite some
> time testing them for 8.4 :-(
I feel your pain, but OTOH, if it's not possible to fix a feature that
was introduced in 8.4 before 8.4 has even gone to beta, that's setting
th
On Sun, Apr 5, 2009 at 11:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> (It's also worth pointing out that the calculations we do with
>> ndistinct are pretty approximations anyway. If the difference between
>> stadistinct = -1 x 10^-6 and stadistinct = -1.4^10-6 is the thing
>> that's determi
On Mon, Apr 6, 2009 at 2:49 AM, Greg Sabino Mullane wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
>> I think the objection that is most likely to be raised is that it would
>> confuse or break programs that analyze EXPLAIN output in any degree of
>> detail. Of course such pr
Hi.
I found a TODO item "pg_dump Add dumping of comments on index columns"
for large objects.
and want to write a patch for it.
I examined contrib/lo which offers this functionality.
I have two plans, can anybody give me some advice on these?
Plan A:
(1) Define a new type for large object
47 matches
Mail list logo
