Re: PITR Phase 2 - Design Planning
От | Andrew Dunstan |
---|---|
Тема | Re: PITR Phase 2 - Design Planning |
Дата | |
Msg-id | 3209.24.211.141.25.1083196945.squirrel@www.dunslane.net обсуждение исходный текст |
Ответ на | Re: PITR Phase 2 - Design Planning (Simon Riggs <simon@2ndquadrant.com>) |
Список | pgsql-hackers |
Simon Riggs said: > On Wed, 2004-04-28 at 18:35, Andrew Dunstan wrote: >> Simon Riggs wrote: >> >> >On Wed, 2004-04-28 at 05:00, Bruce Momjian wrote: >> > >> > >> >>What if we added transaction id to log_line_prefix? The user could >> >>then log all queries and find the xid where they want to stop, but >> >>of course that assumes they have enabled such logging, and they have >> >>access to the logs. >> >> >> >> >> > >> >Good thinking. >> > >> >I'll have a look at this and come back to you. >> > >> log_statement triggered logging happens very early in the process - if >> you are logging them all it happens before the statements are even >> parsed. Would we have an xid to log sensibly at that stage? >> >> Perhaps with log_min_duration_statment = 0 we would (i.e. log >> statements when finished rather than when started). >> > > Let's call this XLogSpy. > > For starters, we only need to look at write transactions. Many > read-only transactions would not need to be examined, just to know they > were read only. > > Remembering that we're using xlogs for recovery, we perhaps should not > assume that we have anything other than that which has been archived. > Currently, that is just the xlogs. So really we need to work off what > is within them and right now that isn't much at all. > > We might optionally include the parsed statement data into the xlog, > since this might be smaller than the exact text itself and would also > allow us to filter the xlogs based upon any aspect of the lists. > > Not really happy with any of these ideas yet. > I don't see how this relates to the log_line_prefix idea, or are you abandoning that? cheers andrew
В списке pgsql-hackers по дате отправления: