Hi, I enabled skink / the valgrind animal to run the tap tests too (hugely increasing the test time :(), and that paid of: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2017-04-22%2004%3A52%3A13
==606== VALGRINDERROR-BEGIN ==606== Conditional jump or move depends on uninitialised value(s) ==606== at 0x46A207: logicalrep_rel_open (relation.c:361) ==606== by 0x472D12: copy_table (tablesync.c:669) ==606== by 0x473186: LogicalRepSyncTableStart (tablesync.c:803) ==606== by 0x475287: ApplyWorkerMain (worker.c:1530) ==606== by 0x440AFD: StartBackgroundWorker (bgworker.c:835) ==606== by 0x44E48A: do_start_bgworker (postmaster.c:5577) ==606== by 0x44E59F: maybe_start_bgworker (postmaster.c:5761) ==606== by 0x44F11D: sigusr1_handler (postmaster.c:5015) ==606== by 0x4E430BF: ??? (in /lib/x86_64-linux-gnu/libpthread-2.24.so) ==606== by 0x6FB8212: __select_nocancel (syscall-template.S:84) ==606== by 0x44F868: ServerLoop (postmaster.c:1693) ==606== by 0x450C53: PostmasterMain (postmaster.c:1337) ==606== Uninitialised value was created by a heap allocation ==606== at 0x605382: MemoryContextAlloc (mcxt.c:729) ==606== by 0x5E4E6A: DynaHashAlloc (dynahash.c:266) ==606== by 0x5E4EEE: element_alloc (dynahash.c:1637) ==606== by 0x5E5018: get_hash_entry (dynahash.c:1248) ==606== by 0x5E5898: hash_search_with_hash_value (dynahash.c:1033) ==606== by 0x5E5A0D: hash_search (dynahash.c:890) ==606== by 0x469D38: logicalrep_relmap_update (relation.c:179) ==606== by 0x472D05: copy_table (tablesync.c:666) ==606== by 0x473186: LogicalRepSyncTableStart (tablesync.c:803) ==606== by 0x475287: ApplyWorkerMain (worker.c:1530) ==606== by 0x440AFD: StartBackgroundWorker (bgworker.c:835) ==606== by 0x44E48A: do_start_bgworker (postmaster.c:5577) ==606== ==606== VALGRINDERROR-END there's also another bleat: ==2161== VALGRINDERROR-BEGIN ==2161== Syscall param write(buf) points to uninitialised byte(s) ==2161== at 0x4E42190: __write_nocancel (syscall-template.S:84) ==2161== by 0x4676C7: CheckPointReplicationOrigin (origin.c:574) ==2161== by 0x25DB99: CheckPointGuts (xlog.c:9007) ==2161== by 0x2647CD: CreateCheckPoint (xlog.c:8792) ==2161== by 0x26734F: StartupXLOG (xlog.c:7576) ==2161== by 0x4510FA: StartupProcessMain (startup.c:217) ==2161== by 0x273832: AuxiliaryProcessMain (bootstrap.c:426) ==2161== by 0x44D8A0: StartChildProcess (postmaster.c:5256) ==2161== by 0x44DF33: PostmasterStateMachine (postmaster.c:3791) ==2161== by 0x44EE25: reaper (postmaster.c:3038) ==2161== by 0x4E430BF: ??? (in /lib/x86_64-linux-gnu/libpthread-2.24.so) ==2161== by 0x6FB8212: __select_nocancel (syscall-template.S:84) ==2161== Location 0xffeffda42 is 2 bytes inside local var "disk_state" ==2161== declared at origin.c:555, in frame #1 of thread 1 ==2161== Uninitialised value was created by a stack allocation ==2161== at 0x467421: CheckPointReplicationOrigin (origin.c:505) ==2161== ==2161== VALGRINDERROR-END ==2161== VALGRINDERROR-BEGIN ==2161== Syscall param write(buf) points to uninitialised byte(s) ==2161== at 0x4E42190: __write_nocancel (syscall-template.S:84) ==2161== by 0x467712: CheckPointReplicationOrigin (origin.c:591) ==2161== by 0x25DB99: CheckPointGuts (xlog.c:9007) ==2161== by 0x2647CD: CreateCheckPoint (xlog.c:8792) ==2161== by 0x26734F: StartupXLOG (xlog.c:7576) ==2161== by 0x4510FA: StartupProcessMain (startup.c:217) ==2161== by 0x273832: AuxiliaryProcessMain (bootstrap.c:426) ==2161== by 0x44D8A0: StartChildProcess (postmaster.c:5256) ==2161== by 0x44DF33: PostmasterStateMachine (postmaster.c:3791) ==2161== by 0x44EE25: reaper (postmaster.c:3038) ==2161== by 0x4E430BF: ??? (in /lib/x86_64-linux-gnu/libpthread-2.24.so) ==2161== by 0x6FB8212: __select_nocancel (syscall-template.S:84) ==2161== Location 0xffeffda58 is 0 bytes inside local var "crc" ==2161== declared at origin.c:511, in frame #1 of thread 1 ==2161== Uninitialised value was created by a stack allocation ==2161== at 0x467421: CheckPointReplicationOrigin (origin.c:505) ==2161== ==2161== VALGRINDERROR-END but that looks more like something that needs to be silenced, based on the 3s look I gave it. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
