pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedDuring Xlog replaying, is there maybe emitted xlog?
3+ messages / 2 participants
[nested] [flat]
* During Xlog replaying, is there maybe emitted xlog?
@ 2012-07-18 01:29 xu2002261 <xu2002261@163.com>
0 siblings, 1 reply; 3+ messages in thread
From: xu2002261 @ 2012-07-18 01:29 UTC (permalink / raw)
To: pgsql-hackers
Hi all,
I reviewed the source code, and saw the following calling path:
StartupXLOG() > StartupDatabase() > RmgrTable[rmid].rm_cleanup() > btree_xlog_cleanup() > _bt_insert_parent > _bt_insertonpg() > XLogInsert()
As we can see, during xlog replaying, XLog may be emitted. So whether there are some *ISSUE* in above calling stack?
thanks.
发信日期：2012-07-18
xu2002261
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: During Xlog replaying, is there maybe emitted xlog?
@ 2012-07-18 02:05 Tom Lane <tgl@sss.pgh.pa.us>
parent: xu2002261 <xu2002261@163.com>
0 siblings, 1 reply; 3+ messages in thread
From: Tom Lane @ 2012-07-18 02:05 UTC (permalink / raw)
To: xu2002261 <xu2002261@163.com>; +Cc: pgsql-hackers
"xu2002261" <xu2002261@163.com> writes:
> Hi all,
> I reviewed the source code, and saw the following calling path:
> StartupXLOG() > StartupDatabase() > RmgrTable[rmid].rm_cleanup() > btree_xlog_cleanup() > _bt_insert_parent > _bt_insertonpg() > XLogInsert()
> As we can see, during xlog replaying, XLog may be emitted. So whether there are some *ISSUE* in above calling stack?
No, it's entirely correct. That path isn't "during" replay, it's upon
completion of replay, where we're cleaning up anything that failed to be
completed before the crash. Emitting more WAL is allowed then. Note
the comment a few lines above the rm_cleanup calls:
/*
* Resource managers might need to write WAL records, eg, to record
* index cleanup actions. So temporarily enable XLogInsertAllowed in
* this process only.
*/
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: During Xlog replaying, is there maybe emitted xlog?
@ 2012-07-18 02:16 xu2002261 <xu2002261@163.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 3+ messages in thread
From: xu2002261 @ 2012-07-18 02:16 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
Thanks a lot.
oops, indeed, the clean up stage is not in the XLog replay, So there is no problem.
2012-07-18
xu2002261
发件人： Tom Lane
发送时间： 2012-07-18 10:05:26
收件人： xu2002261
抄送： pgsql-hackers
主题： Re: [HACKERS] During Xlog replaying, is there maybe emitted xlog?
"xu2002261" <xu2002261@163.com> writes:
> Hi all,
> I reviewed the source code, and saw the following calling path:
> StartupXLOG() > StartupDatabase() > RmgrTable[rmid].rm_cleanup() > btree_xlog_cleanup() > _bt_insert_parent > _bt_insertonpg() > XLogInsert()
> As we can see, during xlog replaying, XLog may be emitted. So whether there are some *ISSUE* in above calling stack?
No, it's entirely correct. That path isn't "during" replay, it's upon
completion of replay, where we're cleaning up anything that failed to be
completed before the crash. Emitting more WAL is allowed then. Note
the comment a few lines above the rm_cleanup calls:
/*
* Resource managers might need to write WAL records, eg, to record
* index cleanup actions. So temporarily enable XLogInsertAllowed in
* this process only.
*/
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2012-07-18 02:16 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2012-07-18 01:29 During Xlog replaying, is there maybe emitted xlog? xu2002261 <xu2002261@163.com>
2012-07-18 02:05 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-07-18 02:16 ` xu2002261 <xu2002261@163.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox