| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Have BackendXidGetPid return pid_t |
| Date: | 2025-11-14 20:52:14 |
| Message-ID: | 3233362.1763153534@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Sami Imseih <samimseih(at)gmail(dot)com> writes:
> While looking at something nearby, I noticed that BackendXidGetPid()
> uses an "int" for "pid", where it should be used "pid_t" like in other
> places in the code including in procarray.c.
I don't think this is an amazingly good idea, considering that the
value it's returning is from an "int" field in struct PGPROC.
You didn't change the function's "result" variable either, nor
is it clear what callers like
snprintf(buf, NCHARS, "%d",
BackendXidGetPid(members[j].xid));
should be doing.
Perhaps at some point we should try to uniformly represent PIDs
as pid_t, but it'll require a far larger patch than this.
(I have a vague recollection also that some places expect PIDs in
shared memory to be atomically updatable, so machines where pid_t
is actually different from int might start to have issues.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2025-11-14 21:07:36 | Re: should we have a fast-path planning for OLTP starjoins? |
| Previous Message | Sami Imseih | 2025-11-14 20:40:36 | Have BackendXidGetPid return pid_t |