| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, rootcause000(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows |
| Date: | 2024-04-23 07:48:12 |
| Message-ID: | CA+hUKG+5nfWcpnZ=Z=UpGvY1tTF=4QU_0U_07EFaKmH7Nr+NLQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Related bug #18426 sent me back here.
Here is a new attempt to see what it might take to put
RelationTruncate() into a critical section. Problems encountered:
even if you've called mdnblocks() beforehand, dressed up as
smgrpreparetruncate(), if the highest segment is exactly full then the
later mdnblocks() again probes whether the next segment number exists
on disk, which involves GetRelationPath(), which allocates. So I
finished up having to write a GetRelationPathInPlace() function, and
to decide whether it's OK to use a MAXPGPATH-sized array on the stack
for this. I also had to teach _fdvec_resize() not to reallocate when
downsizing, to avoid the critical section assertion. It seems like
quite a lot to back-patch... but also awful to leave this trickle of
data corruption reports unaddressed. The big re-engineering ideas[1]
would be absolutely unbackpatchable, but I hope we can work on
something like that for 18...
[1] https://www.postgresql.org/message-id/flat/2348.1544474335%40sss.pgh.pa.us
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-RelationTruncate-must-set-DELAY_CHKPT_START.patch | text/x-patch | 3.9 KB |
| v2-0002-RelationTruncate-must-use-a-critical-section.patch | text/x-patch | 16.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kostiantyn Tomakh | 2024-04-23 09:58:21 | Fwd: BUG #18433: Logical replication timeout |
| Previous Message | Michael Paquier | 2024-04-23 05:37:56 | Re: BUG #15954: Unable to alter partitioned table to set logged |