Re: Reviewing freeze map code
От | Robert Haas |
---|---|
Тема | Re: Reviewing freeze map code |
Дата | |
Msg-id | CA+TgmoY7Odeb3yxLC6WUm3jf5CRKyj4S9kw28fk8u4hyX1W7Gg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Reviewing freeze map code (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Jun 21, 2016 at 10:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Jun 20, 2016 at 5:59 PM, Andres Freund <andres@anarazel.de> wrote: >>> Consider what happens if we, after restarting at l2, notice that we >>> can't actually insert, but return in the !HeapTupleMayBeUpdated >>> branch. > >> OK, I see what you mean. Still, that doesn't seem like such a >> terrible cost. If you try to update a tuple and if it looks like you >> can update it but then after TOASTing you find that the status of the >> tuple has changed such that you can't update it after all, then you >> might need to go set xmax = MyTxid() on all of the TOAST tuples you >> created (whose CTIDs we could save someplace, so that it's just a >> matter of finding them by CTID to kill them). > > ... and if you get an error or crash partway through that, what happens? Then the transaction is aborted anyway, and we haven't leaked anything because VACUUM will clean it up. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: