| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jialun Zhang <reatank(at)gmail(dot)com> |
| Cc: | Gerald Cheves <gcheves(at)verizon(dot)net>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-novice(at)lists(dot)postgresql(dot)org |
| Subject: | Re: What's the best practice to compare the transaction with the checkpoint? |
| Date: | 2020-07-06 15:44:35 |
| Message-ID: | 1377221.1594050275@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-novice |
Jialun Zhang <reatank(at)gmail(dot)com> writes:
> Actually I am trying to add file support for TOAST. I mean store the
> toasted value in the file system and leave a file path in the toast
> pointer.
Why in the world would that be a good idea?
> Therefore, for garbage collection, we need to remove the file
> after confirming that a deleted tuple is older than the latest checkpoint.
Even granting that shoving each toasted value into its own file is a
sane design, I do not see why you'd need to invent a GC mechanism for it.
Seems like you could drive removal of the file off vacuum's removal of
the parent tuple.
Moreover, even if you want to do it like that, you still don't need to
know whether the deleting transaction is older than the last checkpoint;
indeed that's entirely the wrong question. What you need to know is
whether it's older than global xmin, so that it's certain no other
transaction will wish to fetch the field value.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jialun Zhang | 2020-07-06 16:23:31 | Re: What's the best practice to compare the transaction with the checkpoint? |
| Previous Message | Jialun Zhang | 2020-07-06 15:27:39 | Re: What's the best practice to compare the transaction with the checkpoint? |