| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: [HACKERS] WAL logging freezing |
| Date: | 2006-10-31 15:06:40 |
| Message-ID: | 29109.1162307200@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> I got another idea. If we make sure that vacuum removes any aborted xid
> older than OldestXmin from the table, we can safely assume that any xid
> < the current clog truncation point we are going to be interested in is
> committed. Vacuum already removes any tuple with an aborted xmin. If we
> also set any aborted xmax (and xvac) to InvalidXid, and WAL logged that,
The problem with that is all the extra WAL log volume it creates. I'm
also concerned about the loss of forensic information --- xmax values
are frequently useful for inferring what's been going on in a database.
(This is another reason for not wanting a very short freeze interval BTW.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Huxton | 2006-10-31 16:01:01 | Re: View updating and nextval() workaround - will this |
| Previous Message | Tom Lane | 2006-10-31 15:02:23 | Re: View updating and nextval() workaround - will this ever break? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-10-31 16:04:55 | Re: [HACKERS] WAL logging freezing |
| Previous Message | Simon Riggs | 2006-10-31 14:24:12 | Re: [HACKERS] WAL logging freezing |