| From: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: Improve XLOG_NO_TRAN related comments |
| Date: | 2005-12-25 21:44:41 |
| Message-ID: | Pine.LNX.4.58.0512251633340.28412@eon.cs |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
On Sat, 24 Dec 2005, Tom Lane wrote:
>
> Removing these comments entirely, without changing the code they explain,
> doesn't strike me as an improvement.
>
I just checked if we can remove XLOG_NO_TRAN happily, and the conclusion
is that it could bring some benefits (though not much) to our system. The
key is the CheckpointStartLock lock. If we remove XLOG_NO_TRAN, then even
statement like this will block/wait checkpoint:
SELECT nextval('serial');
Of course, we can add a test in XLogInsert() to solve this problem like
this:
no_tran == ((rmid == RM_XLOG_ID) || (rmid == RM_SEQ_ID) || ...)
But the better way is leave XLOG_NO_TRAN for now till we find a way to
avoid CheckpointStartLock lock.
Regards,
Qingqing
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2005-12-25 23:35:45 | Re: [PATCHES] default resource limits |
| Previous Message | Euler Taveira de Oliveira | 2005-12-25 20:56:03 | Re: [HACKERS] to_char and i18n |