Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oVfGI-0005UY-QK for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Sep 2022 20:33:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oVfGG-0000rk-4U for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Sep 2022 20:33:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oVfGF-0000rZ-Nf for pgsql-hackers@lists.postgresql.org; Tue, 06 Sep 2022 20:33:31 +0000 Received: from mail-io1-xd31.google.com ([2607:f8b0:4864:20::d31]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oVfG8-0000hL-QN for pgsql-hackers@postgresql.org; Tue, 06 Sep 2022 20:33:30 +0000 Received: by mail-io1-xd31.google.com with SMTP id y187so9966495iof.0 for ; Tue, 06 Sep 2022 13:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date; bh=V25eq1/vZ2ltjGOGfd4chJsHEWhtc6lQI8WowbO4b9E=; b=4PqlFzAHU1JyE/+6a6H/GD2T/UKeeeabIo2PfyEuCRKB3K/+rzduDWw0ojUtnuxG+w SENUxVDmTw/jM+f2BMBbfSlI05Bn89b4ItND9YwOJQALsp/0/ibwKgXXSSnVKONnGWiL 5TazXBcejmldMkx0izki81PGcXy1+1EWaJAZw3ZNTVoDT+VG1Wigk1TRvNGtXiUoGhDp s1+XJqCqK9bnNu+dvUNk+3USAjRjrS7QPkpxoTQLacSIQvDyVlA04Tu9tQChuGLkBOKC NCiniqGEAtE5Lwha6slM1NadXyC+e8xozjHraQLTY/+nI1a542VKpiQ3MAyO+WZuTpOp o89A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date; bh=V25eq1/vZ2ltjGOGfd4chJsHEWhtc6lQI8WowbO4b9E=; b=3RdYW3Um9HL1y7HmcCDjf5nyx5uLJTX5AawggKlrnN0R9odiTOQ24a+4wNeE7+ztck s1/YsJXwhxbucBbQp9x32kq0kqVvvBgqXKKSZwxLSOS4mfdQe779sDt/p/gmR03LN52L xf3ecWN6yDGU0Fx19HF1rK/gbsJZi2V7A3CjRJ+yKYnbmiztiifJfVi7+/TwfpH7pD5X cJCLaxp9P3TDUUNOOuLPlEbGxymQ4bUEO/3bsvujeHUBID3kVWUG7cGyH1mOWSjUB1Gb bZ/RlIWl+6pdtUZ8zpcs3yvLJ2ws0ZISXBHIHoBbvDSWSuh2aFKWupW2NatKReIIVgUF MLmg== X-Gm-Message-State: ACgBeo3zWAovbpa23HkMKsm3gJ5uJmgnmGb8x41TyVxzv287E2B/mSOi rNB5co1rQ9VBI+un6e0ywepuYA== X-Google-Smtp-Source: AA6agR6NZv+C1Y13LBqPoEUFeL7782GtFsfe0iFnaskVRAA2qdpNUiBlTU4DmuYbc9QYWX+NZmzjQA== X-Received: by 2002:a6b:ba05:0:b0:68a:8a2f:8fdc with SMTP id k5-20020a6bba05000000b0068a8a2f8fdcmr114969iof.148.1662496402892; Tue, 06 Sep 2022 13:33:22 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id k7-20020a02a707000000b003434b40289dsm5918971jam.165.2022.09.06.13.33.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Sep 2022 13:33:22 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 29B5A800DE8; Tue, 6 Sep 2022 15:33:21 -0500 (CDT) Date: Tue, 6 Sep 2022 15:33:21 -0500 From: Justin Pryzby To: Simon Riggs Cc: pgsql-hackers@postgresql.org Subject: Re: New docs chapter on Transaction Management and related changes Message-ID: <20220906203320.GT31833@telsasoft.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Sep 06, 2022 at 04:16:02PM +0100, Simon Riggs wrote: > New chapter on transaction management, plus a few related changes. > > Markup and links are not polished yet, so please comment initially on > the topics, descriptions and wording. This is useful. Nitpicks follow. + If executed in a subtransaction this will return the top-level xid. I'd prefer it with a comma after "subtransaction" +SQL Standard. PostgreSQL supports SAVEPOINTs through the implementation +defined mechanism of subtransactions, which offer a superset of the required implementation-defined +features. Prepared transactions allow PostgreSQL to implement what SQL what *the + +All transactions are identified by a unique VirtualTransactionId (virtualxid or +vxid), e.g. 4/12532, which is comprised of the BackendId (in this example, 4) +and a sequentially assigned number unique to that backend, known as LocalXid sequentially-assigned + +If a transaction attempts to write to the database it will be assigned a database comma +property is used by the transaction system to say that if one xid is earlier +than another xid then the earlier transaction attempted to write before the xid comma then + +Currently executing transactions are shown in the pg_locks view in columns currently-executing +"virtualxid" (text) and "transactionid" (xid), if an xid has been assigned. maybe remove the "if assigned" part, since it's described next? +Read transactions will have a virtualxid but a NULL xid, while write +transactions will have both a virtualxid and an xid assigned. + + +Row-level read locks may require the assignment of a multixact ID (mxid), which +are recorded in the pg_multixact directory. which *is ? +top-level transaction. Subtransactions can also be started from other +subtransactions. As a result, the arrangement of transaction and subtransactions transactions (plural) ? +form a hierarchy or tree. Thus, each subtransaction has one parent transaction. +At present in PostgreSQL, only one transaction or subtransaction can be active at +one time. one time per command/query/request. +Subtransactions may end via a commit or abort without affecting their parent may end either by committing or aborting, without .. +transaction, allowing the parent transaction to continue. +also be started in other ways, such as PL/pgSQL's EXCEPTION clause. PL/Python and +PL/TCL also support explicit subtransactions. Working with C API, users may also +call BeginInternalSubTransaction(). *the C API ? +If a subtransaction is assigned an xid, we refer to this as a subxid. Read-only +subtransactions are not assigned a subxid, but when a subtransaction attempts to +write it will be assigned a subxid. We ensure that all of a subxid's parents, up write comma. Or say: "subxid is not assigned until the subtransaction attempts to write" ? + +The more subtransactions each transaction uses, the greater the overhead for +transaction management. Up to 64 subxids are cached in shmem for each backend, backend semicolon +Those commands are extensions to the SQL Standard, since the SQL syntax is not yet +yet part of the standard, though the Standard does refer to encompassing yet yet +Information relating to these is stored in pg_twophase. Currently prepared s/these/two-phase commits/ +transactions can be inspected using pg_prepared_xacts view. + currently-prepared ?