Remove log segment and log_id fields from pg_controldata
От | Bruce Momjian |
---|---|
Тема | Remove log segment and log_id fields from pg_controldata |
Дата | |
Msg-id | 200702040137.l141bX018660@momjian.us обсуждение исходный текст |
Ответ на | Re: Configuring BLCKSZ and XLOGSEGSZ (in 8.3) ("Simon Riggs" <simon@2ndquadrant.com>) |
Ответы |
Re: Remove log segment and log_id fields from pg_controldata
|
Список | pgsql-hackers |
The original discussion of this patch was here: http://archives.postgresql.org/pgsql-hackers/2006-11/msg00876.php Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --------------------------------------------------------------------------- Simon Riggs wrote: > On Tue, 2006-12-05 at 17:26 -0500, Tom Lane wrote: > > "Simon Riggs" <simon@2ndquadrant.com> writes: > > > On Tue, 2006-12-05 at 16:24 -0500, Tom Lane wrote: > > >> Sure, what would happen is that every backend passing through this code > > >> would execute the several lines of computation needed to decide whether > > >> to call RequestCheckpoint. > > > > > Right, but the calculation uses RedoRecPtr, which may not be completely > > > up to date. So presumably you want to re-read the shared memory value > > > again to make sure we are exactly accurate and allow only one person to > > > call checkpoint? Either way we have to take a lock. Insert lock causes > > > deadlock, so we would need to use infolock. > > > > Not at all. It's highly unlikely that RedoRecPtr would be so out of > > date as to result in a false request for a checkpoint, and if it does, > > so what? Worst case is we perform an extra checkpoint. > > On its own, I wouldn't normally agree... > > > Also, given the current structure of the routine, this is probably not > > the best place for that code at all --- it'd make more sense for it to > > be in the just-finished-a-segment code stretch, which would ensure that > > it's only done by one backend once per segment. > > But thats a much better plan since it requires no locking. > > There's a lot more changes there for such a simple fix though and lots > more potential bugs, but I've coded it as you suggest and removed the > fields from pg_control. > > Patch passes make check, applies cleanly on HEAD. > pg_resetxlog and pgcontroldata tested. > > > -- > Simon Riggs > EnterpriseDB http://www.enterprisedb.com > [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: