Could you please keep this inline. Is there some reason the community
should not be able to read about debug logic? I asked this question
last week, no reply. Now, Mr. Dan is asking the same.
'What is the logic being followed here by ctid verification? You collect
from the original db the locations of the rows that come up missing on
the target db. How does that lead to an understanding of where the rows
"went?"'
Not knowing how pg technology would be used to trace what is going on
is limiting. If you could move to solaris 10 and use dtrace to turn on
reporting based on some logic that draws you near to the "problem" rows,
that might make the trace data more manageable. Also, it might point
to/away from an os problem. I don't see how else you can determine what
is going on, but I sure would like to hear about the tools that are used
for this purpose in pg. Please let us be informed.
On Tue, Sep 19, 2006 at 04:01:41PM -0400, Mr. Dan wrote:
>
> Hi Tom,
>
> Sorry - to all my groupies out there for the time delay :) -
>
> It's a rather time consuming endeavor.
>
> Ok the ctid numbers did all seem to match for the group of 25 rows that
> disappear.
>
> For example., ctiid (146649,1) to (146649,25) represented a group or block
> of 25 rows that go missing. I have 44 total columns including the system
> objects. In case it helps, here's my data types.
>
> I'm not following exactly what these results mean. Are you saying because
> it has the same ctid that it's a hardware problem? I would find that
> difficult to believe because I've reproduced this on 2 different file
> systems WAFL and REISER FS with totally different hard drives.
>
>
> varchar(14) NOT NULL,
> varchar(9) NOT NULL,
> varchar(4) NOT NULL,
> varchar(14),
> varchar(25) NOT NULL,
> char(1) NOT NULL,
> char(4) NOT NULL,
> char(1) NOT NULL,
> char(1) NOT NULL,
> char(3) NOT NULL,
> char(1) NOT NULL,
> char(2),
> char(12),
> umeric(7,3) NOT NULL,
> char(1) NOT NULL,
> char(1) NOT NULL,
> varchar(8) NOT NULL,
> char(3) NOT NULL,
> char(2) NOT NULL,
> char(3) NOT NULL,
> char(3) NOT NULL,
> int4 NOT NULL,
> int4 NOT NULL,
> char(1) NOT NULL,
> timestamp,
> timestamp,
> timestamp NOT NULL,
> timestamp NOT NULL,
> int4,
> char(5),
> varchar(14),
> int4,
> char(1),
> numeric(12,3),
> numeric(12,3),
> char(1),
> char(1),
> nuumeric(4,3)
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
--