On Thu, Oct 11, 2012 at 07:06:15PM -0400, Tom Lane wrote:
> Markus Wanner writes:
> > On 10/11/2012 03:11 PM, Tom Lane wrote:
> >> The original design intention was that rm_desc should not attempt to
> >> print any such data, but obviously some folks didn't get the word.
>
> > FWIW: in case the s
On 10/11/2012 04:06 PM, Tom Lane wrote:
> Yeah, if we decide to stick with the limitation, some documentation
> would be called for. I remember having run into this and having removed
> functionality from an rm_desc function rather than question the premise.
> But maybe the extra functionality is
Markus Wanner writes:
> On 10/11/2012 03:11 PM, Tom Lane wrote:
>> The original design intention was that rm_desc should not attempt to
>> print any such data, but obviously some folks didn't get the word.
> FWIW: in case the source code contains comments explaining that
> intention, I certainly
Tom,
On 10/11/2012 03:11 PM, Tom Lane wrote:
> The original design intention was that rm_desc should not attempt to
> print any such data, but obviously some folks didn't get the word.
FWIW: in case the source code contains comments explaining that
intention, I certainly missed them so far.
Rega
Markus Wanner writes:
> I stumbled across a minor issue in xlog.c:1030: the WAL_DEBUG code block
> there passes rdata->data to the rm_desc() methode. However, that's only
> the first XLogRecData struct, not the entire XLog record. So the
> rm_desc() method effectively reports spurious data for any
Hi,
I stumbled across a minor issue in xlog.c:1030: the WAL_DEBUG code block
there passes rdata->data to the rm_desc() methode. However, that's only
the first XLogRecData struct, not the entire XLog record. So the
rm_desc() method effectively reports spurious data for any subsequent part.
Take a
