> 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."* https://libpng.sourceforge.io/decompression_bombs.html https://stackoverflow.com/questions/33602308/how-to-check-png-file-if-its-a-decompression-bomb Regards, Imre Achilleas Mantzios <ach...@matrix.gatewaynet.com> ezt írta (időpont: 2020. ápr. 17., P, 16:39): > 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. >
