You can't fix LVM by growing size back to original size, unless you were very lucky and the LV had no fragmentation whatsoever due to previous resizes. Chances are the new LV will have the first 20G or so of your original filesystem but the remaining 780G (or whatever) are scrambled eggs (wrong data, wrong offset, wrong order).
And that's assuming you're using HDD media. If it was SSD, with issue_discards=1 in your lvm.conf, the data would simply be gone, which is why I never use this option.
You have to check /etc/lvm/{archive,backup}/ for old versions of your metadata. Each file in there says when it was created, for example:
description = "Created *before* executing 'lvremove HDD/mdtest1'"
You're looking for the one that says Created before lvresize 850 with the G missing. And then vgcfgrestore LVM metadata using that backup and hopefully then it will be back in working order.
If you do not have such files in /etc/lvm, either because you did this from a Live CD that lost this data, or the damage happened on your root LV, things get a bit more complicated as you have to hope for the LVM metadata on disk to contain this bit of history in its circular buffer.
Rough method to see what's possibly in there:
dd if=/dev/pvdevice bs=1M count=1 | strings -w -n 16