Tom Lane píše v ne 05. 04. 2009 v 17:44 -0400:
Zdenek Kotala zdenek.kot...@sun.com writes:
Zdenek Kotala píše v út 31. 03. 2009 v 21:25 +0200:
Another possibility is to rewrite postgres(and pg_resetxlog) to use
getopt_long() instead of getopt().
Attached patch rewrites postgres to use
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
On Mon, Apr 6, 2009 at 2:49 AM, Greg Sabino Mullane g...@turnstep.com 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
On Sun, Apr 5, 2009 at 11:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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 =
On Mon, Apr 6, 2009 at 11:27 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Apr 6, 2009 at 3:52 AM, Dave Page dp...@pgadmin.org 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
* 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.
On Mon, Apr 6, 2009 at 3:52 AM, Dave Page dp...@pgadmin.org 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,
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:
higepon hige...@gmail.com 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
On Mon, Apr 6, 2009 at 7:30 AM, Stephen Frost sfr...@snowman.net 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
Robert Haas robertmh...@gmail.com 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
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
On Mon, Apr 6, 2009 at 7:30 AM, Stephen Frost sfr...@snowman.net 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
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
On Mon, Apr 6, 2009 at 10:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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 br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+
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
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
I wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
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 are going
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:
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
Alvaro Herrera alvhe...@commandprompt.com 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
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
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:
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
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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,
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
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
Tom Lane t...@sss.pgh.pa.us 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
Gregory Stark st...@enterprisedb.com 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
Josh Berkus j...@agliodbs.com 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
Andrew Gierth and...@tao11.riddles.org.uk 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
On Apr 6, 2009, at 5:48 PM, Tom Lane wrote:
Andrew Gierth and...@tao11.riddles.org.uk 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
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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?
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.
Josh Berkus j...@agliodbs.com 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.
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp 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
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()
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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:
Alvaro Herrera alvhe...@commandprompt.com 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
2009/4/7 Tom Lane t...@sss.pgh.pa.us:
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
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 da...@fetter.org 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,
48 matches
Mail list logo
