On Mon, Sep 26, 2016 at 8:54 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Sun, Sep 25, 2016 at 9:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Amit Kapila <amit.kapil...@gmail.com> writes: >>> On Fri, Sep 23, 2016 at 12:21 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>>> This is clearly an oversight in Simon's patch fafa374f2, which introduced >>>> this code without any consideration for the possibility that the page >>>> doesn't have a valid special area. ... >>>> but I'm not very clear on whether this is a safe fix, mainly because >>>> I don't understand what the reuse WAL record really accomplishes. >>>> Maybe we need to instead generate a reuse record with some special >>>> transaction ID indicating worst-case assumptions? >> >>> I think it is basically to ensure that the queries on standby should >>> not be considering the page being recycled as valid and if there is >>> any pending query to which this page is visible, cancel it. If this >>> understanding is correct, then I think the fix you are proposing is >>> correct. >> >> After thinking about it some more, I do not understand why we are emitting >> WAL here at all in *any* case, either for a new page or for a deleted one >> that we're about to recycle. Why wouldn't the appropriate actions have >> been taken when the page was deleted, or even before that when its last >> tuple was deleted? >> > > It seems to me that we do take actions for conflict resolution during > the page deletion (that looks to be covered by XLOG_HEAP2_CLEANUP_INFO > which we emit in vacuum), but not sure if that is sufficient. > Consider a case where the new transaction is started on standby after >
Here by new transaction, I intend to say some newer snapshot with valid MyPgXact->xmin. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
