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 1j8lFv-0007jg-KF for pgsql-bugs@arkaria.postgresql.org; Mon, 02 Mar 2020 13:37:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j8lFu-0003Ul-9Q for pgsql-bugs@arkaria.postgresql.org; Mon, 02 Mar 2020 13:37:10 +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 1j8lFt-0003Ue-Re for pgsql-bugs@lists.postgresql.org; Mon, 02 Mar 2020 13:37:10 +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 1j8lFr-0005Zt-58 for pgsql-bugs@lists.postgresql.org; Mon, 02 Mar 2020 13:37:08 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id B442621C4C3C; Mon, 2 Mar 2020 16:37:04 +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 3EF2521C4C39; Mon, 2 Mar 2020 16:37:04 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1583156224; bh=3eUSnJUKyaOSvHfgPYuhHF3p/RGepsjs1rs5dvi6/sI=; h=References:From:To:Cc:Subject:In-reply-to:Date; b=Dwm0rOzCFVqvtekSF0aBC7rKi1ElgGL6n9flc0GwKiY3PTxBM2DFc4UDeGoTUeknK kAsA54M3/faj7PjUz8pI9p/gaejjnhqGYHmpkcU155b/vRfYB9HqvMTCuMlfeF+FCV fA6k69TtdpBZVsOs9G8AbBFeRX2hJMqGgZTD++Zk= 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> <87o8tf6w59.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 16:37:04 +0300 Message-ID: <87mu8y7u9r.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: > I think here you are trying to deduce the meaning. I don't see that > it can clearly define that don't use serialized snapshots. It is not > clear to me why have you changed the below code, basically why it is > okay to pass InvalidXLogRecPtr instead of restart_lsn? > > @@ -327,7 +327,7 @@ CreateInitDecodingContext(char *plugin, > ReplicationSlotMarkDirty(); > ReplicationSlotSave(); > > - ctx = StartupDecodingContext(NIL, restart_lsn, xmin_horizon, > + ctx = StartupDecodingContext(NIL, InvalidXLogRecPtr, xmin_horizon, > need_full_snapshot, false, > read_page, prepare_write, do_write, > update_progress); Because when we create the slot we don't demand to stream from some specific point. In fact we just can't, because we don't know since which LSN it is actually possible to stream, i.e. when we'd have good snapshot and no old (which we haven't seen in full) xacts running. It is up to snapbuild.c to define this point. The previous coding was meaningless: we asked for some random restart_lsn and snapbuild.c would silently advance it to earliest suitable LSN. OTOH, when we are decoding from existing slot not only we know earliest possible point, but to avoid missing xacts we must enforce streaming since this very point despite the snapbuilder being unable (because he might not know which xacts are running at point of the snapshot) to check its safety. start_decoding_at reflects the difference between these scenarios, and serialized snapshots handling stems from here. Thanks for looking into this. -- cheers, arseny