| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, Thunder <thunder1(at)126(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: PANIC :Call AbortTransaction when transaction id is no normal |
| Date: | 2019-05-13 23:53:36 |
| Message-ID: | 20190513235336.GE2273@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, May 13, 2019 at 09:37:32AM -0400, Tom Lane wrote:
> But ... that code's been like that for decades and nobody's complained
> before. Why are we worried about bootstrap's response to signals at all?
Yeah, I don't think that it is something worth bothering either. As
you mentioned the data folder would be removed by default. Or perhaps
the reporter has another case in mind which could justify a change in
the signal handlers? I am ready to hear that case, but there is
nothing about the reason why it could be a benefit.
The patch proposed upthread is not something I find correct anyway,
I'd rather have the abort path complain loudly about a bootstrap
transaction that fails instead of just ignoring it, because it is the
kind of transaction which must never fail. And it seems to me that it
can be handy for development purposes.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-05-14 00:32:04 | Re: How to install login_hook in Postgres 10.5 |
| Previous Message | Nasby, Jim | 2019-05-13 22:59:50 | Re: PostgreSQL 12 Beta 1 Release: 2019-05-23 |