Re: [PATCH] vacuumlo: print the number of large objects going to be removed

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "Michael Paquier" <michael(at)paquier(dot)xyz>
Cc: "Timur Birsh" <taem(at)linukz(dot)org>,"pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] vacuumlo: print the number of large objects going to be removed
Date: 2019-09-06 15:25:57
Message-ID: 658de763-0290-41db-a6fe-b6445575f3b2@manitou-mail.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier wrote:

> Sure. However do we need to introduce this much complication as a
> goal for this patch though whose goal is just to provide hints about
> the progress of the work done by vacuumlo?

Yeah, I went off on a tangent when realizing that ~500 lines of C
client-side code in vacuumlo could be turned into ~50 lines of
plpgsql in a block.
That was not meant as on objection to the patch
(besides I followed the plpgsql approach and got disappointed with the
performance of lo_unlink() in a loop compared to the client-side
equivalent, so I won't bother -hackers with this idea anymore, until I
figure out why it's not faster and if I can do something about it).

One comment about the patch:

+ long to_delete = 0;
...
+ to_delete = strtol(PQcmdTuples(res), NULL, 10);

I believe the maximum number of large objects is almost 2^32, and as a
count above 2^31 may not fit into a signed long, shouldn't we use
an unsigned long instead? This would also apply to the preexisting
"deleted" variable.

Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Yuli Khodorkovskiy 2019-09-06 15:26:38 Re: add a MAC check for TRUNCATE
Previous Message Robert Haas 2019-09-06 15:21:45 Re: add a MAC check for TRUNCATE