| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Xuneng Zhou <xunengzhou(at)gmail(dot)com> |
| Cc: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BGWORKER_INTERRUPTIBLE workers are never restarted after DROP/ALTER/CREATE DATABASE |
| Date: | 2026-11-09 03:42:52 |
| Message-ID: | avFBPPOg8-5RrmCA@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Nov 09, 2026 at 11:37:22AM +0800, Xuneng Zhou wrote:
>> There may be something with threading here, actually, we've
>> mentioned that as we could not rely on PIDs anymore, should the switch
>> to threads happen, then a concept of session number would be required.
>> If it is 8-byte wide, the PID rotation concern is moot.
>
> I don't follow this well. Does this mean that this is not a problem
> after threading?
Under a threading infrastructure, PIDs have no meaning. So, assuming
that a concept of session IDs is used to replace how we internally
track each thread for the SQL interface, and assuming that this is 8
byte wide, then the PID wraparound concerns would be entirely gone.
This relies on three ifs.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-11-09 03:45:46 | Re: BGWORKER_INTERRUPTIBLE workers are never restarted after DROP/ALTER/CREATE DATABASE |
| Previous Message | Xuneng Zhou | 2026-11-09 03:37:22 | Re: BGWORKER_INTERRUPTIBLE workers are never restarted after DROP/ALTER/CREATE DATABASE |