Changes between Initial Version and Version 1 of Ticket #5564


Ignore:
Timestamp:
10/03/23 13:21:29 (15 months ago)
Author:
robe
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #5564 – Description

    initial v1  
    99
    1010Solution 2. is maybe the most consistent with the current implementation in PostGIS due to the peculiarity of geospatial data type in order to be indexed, that originally brought us to redefine (and simplify compared to Postgresql core version) the ADD_VALUE function. But I would like to hear about other opinions regarding this.
     11
     12
     13The gdb backtrace of this issue:
     14
     15
     16{{{
     17#0 FunctionCall2Coll(fcinfo=0x0 collation-collationcentry=0x0 arg =232/28/1391480| arg2=232728/1252344) at tmgr.c:1306\n
     18#1 0x0000000000603533 in brin_inclusion_union (fcinfo=<optimized out>) at brin_inclusion.c:522\n
     19#2 0x0000000000a9be34 in FunctionCal13Coll (flinfo=0×152d885cf98| collation=optimizedout>|
     20arg1=argi@entry=23285305342184| arg2=arg2@entry=23272870259120| arg3=arg3@entry=23272871440776) at
     21fmgr.c:1331\n
     22#3 0x0000000000601ea6 in union_tuples (b=0x152aa33c9278| a=<optimized out>| bdesc=<optimized
     23out>) at brin.c:1651 \n
     24#4 summarize_range CheapNumBlks=53390|heapBIk=43520| heapRel=0x152d88748a98|
     25state=<optimized out>| indexInfo=0x152a33c9518) at brin.c:1460\n
     26#5 brinsummarize index=0x152d88749b48|heapRel=heapRel@entry=0x152d88748a98| pageRange=pageRange@entry=4294967295|
     27include_partial=include_partial@entry-false| numSummarized-numSummarized@entry=0×152aa32a3308|
     28numExisting=numExisting@entry=0x152a32a3308) at brin.c:1542\n
     29#6 0x000000000060219a in brinvacuumcleanup(info=0x7ffd2a9740b0| stats=<optimized out>) at brin.c:957\n
     30#7 0x0000000000652280 in lazy_cleanup_one_index
     31(indrel=0x152088749648| 1stat=0x152aa32@3300| reltuples=reltuples@entry=176649|
     32estimated_count=estimated_count@entry=true| vacrel=vacrel@entry=0x152a33c9628) at vacuumlazy.c:3404\n
     33#8 0x0000000000654f74 in lazy_cleanup_all_indexes (vacrel=8x152aa33c9628) at vacuumlazy.c:3295\n
     34#9 lazy_scan_heap (aggressive=false| params=0x152d88785ac| vacrel=<optimized out>) at vacuumlazy.c: 1851\n
     35#10 heap_vacuum_rel (rel=0x152088748298| params=0x152d8878f5ac| bstrategy=<optimized out>) at
     36vacuumlazy.c:746\n/
     37#11 0x00000000007bflba in table_relation_vacuum (bstrategy-<optimized out>|
     38params=0x152d8878f5ac| rel=0x152d88748a98) at ../../../src/include/access/tableam.h:1682\n
     39#12 vacuum_rel(relid=1830312108| relation=<optimized out>| params=params@entry=0x152d8878f5ac) at vacuum. c: 2122\n
     40#13 0x00000000007c065c in vacuum (relations=0×152aa33a188| params=params@entry=0×152d8878f5ac|
     41bstrategy=<optimized out>| bstrategy@entry=0×152aa33dba38| isTopLevel=isTopLevel@entry=true) at
     42vacuum. c:494\n
     43#14 0x00000000005d3ba7 in autovacuum_do_vac_analyze (bstrategy=0×152aa33d0038|
     44tab=0x152d8878f5a8 at autovacuum.c:3267\n
     45#15 do_autovacuum ( at autovacuum.c: 2507\n
     46#16 0x00000000005041b7 in AutoVackorkerMain(arg=0x0| a r g = 0 )a t autovacuum.c:1728\n
     47#17 0x00000000008bbob in StartAutoVacWorker( at autovacuum.c:1512\n
     48#18 0x00000000008c3fc in StartAutovacuumWorker ( at postmaster.c:6885\n
     49#19 sigusr1_handler (postgres_signal_arg=<optimized out>) at postmaster.c:6313\
     50
     51
     52}}}