| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Noah Misch <noah(at)leadboat(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Temporary tables versus wraparound... again |
| Date: | 2022-12-14 21:43:52 |
| Message-ID: | CAM-w4HPvg7C0J9GRs90697f78+Xw6dDkDin47tu+4y+qMz1dyA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> You do have to lock a table in order to update its pg_class row,
> though, whether the table is temporary or not. Otherwise, another
> session could drop it while you're doing something with it, after
> which bad things would happen.
I was responding to this from Andres:
> Is that actually true? Don't we skip some locking operations for temporary
> tables, which then also means catalog modifications cannot safely be done in
> other sessions?
I don't actually see this in the code but in any case we're not doing
any catalog modifications here. We're just inspecting values of
relfrozenxid and relminmxid in the struct returned from
SearchSysCache. Which I think is no different for temp tables than any
other table.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2022-12-14 21:45:45 | Re: Error-safe user functions |
| Previous Message | Robert Haas | 2022-12-14 21:22:56 | Re: Temporary tables versus wraparound... again |