On 03/26/2014 04:51 PM, Robert Haas wrote:
On Wed, Mar 26, 2014 at 5:08 AM, Heikki Linnakangas
wrote:
Oh, no, there's no need to do it while holding WALInsertLock. It's quite
trivial, actually, see attached. So it's not difficult to fix this if we
want to.
Well is there any reason not to just
On Wed, Mar 26, 2014 at 5:08 AM, Heikki Linnakangas
wrote:
> Oh, no, there's no need to do it while holding WALInsertLock. It's quite
> trivial, actually, see attached. So it's not difficult to fix this if we
> want to.
Well is there any reason not to just commit that patch? I mean, it
seems odd
On 03/25/2014 08:05 PM, Andres Freund wrote:
On 2014-03-25 10:49:54 -0700, Robert Haas wrote:
On Tue, Mar 25, 2014 at 12:30 AM, Heikki Linnakangas
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 d
On 2014-03-25 10:49:54 -0700, Robert Haas wrote:
> On Tue, Mar 25, 2014 at 12:30 AM, Heikki Linnakangas
> 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 whethe
On Tue, Mar 25, 2014 at 12:30 AM, Heikki Linnakangas
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
Heikki Linnakangas wrote:
> On 03/25/2014 02:13 AM, Alvaro Herrera wrote:
> >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
On 03/25/2014 02:13 AM, Alvaro Herrera wrote:
Robert Haas wrote:
On Mon, Mar 24, 2014 at 7:14 AM, Tom Lane wrote:
3. Remove the feature altogether, so that enabling wal_debug doesn't
cause all insertions to be logged anymore (no changes to the logging
during replay). It's a lot less interest
Robert Haas wrote:
> On Mon, Mar 24, 2014 at 7:14 AM, Tom Lane wrote:
> >> 3. Remove the feature altogether, so that enabling wal_debug doesn't
> >> cause all insertions to be logged anymore (no changes to the logging
> >> during replay). It's a lot less interesting now that we have pg_xlogdump.
On Mon, Mar 24, 2014 at 7:14 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> As we all know, when you compile with WAL_DEBUG, and enable wal_debug
>> GUC, you get output like this in the log for every inserted WAL record:
>
>> LOG: INSERT @ 0/5407E578: prev 0/5407E4D0; xid 0; len 32: Standby
Heikki Linnakangas writes:
> As we all know, when you compile with WAL_DEBUG, and enable wal_debug
> GUC, you get output like this in the log for every inserted WAL record:
> LOG: INSERT @ 0/5407E578: prev 0/5407E4D0; xid 0; len 32: Standby -
> running xacts: nextXid 774 latestCompletedXid 771
As we all know, when you compile with WAL_DEBUG, and enable wal_debug
GUC, you get output like this in the log for every inserted WAL record:
LOG: INSERT @ 0/5407E578: prev 0/5407E4D0; xid 0; len 32: Standby -
running xacts: nextXid 774 latestCompletedXid 771 oldestRunningXid 772;
2 xacts: 78
11 matches
Mail list logo
