Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j8fiL-0005hp-0V for pgsql-bugs@arkaria.postgresql.org; Mon, 02 Mar 2020 07:42:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j8fiI-0004YV-GK for pgsql-bugs@arkaria.postgresql.org; Mon, 02 Mar 2020 07:42:06 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j8fiH-0004YO-VQ for pgsql-bugs@lists.postgresql.org; Mon, 02 Mar 2020 07:42:06 +0000 Received: from cyclops.postgrespro.ru ([93.174.131.138] helo=mail.postgrespro.ru) by makus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1j8fiA-0002pB-7Q for pgsql-bugs@lists.postgresql.org; Mon, 02 Mar 2020 07:42:04 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 9313621C45F4; Mon, 2 Mar 2020 10:41:55 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[] autolearn=unavailable Received: from ars-thinkpad (nat03-43-2.netorn.net [188.35.130.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id E702A21C459F; Mon, 2 Mar 2020 10:41:54 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1583134915; bh=dXlZC5CzIBEedKFH50uRCyOpvAKxjwDMiYXQUGLJcDw=; h=References:From:To:Cc:Subject:In-reply-to:Date; b=jz6o57S6Rkk5O7Wl4b+4Fltj/8gN+xorfL6p6PQ9f+LVMNdH1FNaNKwzl5nLDin11 l0o+zY+y07hv20aFmBhzE8YnR4lwR0YIj+PKmfH2i6spfDgv8saNnemqLqcgJ3KIxZ Mtg1kuhbvMPWwozWiXNAoVRubYIMwarPooDCPLY8= References: <87ftjifoql.fsf@ars-thinkpad> <20191024213157.7pm6niybfxgpvmgg@alap3.anarazel.de> <87eez1fh48.fsf@ars-thinkpad> <8736bs81sx.fsf@ars-thinkpad> <871rrb942q.fsf@ars-thinkpad> <87zhdx76d5.fsf@ars-thinkpad> <8736bjoiax.fsf@ars-thinkpad> User-agent: mu4e 1.2.0; emacs 26.0.50 From: Arseny Sher To: Amit Kapila Cc: Andres Freund , "Hsu\, John" , "pgsql-bugs\@lists.postgresql.org" Subject: Re: ERROR: subtransaction logged without previous top-level txn record In-reply-to: Date: Mon, 02 Mar 2020 10:41:54 +0300 Message-ID: <87o8tf6w59.fsf@ars-thinkpad> MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Amit Kapila writes: > On Sun, Feb 9, 2020 at 9:37 PM Arseny Sher wrote: > + /* > + * Don't use serialized snapshot if we are not sure where all > + * currently running xacts will finish (new slot creation). > + * (Actually, if we came here through xl_running_xacts, we could perform > + * SNAPBUILD_FULL_SNAPSHOT -> SNAPBUILD_CONSISTENT transition properly, > + * but added lines of code would hardly worth the benefit.) > + */ > + if (builder->start_decoding_at == InvalidXLogRecPtr) > + return false; > > Instead of using start_decoding_at to decide whether to restore > snapshot or not, won't it be better to have new variable in SnapBuild > (say can_use_serialized_snap or something like that) and for this > purpose? start_decoding_at who is initialized externally at AllocateSnapshotBuilder is what actually defines how to handle serialized snapshots: if it is valid LSN, snapbuild must trust the caller that WAL reading starts early enough to stream since this LSN, so we deserialize the snap and jump into CONSISTENT. If it is invalid, we don't know the safe streaming point yet, and it remains invalid until we learn full snapshot and then wait for all xacts finishing. So such bool would be a pointless synonym. Moreover, as cited comment mentions: > + * (Actually, if we came here through xl_running_xacts, we could perform > + * SNAPBUILD_FULL_SNAPSHOT -> SNAPBUILD_CONSISTENT transition properly, > + * but added lines of code would hardly worth the benefit.) there is nothing wrong in using the serialized snapshot per se. It's just that we must wait for all xacts finishing after getting the snapshot and this is impossible if we don't know who is running. So can_use_serialized_snap would be even somewhat confusing. -- cheers, arseny