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
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 |