{"push_id":2798666192,"size":11,"distinct_size":1,"ref":"refs/heads/kyukhin/gh-3613-update-idx-afer-alter","head":"4cf29331f3730658351701122d8714e157e0d77b","before":"1d1b87f7615fd659029c4a83bf1135725e1fdc65","commits":[{"sha":"6854ea19b0d50b741b3dad74f4cca9acd66e7c22","author":{"name":"Olga Arkhangelskaia","email":"39e937f86fd3e8cf0281bdae3123e7efb0050bb2@tarantool.org"},"message":"say: configurable syslog destination\n\nAdded server option to syslog configuration.\nServer option is responsible for log destination. At the momemt\nthere is two ways of usage:server=unix:/path/to/socket or\nserver=ipv4:port. If port is not set default udp port 514 is used.\nIf logging to syslog is set, however there is no server options -\ndefault location is used: Linux /dev/log and Mac /var/run/syslog.\n\nCloses #3487","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/6854ea19b0d50b741b3dad74f4cca9acd66e7c22"},{"sha":"8c06a069d764740b3ed5759c6b9a1ddd1d60f133","author":{"name":"Mergen Imeev","email":"3704c021c2a271260e9bf466142287ca9d5f2fd6@gmail.com"},"message":"test: fix box/errinj.test.lua sporadic failure\n\nIn some cases operation box.snapshot() takes longer than expected.\nThis leads to situations when the previous error is reported instead\nof the new one. Now these errors completely separated.\n\nCloses #3599","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/8c06a069d764740b3ed5759c6b9a1ddd1d60f133"},{"sha":"e72867cb916966aebe31c27d0054eb9316bced98","author":{"name":"Vladimir Davydov","email":"962fd425226003962530d10a2c8ddc4a6d94fb88@gmail.com"},"message":"vinyl: fix appearance of phantom tuple in secondary index after update\n\nindex.update() looks up the old tuple in the primary index, applies\nupdate operations to it, then writes a DELETE statement to secondary\nindexes to delete the old tuple and a REPLACE statement to all indexes\nto insert the new tuple. It also sets a column mask for both DELETE and\nREPLACE statements. The column mask is a bit mask which has a bit set if\nthe corresponding field is updated by update operations. It is used by\nthe write iterator for two purposes. First, the write iterator skips\nREPLACE statements that don't update key fields. Second, the write\niterator turns a REPLACE that has a column mask that intersects with key\nfields into an INSERT (so that it can get annihilated with a DELETE when\nthe time comes). The latter is correct, because if an update() does\nupdate secondary key fields, then it must have deleted the old tuple and\nhence the new tuple is unique in terms of extended key (merged primary\nand secondary key parts, i.e. cmp_def).\n\nThe problem is that a bit may be set in a column mask even if the\ncorresponding field does not actually get updated. For example, consider\nthe following example.\n\n  s = box.schema.space.create('test', {engine = 'vinyl'})\n  s:create_index('pk')\n  s:create_index('sk', {parts = {2, 'unsigned'}})\n  s:insert{1, 10}\n  box.snapshot()\n  s:update(1, {{'=', 2, 10}})\n\nThe update() doesn't modify the secondary key field so it only writes\nREPLACE{1, 10} to the secondary index (actually it writes DELETE{1, 10}\ntoo, but it gets overwritten by the REPLACE). However, the REPLACE has\ncolumn mask that says that update() does modify the key field, because a\ncolumn mask is generated solely from update operations, before applying\nthem. As a result, the write iterator will not skip this REPLACE on\ndump. This won't have any serious consequences, because this is a mere\noptimization. What is worse, the write iterator will also turn the\nREPLACE into an INSERT, which is absolutely wrong as the REPLACE is\npreceded by INSERT{1, 10}. If the tuple gets deleted, the DELETE\nstatement and the INSERT created by the write iterator from the REPLACE\nwill get annihilated, leaving the old INSERT{1, 10} visible.\n\nThe issue may result in invalid select() output as demonstrated in the\nissue description. It may also result in crashes, because the tuple\ncache is very sensible to invalid select() output.\n\nTo fix this issue let's clear key bits in the column mask if we detect\nthat an update() doesn't actually update secondary key fields although\nthe column mask says it does.\n\nCloses #3607","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/e72867cb916966aebe31c27d0054eb9316bced98"},{"sha":"444355dd4fbc66f55d1b60777f4fb11517cdd3cc","author":{"name":"Vladimir Davydov","email":"962fd425226003962530d10a2c8ddc4a6d94fb88@gmail.com"},"message":"test: fix box/bitset test failure\n\nReproduce file:\n\n- [box/access.test.lua, null]\n- [box/iterator.test.lua, null]\n- [box/bitset.test.lua, null]\n\nThe issue happens, because box/bitset.lua:dump() uses iterate(), which\ngets cleared by box/iterator test. Fix this by using utils.iterate()\ninstead.","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/444355dd4fbc66f55d1b60777f4fb11517cdd3cc"},{"sha":"7033727e30f3fd8905d7d5bb196da2451d7483da","author":{"name":"Nikita Pettik","email":"f5426693cd7bcafd8a529d1adfff964ab6d38d38@tarantool.org"},"message":"test: add read privilege in box/access test for FK space\n\nAfter introducing foreign key constraints, space:drop() processes lookup\nin _fk_constraint system space to drop child constraints (if any\nexist). Thus, we must provide at least 'read' privilege for this space.","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/7033727e30f3fd8905d7d5bb196da2451d7483da"},{"sha":"2519395454345d6ca9c7b7a09fcd84dabc234cf7","author":{"name":"Vladimir Davydov","email":"962fd425226003962530d10a2c8ddc4a6d94fb88@gmail.com"},"message":"test: fix tests failing after introducing _fk_constraint system space\n\nThere's a new system space _fk_constraint with two indexes. Take this\ninto account in tests that check presence of system spaces.","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/2519395454345d6ca9c7b7a09fcd84dabc234cf7"},{"sha":"57d54d1ca3c46a2d045da1d90c1ebe774e6850a5","author":{"name":"Vladimir Davydov","email":"962fd425226003962530d10a2c8ddc4a6d94fb88@gmail.com"},"message":"Merge branch '1.9' into 1.10","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/57d54d1ca3c46a2d045da1d90c1ebe774e6850a5"},{"sha":"a483048437f29f38f01143ab2e6c5d9788824553","author":{"name":"Vladimir Davydov","email":"962fd425226003962530d10a2c8ddc4a6d94fb88@gmail.com"},"message":"Merge branch '1.10' into 2.0","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/a483048437f29f38f01143ab2e6c5d9788824553"},{"sha":"5db765a76ab7270b350960a2dd6d89dcd3bdc032","author":{"name":"Olga Arkhangelskaia","email":"39e937f86fd3e8cf0281bdae3123e7efb0050bb2@tarantool.org"},"message":"say: fix non-informative error messages for log cfg\n\nIn case of bad or erroneous options for log configurations errors had\nambiguous or absent messages. In some cases it lead to app crashes.\n\nCloses #3553","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/5db765a76ab7270b350960a2dd6d89dcd3bdc032"},{"sha":"32cb1ad298b2b55d8536a85bdfb3827c8c8739e1","author":{"name":"Kirill Shcherbatov","email":"5cc65286c3dac56537b6a3555ed064424ec0a6c4@tarantool.org"},"message":"sql: drop useless code from os_unix.c\n\nResolves #3284.","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/32cb1ad298b2b55d8536a85bdfb3827c8c8739e1"},{"sha":"4cf29331f3730658351701122d8714e157e0d77b","author":{"name":"Kirill Yukhin","email":"68b6543cf7e4eb54f3cd6dfb62cadfaa7709acb9@tarantool.org"},"message":"sql: after table rename properly update indexes\n\nAfter table was altered due to rename, indexes were not updated.\nRe-create all table's indexes (in legacy SQL DD), also perform\nupdate of corresponding entry in _index for each index to fix\ntable name in create statement.\n\nCloses #3613","distinct":true,"url":"https://api.github.com/repos/tarantool/tarantool/commits/4cf29331f3730658351701122d8714e157e0d77b"}]}
{"actor":{"display_login":"kyukhin"}}