From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Subject: | Re: pgsql: Allow users to limit storage reserved by replication slots |
Date: | 2020-04-08 02:58:55 |
Message-ID: | 7878.1586314735@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> However, even with that change, we're still testing that a checkpoint is
> 216 bytes ... in other words, whenever someone changes the definition of
> struct CheckPoint, this test will fail. That seems unnecessary and
> unfriendly. I'm not sure how to improve that without also removing that
> column.
I read florican's results as showing that sizeof(CheckPoint) is already
different on 32-bit machines than 64-bit; it's repeatably getting this:
# Failed test 'check that the slot state changes to "reserved"'
# at t/019_replslot_limit.pl line 125.
# got: '0/15000C0|reserved|192 bytes'
# expected: '0/15000C0|reserved|216 bytes'
This test case was *not* well thought out.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-04-08 03:33:04 | pgsql: Remove testing for precise LSN/reserved bytes in new TAP test |
Previous Message | Thomas Munro | 2020-04-08 02:58:37 | pgsql: Support PrefetchBuffer() in recovery. |
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2020-04-08 03:06:21 | Re: Use compiler intrinsics for bit ops in hash |
Previous Message | Amit Langote | 2020-04-08 02:53:44 | Re: d25ea01275 and partitionwise join |