| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock |
| Date: | 2022-08-10 05:35:09 |
| Message-ID: | CA+hUKGL4VswoOsqqkeH99aExY-NL35qjst2DKK-PRpTxCKJ0OQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Aug 10, 2022 at 5:28 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I don't think it's a safe assumption that nobody would hold a pin on such a
> page during recovery. While not the case here, somebody else could have used
> pg_prewarm to read it in.
>
> But also, the checkpointer or bgwriter could have it temporarily pinned, to
> write it out, or another backend could try to write it out as a victim buffer
> and have it temporarily pinned.
Right, of course. So it's just that hash indexes didn't get xlog'd
until 2017, and still aren't very popular, and then recovery didn't
get regression tested until 2021, so nobody ever hit it.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2022-08-10 05:36:41 | Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock |
| Previous Message | Andres Freund | 2022-08-10 05:28:30 | Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock |