| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: 011_crash_recovery.pl intermittently fails |
| Date: | 2021-03-08 01:09:33 |
| Message-ID: | 1690207.1615165773@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> Thanks! I'm afraid I wouldn't get around to it for a few weeks, so if
> you have time, please do. (I'm not sure if it's strictly necessary to
> log *this* xid, if a higher xid has already been logged, considering
> that the goal is just to avoid getting confused about an xid that is
> recycled after crash recovery, but coordinating that might be more
> complicated; I don't know.)
Yeah, ideally the patch wouldn't add any unnecessary WAL flush,
if there's some cheap way to determine that our XID must already
have been written out. But I'm not sure that it's worth adding
any great amount of complexity to avoid that. For sure I would
not advocate adding any new bookkeeping overhead in the mainline
code paths to support it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | houzj.fnst@fujitsu.com | 2021-03-08 01:25:36 | RE: Parallel INSERT (INTO ... SELECT ...) |
| Previous Message | David Fetter | 2021-03-08 01:09:22 | Re: [PATCH] pg_permissions |