ts=# \errverbose
ERROR: XX000: invalid memory alloc request size 18446744073709551613
#0 pg_re_throw () at elog.c:1716
#1 0x00a33b12 in errfinish (filename=0xbff20e "mcxt.c", lineno=959,
funcname=0xbff2db <__func__.6684> "palloc") at elog.c:502
#2 0x00a6760d in palloc (size=1
On Thu, Feb 11, 2021 at 07:48:37PM -0600, Justin Pryzby wrote:
> #3 0x009fb149 in text_to_cstring (t=0x2aaae8023010) at varlena.c:212
> 212 result = (char *) palloc(len + 1);
>
> (gdb) l
> 207 /* must cast away the const, unfortunately */
> 208 text
On 2/12/21 2:48 AM, Justin Pryzby wrote:
ts=# \errverbose
ERROR: XX000: invalid memory alloc request size 18446744073709551613
#0 pg_re_throw () at elog.c:1716
#1 0x00a33b12 in errfinish (filename=0xbff20e "mcxt.c", lineno=959, funcname=0xbff2db
<__func__.6684> "palloc") at elog.c
On Fri, Feb 12, 2021 at 06:44:54PM +0100, Tomas Vondra wrote:
> > (gdb) p len
> > $1 = -4
> >
> > This VM had some issue early today and I killed the VM, causing PG to
> > execute
> > recovery. I'm tentatively blaming that on zfs, so this could conceivably
> > be a
> > data error (although reco
I think to get a size of -4 you would be trying to read a varlena
pointer pointing to four nul bytes. I bet if you run dd on the
corresponding block you'll find a chunk of nuls in the page. That
perhaps makes sense with ZFS where if a new page was linked to the
tree but never written it would be an
