Re: vacuumlo patch

From: Aron Wieck <me(at)eunice(dot)de>
To: Tim Lewis <Tim(dot)Lewis(at)vialect(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: vacuumlo patch
Date: 2011-07-26 15:06:53
Message-ID: 949971A6-1A71-46B0-B291-01C76F50D0A6@eunice.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tim,

you correctly assumed I was just trying to clean up the code. There was no reason to change the behavior, so please ignore my change to the patch.

Aron

On 26.07.2011, at 15:44, Tim Lewis wrote:

> Hi Aron,
>
> Thanks for the input. The "small change" you suggest would change the behavior of the patch which I would prefer not to do as I have reasons for the previous behavior.
> Because you gave no reasons and "stop after removing LIMIT LOs" was not changed to "stop after attempting to remove LIMIT LOs" I suspect you were just trying to keep the code clean.
>
> The difference:
> In your version of the patch vacuumlo will stop after N lo_unlink(OID) attempts.
> The previous behavior of the patch is that vacuumlo will stop after N successful lo_unlink(OID)s.
>
> If you have good reason for your behavior please add another flag so that it is optional.
> There should be a clear distinction between "counting vs not", and "aborting vs continuing" when a lo_unlink(OID) is unsuccessful.
>
>
> On Tue, Jul 26, 2011 at 4:18 AM, Aron <me(at)eunice(dot)de> wrote:
> Here's another small change to the patch, it works fine for me and it quite
> saved my day.
>
> I try to submit the patch by email.
>
>
> diff --git a/contrib/vacuumlo/vacuumlo.c b/contrib/vacuumlo/vacuumlo.c
> index f6e2a28..1f88d72 100644
> --- a/contrib/vacuumlo/vacuumlo.c
> +++ b/contrib/vacuumlo/vacuumlo.c
> @@ -48,6 +48,7 @@ struct _param
> char *pg_host;
> int verbose;
> int dry_run;
> + int transaction_limit;
> };
>
> int vacuumlo(char *, struct _param *);
> @@ -286,6 +287,8 @@ vacuumlo(char *database, struct _param * param)
> }
> else
> deleted++;
> + if(param->transaction_limit!=0 &&
> deleted>=param->transaction_limit)
> + break;
> }
> PQclear(res);
>
> @@ -313,6 +316,7 @@ usage(const char *progname)
> printf(" -h HOSTNAME database server host or socket directory\n");
> printf(" -n don't remove large objects, just show what would be
> done\n");
> printf(" -p PORT database server port\n");
> + printf(" -l LIMIT stop after removing LIMIT LOs\n");
> printf(" -U USERNAME user name to connect as\n");
> printf(" -w never prompt for password\n");
> printf(" -W force password prompt\n");
> @@ -342,6 +346,7 @@ main(int argc, char **argv)
> param.pg_port = NULL;
> param.verbose = 0;
> param.dry_run = 0;
> + param.transaction_limit = 0;
>
> if (argc > 1)
> {
> @@ -359,7 +364,7 @@ main(int argc, char **argv)
>
> while (1)
> {
> - c = getopt(argc, argv, "h:U:p:vnwW");
> + c = getopt(argc, argv, "h:U:p:l:vnwW");
> if (c == -1)
> break;
>
> @@ -395,6 +400,14 @@ main(int argc, char **argv)
> }
> param.pg_port = strdup(optarg);
> break;
> + case 'l':
> + param.transaction_limit = strtol(optarg, NULL, 10);
> + if ((param.transaction_limit < 0) || (param.transaction_limit >
> 2147483647))
> + {
> + fprintf(stderr, "%s: invalid transaction limit number: %s, valid
> range is form 0(disabled) to 2147483647.\n", progname, optarg);
> + exit(1);
> + }
> + break;
> case 'h':
> param.pg_host = strdup(optarg);
> break;
>
>
> --
> View this message in context: http://postgresql.1045698.n5.nabble.com/vacuumlo-patch-tp4628522p4634026.html
> Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
>
> --
>
> Noodle
> Connecting People, Content & Capabilities within the Enterprise
>
>
> Toll Free: 866-258-6951 x 701
> Tim(dot)Lewis(at)vialect(dot)com
> http://www.vialect.com
>
> Noodle is a product of Vialect Inc
>
> Follow Noodle on Twitter
> http://www.twitter.com/noodle_news
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-07-26 15:07:43 Re: Another issue with invalid XML values
Previous Message Tom Lane 2011-07-26 14:59:05 Re: Another issue with invalid XML values