| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Geoff Winkless <pg(at)ukku(dot)uk> |
| Cc: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: UNLOGGED table CREATEd on one connection not immediately visible to another connection |
| Date: | 2026-01-29 15:41:27 |
| Message-ID: | 1223180.1769701287@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Geoff Winkless <pg(at)ukku(dot)uk> writes:
> In our application we have a situation where once a day one process
> CREATEs an UNLOGGED table and INSERTs several hundred records using
> individual queries (no explicit transactions) all of which return
> successfully. We then send the ID of the table that we have created
> over a TCP socket to a second process, which runs a query that JOINs
> against that new table.
> Unfortunately quite often the second process is getting a
> PGRES_FATAL_ERROR with
> Primary: relation "qreftmp750" does not exist
> Now (and this is very important) this appears to be a race condition,
> because when that process immediately retries the same query (which we
> do when we get FATAL_ERROR) it sometimes works on the second or third
> (or even 11th) attempt.
Perhaps the second process is querying a standby server rather than
the primary? Replication lag could explain this. I don't really
believe that it's possible within a single PG server, though.
We take very substantial pains to avoid the race condition you're
positing.
If there is anything in your client software stack capable of issuing
implicit begin/commit, that'd deserve a second/third/fourth look...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PetSerAl | 2026-01-29 17:58:52 | Re: About backups |
| Previous Message | Adrian Klaver | 2026-01-29 15:09:42 | Re: UNLOGGED table CREATEd on one connection not immediately visible to another connection |