Обсуждение: BUG #16037: Assertion fails in varbit_out

The following bug has been logged on the website:

Bug reference:      16037
Logged by:          Alexander Lakhin
Email address:      exclusion@gmail.com
PostgreSQL version: 12.0
Operating system:   Ubuntu 18.04
Description:

The following query:
SELECT CAST(B'111111111111100000000' AS BIT VARYING(20)) >>8;
causes the FailedAssertion exception:

Core was generated by `postgres: law regression [local] SELECT
                        '.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: Нет такого файла или каталога.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007fcd62f0e801 in __GI_abort () at abort.c:79
#2  0x00005648f4302ee3 in ExceptionalCondition (
    conditionName=conditionName@entry=0x5648f44fabf0 "!(pad_ == 0 ||
(*((((VarBit *) (s))->bit_dat) + (((((varattrib_4b *)
(s))->va_4byte.va_header >> 2) & 0x3FFFFFFF) - ((int32) sizeof(int32)) -
sizeof(int32)) - 1) & ~(0xFF << pad_)) == 0)",
errorType=errorType@entry=0x5648f4357dfd "FailedAssertion",
fileName=fileName@entry=0x5648f44faa27 "varbit.c", 
    lineNumber=lineNumber@entry=598) at assert.c:54
#3  0x00005648f42d806e in varbit_out (fcinfo=<optimized out>) at
varbit.c:598
#4  0x00005648f430b990 in FunctionCall1Coll (flinfo=0x5648f4aa5618,
collation=<optimized out>, arg1=<optimized out>)
    at fmgr.c:1140
#5  0x00005648f3ea36d5 in printtup (slot=0x5648f4aa4c48,
self=0x5648f4a9df78) at printtup.c:434
#6  0x00005648f406a788 in ExecutePlan (execute_once=<optimized out>,
dest=0x5648f4a9df78, direction=<optimized out>, 
    numberTuples=0, sendTuples=<optimized out>, operation=CMD_SELECT,
use_parallel_mode=<optimized out>, 
    planstate=0x5648f4aa4920, estate=0x5648f4aa46c8) at execMain.c:1685
#7  standard_ExecutorRun (queryDesc=0x5648f4a032f8, direction=<optimized
out>, count=0, execute_once=<optimized out>)
    at execMain.c:364
#8  0x00005648f41dcbb5 in PortalRunSelect
(portal=portal@entry=0x5648f4a498d8, forward=forward@entry=true, count=0, 
    count@entry=9223372036854775807, dest=dest@entry=0x5648f4a9df78) at
pquery.c:929
#9  0x00005648f41de346 in PortalRun (portal=portal@entry=0x5648f4a498d8,
count=count@entry=9223372036854775807, 
    isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true,
dest=dest@entry=0x5648f4a9df78, 
    altdest=altdest@entry=0x5648f4a9df78, completionTag=0x7fffc1791b80 "")
at pquery.c:770
#10 0x00005648f41d9bf2 in exec_simple_query (
    query_string=0x5648f49e2628 "SELECT CAST(B'", '1' <repeats 13 times>,
"00000000' AS BIT VARYING(20)) >>8;")
    at postgres.c:1215
#11 0x00005648f41dbb2e in PostgresMain (argc=<optimized out>,
argv=argv@entry=0x5648f4a0d9d8, dbname=<optimized out>, 
    username=<optimized out>) at postgres.c:4236
#12 0x00005648f3e938ed in BackendRun (port=0x5648f4a060b0,
port=0x5648f4a060b0) at postmaster.c:4431
#13 BackendStartup (port=0x5648f4a060b0) at postmaster.c:4122
#14 ServerLoop () at postmaster.c:1704
#15 0x00005648f4154acb in PostmasterMain (argc=3, argv=0x5648f49dca00) at
postmaster.c:1377
#16 0x00005648f3e95581 in main (argc=3, argv=0x5648f49dca00) at main.c:228

It does not happen on 860216efa~1.

PG Bug reporting form <noreply@postgresql.org> writes:
> The following query:
> SELECT CAST(B'111111111111100000000' AS BIT VARYING(20)) >>8;
> causes the FailedAssertion exception:

D'oh ... bitshiftright() needs to do the zero-pad-fixup in both
code paths.  Will fix it tomorrow.

            regards, tom lane

Hi,

On 2019-10-04 01:34:48 -0400, Tom Lane wrote:
> PG Bug reporting form <noreply@postgresql.org> writes:
> > The following query:
> > SELECT CAST(B'111111111111100000000' AS BIT VARYING(20)) >>8;
> > causes the FailedAssertion exception:
> 
> D'oh ... bitshiftright() needs to do the zero-pad-fixup in both
> code paths.  Will fix it tomorrow.

Does that suggest we shouldn't make the asserts active in the branches <
12?

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2019-10-04 01:34:48 -0400, Tom Lane wrote:
>> D'oh ... bitshiftright() needs to do the zero-pad-fixup in both
>> code paths.  Will fix it tomorrow.

> Does that suggest we shouldn't make the asserts active in the branches <
> 12?

No, it just means the previous patch was an incomplete fix.  The
whole point of the asserts was to flush out cases where we weren't
padding correctly, and they just did that :-)

(Besides which, we discourage people from running with asserts on
in production, so I don't quite see what your concern is.)

            regards, tom lane