On Sat, Jul 26, 2008 at 01:56:14PM -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I want to dump tables separately for performance reasons. There are
> > documented tests showing 100% gains using this method. There is no gain
> > adding this to pg_restore. There is a gain to b
On Mon, Jul 21, 2008 at 03:43:11AM -0400, Tom Lane wrote:
> daveg <[EMAIL PROTECTED]> writes:
> > On Sun, Jul 20, 2008 at 02:50:50PM -0400, Tom Lane wrote:
> >> In most cases our policy has been that pg_dumpall should accept and pass
> >> through any pg_dump option
On Sun, Jul 20, 2008 at 02:50:50PM -0400, Tom Lane wrote:
> daveg <[EMAIL PROTECTED]> writes:
> > Here is an updated version of this patch against head. It builds, runs and
> > functions as expected. I did not build the sgml.
>
> Applied with mostly minor cosmetic impro
On Sun, Jul 20, 2008 at 09:18:29PM -0400, Stephen Frost wrote:
> * Simon Riggs ([EMAIL PROTECTED]) wrote:
> > On Sun, 2008-07-20 at 17:43 -0400, Stephen Frost wrote:
> > > Even this doesn't cover everything though- it's too focused on tables
> > > and data loading. Where do functions go? What abo
Here is an updated version of this patch against head. It builds, runs and
functions as expected. I did not build the sgml.
I've made changes based on various comments as follows:
- use WAIT_TIME in description consistantly. Reworded for clarity.
(Stephan Frost)
- Use a separate query b
On Thu, Jul 03, 2008 at 05:55:01AM -0700, daveg wrote:
> On Thu, Jul 03, 2008 at 11:15:10AM +0300, Marko Kreen wrote:
> > On 5/11/08, daveg <[EMAIL PROTECTED]> wrote:
> > > Attached is a patch to add a commandline option to pg_dump to limit how
> > > long
&
On Thu, Jul 03, 2008 at 11:15:10AM +0300, Marko Kreen wrote:
> On 5/11/08, daveg <[EMAIL PROTECTED]> wrote:
> > Attached is a patch to add a commandline option to pg_dump to limit how
> > long
> > pg_dump will wait for locks during startup.
>
> My quic
On Wed, Jul 02, 2008 at 09:01:18AM -0700, David Fetter wrote:
> On Wed, Jul 02, 2008 at 05:57:29PM +0200, Peter Eisentraut wrote:
> > It would also be interesting if EXPLAIN could optionally be a
> > function that returns a datum of type XML, to allow further
> > processing.
>
> It would be better
On Tue, Jun 24, 2008 at 10:41:07PM -0400, Tom Lane wrote:
> daveg <[EMAIL PROTECTED]> writes:
> > Are we talking about the same patch?
>
> Maybe not --- I thought you were talking about a backend-side behavioral
> change.
>
> > Because I don't know wh
On Tue, Jun 24, 2008 at 05:34:50PM -0400, Tom Lane wrote:
> daveg <[EMAIL PROTECTED]> writes:
> > lock-timeout sets statement_timeout to a small value while locks are being
> > taken on all the tables. Then it resets it to default. So it could reset it
> > to
On Mon, Jun 23, 2008 at 07:30:53PM -0400, Bruce Momjian wrote:
> daveg wrote:
> > On Mon, Jun 23, 2008 at 06:51:28PM -0400, Bruce Momjian wrote:
> > > Alex Hunsaker wrote:
> > > > On Wed, Apr 16, 2008 at 4:54 PM, Alvaro Herrera
> > > > <[EMAIL PROTECT
On Mon, Jun 23, 2008 at 06:51:28PM -0400, Bruce Momjian wrote:
> Alex Hunsaker wrote:
> > On Wed, Apr 16, 2008 at 4:54 PM, Alvaro Herrera
> > <[EMAIL PROTECTED]> wrote:
> > > Joshua D. Drake escribi?:
> > >
> > > > That is an interesting idea. Something like:
> > > >
> > > > pg_restore -E "SET ST
On Thu, Jun 12, 2008 at 12:33:57PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Mon, Jun 09, 2008 at 05:56:59PM -0700, Neil Conway wrote:
> >> I'm not necessarily opposed to this, but I wonder if we really need
> >> *more* syntax variants for declaring set-returning func
On Sun, Jun 01, 2008 at 08:50:13PM -0400, Stephen Frost wrote:
> * daveg ([EMAIL PROTECTED]) wrote:
> > The feature that the proposed patch enables is to create pg_dump custom
> > format archives for multiple tables with a predicate. No amount of csv or
> > xml will do th
On Sun, Jun 01, 2008 at 04:40:15PM -0400, Andrew Dunstan wrote:
> daveg wrote:
> >
> >I can't imagine many of my clients ever writing another C program or even
> >being willing to pay me to do so. While modularizing pg_dump is a fine
> >idea,
> >I don&#x
On Sun, Jun 01, 2008 at 04:13:34PM -0400, Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> >Davy Durham <[EMAIL PROTECTED]> writes:
> >
> >>So, if this patch is not acceptable as-is, what would you feel about
> >>this:
> >>I could enhance the -t/--table=NAME option to accept more than a
On Sat, May 24, 2008 at 12:27:16AM -0300, Dickson S. Guedes wrote:
> Hi all,
>
> These patch implements the TODO item: Have psql show current values
> for a sequence.
> Comments are welcome.
>
> Sequence "public.foo_bar_seq"
> +---+-+-+
> |Col
On Sat, May 17, 2008 at 06:55:27PM -0300, Euler Taveira de Oliveira wrote:
> daveg wrote:
>
> >I originally sent this a week ago, but there was no response and I do not
> >see it
> >
> Nope. FYI, the right link is [1] and your patch [2] is in the queue for
> J
I originally sent this a week ago, but there was no response and I do not
see it at:
http://momjian.postgresql.org/cgi-bin/pgpatches
or
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
so I assume it got missed in all the excitement about the psql banner.
-
Subject: [PATCHES] pg_dump
On Thu, May 15, 2008 at 10:20:53AM -0700, Ron Mayer wrote:
> Alvaro Herrera wrote:
> >Andrew Dunstan wrote:
> >
> >>Welcome to UI development. There is always *far* more argument of minor
> >>matters of appearance than over anything else, in my experience.
> >
> >Which is a good thing (in this ca
On Wed, May 14, 2008 at 10:52:43AM -0400, Bruce Momjian wrote:
>
> One idea would be to add the libpq hooks but not document them. This
> way, we can modify or remove the API as needed in the future. As
> libpqtypes matures and we are sure what the API should be, we can
> document it as stable a
On Sun, May 11, 2008 at 04:30:47AM -0700, daveg wrote:
>
> Attached is a patch to add a commandline option to pg_dump to limit how long
> pg_dump will wait for locks during startup.
Ooops, really attached this time.
-dg
--
David Gould [EMAIL PROTECTED] 510 536 1443
Attached is a patch to add a commandline option to pg_dump to limit how long
pg_dump will wait for locks during startup.
The intent of this patch is to allow pg_dump to fail if a table lock cannot
be taken in a reasonable time. This allows the caller of pg_dump to retry or
otherwise correct the s
On Fri, Apr 11, 2008 at 06:25:53PM -0400, Tom Lane wrote:
> Andrew Chernow <[EMAIL PROTECTED]> writes:
> > A more graceful solution would be to print something to stderr and then
> > exit.
>
> stderr doesn't exist, or point to a useful place, in many environments.
> And a forced exit() is no bett
On Thu, Apr 03, 2008 at 01:19:21PM -0400, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > I think you have to find a syntax where the current commands continue to
> > mean
> > exactly what they always meant and where typos can't result in an entirely
> > different kind of behaviour
On Sat, Aug 04, 2007 at 09:04:33PM +0100, Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> >> The scenario I was describing was having, for example, 20 fields each
> >> of which are char(100) and store 'x' (which are padded with 99
> >
On Mon, Jul 09, 2007 at 06:13:54PM +0100, Gregory Stark wrote:
> I'm not suggesting making dblink super-user only. Only revoking public execute
> bits in the default install script. That doesn't affect users upgrading so I
> don't see a backwards-compatibility issue.
>
> The doc changes are going
On Mon, May 14, 2007 at 11:19:23PM -0400, Greg Smith wrote:
> On Mon, 14 May 2007, Tom Lane wrote:
>
> >If you can write something like that, why do we need the parameter at all?
>
> Couple of reasons:
>
> -As I already mentioned in my last message, I think it's unwise to let the
> LRU writes g
On Mon, May 14, 2007 at 11:55:07AM -0500, Jim C. Nasby wrote:
> On Mon, May 14, 2007 at 11:03:52AM -0400, Tom Lane wrote:
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> > > But these kinds of inconsistent behaviours can be traps for users. It
> > > means
> > > "\c1" and "\c 1" do different things
On Thu, Feb 22, 2007 at 11:50:06AM +1100, FAST PostgreSQL wrote:
> - The log output will be in COPY format and will include the following
> information, irrespective of the log_line_prefix setting.
> ( timestamp_with_milliseconds, timestamp, username, databasename,
> sessionid, host_and_port,
On Sat, Apr 22, 2006 at 01:49:25PM -0700, David Fetter wrote:
> On Sat, Apr 22, 2006 at 01:14:42PM -0700, David Gould wrote:
>
> > To avoid running out of swap and triggering the oom killer we have
> > had to reduce work_mem below what we prefer.
>
> Dunno about your work_mem, but you can make su
On Sat, Apr 22, 2006 at 06:38:53PM +0100, Simon Riggs wrote:
> On Sat, 2006-04-22 at 13:17 -0400, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > I still do, for multi-user systems. Releasing unused memory from a large
> > > CREATE INDEX will allow that memory to be swapped out, e
On Sun, Feb 19, 2006 at 08:09:09PM -0500, Neil Conway wrote:
> On Mon, 2006-02-06 at 16:05 -0600, P. Scott DeVos wrote:
> > I have been working with plpython for several months and have
> > been hampered by the lack of a traceback being logged when a
> > plpython function raises an error. I have w
On Mon, Feb 13, 2006 at 02:59:43PM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> More to the point, the utility of the patch remains unproven.
> > >> We are not in the habit of adding OS dependencies on speculation.
> >
> > > He ran tests, th
On Tue, Jan 03, 2006 at 11:32:01PM -0500, Tom Lane wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > The following patch implements individual privileges for TRUNCATE,
> > VACUUM and ANALYZE. Includes documentation and regression test
> > updates. Resolves TODO item 'Add a separate TRU
On Fri, Dec 30, 2005 at 05:55:23PM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Neil Conway <[EMAIL PROTECTED]> writes:
> > > One minor irritation is that the query string of prepared statements
> > > created via SQL has "PREPARE ... AS" prefixed to it, whereas statements
> > > prepared via th
On Fri, Dec 23, 2005 at 03:38:56PM -0500, Andrew Dunstan wrote:
> >
> >What numbers would you like? If what I suggested seems odd, how about
> >targets of 400 connections, 4000 shared_buffers and 200,000
> >max_fsm_pages?
>
>
> Here's a patch that does what I had in mind. On my modest workstati
On Thu, Oct 20, 2005 at 12:30:27PM -0400, Tom Lane wrote:
> "Matthew T. O'Connor" writes:
> > Tom Lane wrote:
> >> Surely this is completely broken? AFAICT you are testing the result
> >> from a VACUUM or ANALYZE command, which is not going to return any
> >> tuples.
>
> > Upon further inspectio
Apologies if this is old news, but pg_autovacuum in 8.0.x has the bad habit
of SEGVing and exiting when a table gets dropped out from under it. This
creates problems if you rely on pg_autovacuum for the bulk of your vacuuming
as it forgets it's statistics when it is restarted and so will skip some
39 matches
Mail list logo
