From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp48.i.mail.ru (smtp48.i.mail.ru [94.100.177.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id BDE3645C308 for ; Fri, 11 Dec 2020 17:50:14 +0300 (MSK) From: Leonid Vasiliev Date: Fri, 11 Dec 2020 17:49:12 +0300 Message-Id: <59ffd9dd6c9e895b85f89bfb23d6f8fcbf2c556f.1607696813.git.lvasiliev@tarantool.org> In-Reply-To: References: In-Reply-To: References: Subject: [Tarantool-patches] [PATCH v2 3/3] sql: update temporary file name format List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: v.shpilevoy@tarantool.org, imeevma@tarantool.org, korablev@tarantool.org, sergos@tarantool.org, m.semkin@corp.mail.ru Cc: tarantool-patches@dev.tarantool.org The bug was consisted in fail when working with temporary files created by VDBE to sort large result of a `SELECT` statement with `ORDER BY`, `GROUP BY` clauses. Whats happen (step by step): - We have two instances on one node (sharded cluster). - A query is created that executes on both. - The first instance creates the name of the temporary file and checks a file with such name on existence. - The second instance creates the name of the temporary file (the same as in first instance) and checks a file with such name on existence. - The first instance creates a file with the `SQL_OPEN_DELETEONCLOSE` flag. - The second instance opens(try to open) the same file. - The first instance closes (and removes) the temporary file. - The second instance tries to work with the file and fails. Why did it happen: The temporary file name format has a random part, but the random generator uses a fixed seed. When it was decided to use a fixed seed: 32cb1ad298b2b55d8536a85bdfb3827c8c8739e1 How the patch fixes the problem: The patch injects the PID in the temporary file name format. The generated name is unique for a single process (due to a random part) and unique between processes (due to the PID part). Alternatives: 1) Use `O_TMPFILE` or `tmpfile()` (IMHO the best way to work with temporary files). In both cases, we need to update a significant part of the code, and some degradation can be added. It's hard to review. 2) Return a random seed for the generator. As far as I understand, we want to have good reproducible system behavior, in which case it's good to use a fixed seed. 3) Add reopening file with the flags `O_CREAT | O_EXCL` until we win the fight. Now we set such flags when opening a temporary file, but after that we try to open the file in `READONLY` mode and if ok - return the descriptor. This is strange logic for me and I don't want to add any aditional logic here. Also, such solution will add additional attempts to open the file. So, it look like such minimal changes will work fine and are simple to review. Co-authored-by: Mergen Imeev Fixes #5537 --- src/box/sql/os_unix.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/box/sql/os_unix.c b/src/box/sql/os_unix.c index 557d709..ce415cb 100644 --- a/src/box/sql/os_unix.c +++ b/src/box/sql/os_unix.c @@ -1483,8 +1483,8 @@ unixGetTempname(int nBuf, char *zBuf) assert(nBuf > 2); zBuf[nBuf - 2] = 0; sql_snprintf(nBuf, zBuf, - "%s/" SQL_TEMP_FILE_PREFIX "%llx%c", zDir, - r, 0); + "%s/" SQL_TEMP_FILE_PREFIX "%ld_%llx%c", zDir, + (long)randomnessPid, r, 0); if (zBuf[nBuf - 2] != 0 || (iLimit++) > 10) return -1; } while (access(zBuf, 0) == 0); -- 2.7.4