Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG
От | Andres Freund |
---|---|
Тема | Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG |
Дата | |
Msg-id | 20140325180523.GA26658@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG
|
Список | pgsql-hackers |
On 2014-03-25 10:49:54 -0700, Robert Haas wrote: > On Tue, Mar 25, 2014 at 12:30 AM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: > >>> I've found WAL_DEBUG quite useful in the past, when working on > >>> scalability, and have indeed wished for it to be > >>> compiled-in-by-default. > >>> > >>> I don't know whether I'm the only one, though. > >> > >> You are not. I would rather have it fixed than removed, if possible. I > >> don't really care too much about getting a performance hit to palloc the > >> records, really; being able to actually read what's happening is much > >> more useful. > > > > I find it useful too, but I think pg_xlogdump can serve the same purpose. > > > > One thing missing from pg_xlogdump is the capability to keep tracking the > > inserted WAL, instead of dumping to the end of WAL and stopping there. If we > > add an option to pg_xlogdump to poll the WAL instead of bailing out at an > > error, I think it's a good replacement. > > Well, one nice thing about wal_debug is that the WAL is at that point > still associated with the session that generated it. But I grant > that's not a huge issue. How much work are we talking about to fix > this, though? It's not entirely trivial, we'd essentially need to copy the loop in CopyXLogRecordToWAL(). And do so while still holding the WALInsertLock(). Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: