> it killed my 200+ days uptime FreeBSD box :( .
> As I describe above, those attachments are nowhere as files.
> They are email attachments. Also we got about half TB of them.
it is possible - that some image is a "decompression bomb" ?
"Because of the efficient compression method used in Portable Network Graphics (PNG) files, a small PNG file can expand tremendously, acting as a "decompression bomb". Malformed PNG chunks can consume a large amount of CPU and wall-clock time and large amounts of memory, up to all memory available on a system, causing a Denial of Service (DoS). Libpng-1.4.1 has been revised to use less CPU time and memory, and provides functions that applications can use to further defend against such files."
Regards,
Imre
On 17/4/20 4:09 μ.μ., Adam Brusselback wrote:
Why not extract and store that metadata with the image rather than trying to extract it to filter on at query time? That way you can index your height and width columns to speed up that filtering if necessary.
Yes I thought of that, but those are coming automatically from our mail server (via synonym), we have written an alias : a program that parses and stores emails. This is generic, I wouldn't like to add specific code (or specific columns) just for image attachments. However I dig the idea of the indexes.
You may be able to write a wrapper for a command line tool like imagemagic or something so you can call that from a function to determine the size if you did want to stick with extracting that at query time.
As I describe above, those attachments are nowhere as files. They are email attachments. Also we got about half TB of them.
