ssage-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 23, 2006 1:41 PM
To: Ray Stell
Cc: theman; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] COPY FROM command v8.1.4
Ray Stell <[EMAIL PROTECTED]> writes:
> Curious how you get to an OS kernel bug from these writes?
Ray Stell <[EMAIL PROTECTED]> writes:
> Curious how you get to an OS kernel bug from these writes?
Note the two successive lseek's returning the same result. With a
write() in between that should have extended the file, that is clearly
the wrong answer.
Subsequent discussion reveals that Dan is
Curious how you get to an OS kernel bug from these writes? Aren't we
missing the associated db reads in this trc data? Maybe there been
other data provided off the list? Would love to see it.
Thanks.
On Fri, Sep 22, 2006 at 05:59:31PM -0400, Tom Lane wrote:
> "theman" <[EMAIL PROTECTED]> wr
"theman" <[EMAIL PROTECTED]> writes:
> lseek(10, 0, SEEK_END) = 913072128
> write(10, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192)
> = 8192
> lseek(10, 0, SEEK_END) = 913080320
> write(10, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
Tom Lane <[EMAIL PROTECTED]>
To: "Mr. Dan" <[EMAIL PROTECTED]>
CC: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] COPY FROM command v8.1.4 Date: Wed, 13 Sep 2006
12:50:26 -0400
"Mr. Dan" <[EMAIL PROTECTED]> writes:
>> How are you doing the copies, exact
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 loc
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 missi
Hi,
Any update on this ?
--robert
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mr. Dan
Sent: Thursday, 14 September 2006 11:14 PM
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] COPY FROM command v8.1.4
Hi Ray,
I've tried "it" on
Hi Ray,
I've tried "it" on both WAFL and Reiser filesystems and gotten either 0,1,
or 2 blocks of 25 rows missing. I haven't tried it on ext3 or JFS. No, I
haven't seen any problems in the syslogs and I haven't seen any drops on the
network in regards to WAFL. Reiser is the local filesyste
You said "local Reiser FS." Maybe repeat on one of the others, Ext3/JFS?
Tom asked about hardware issues, is there nothing in syslog
that relates to the timing of the event? I don't recall you
responding in public to this. Maybe I missed it.
Just musing...
On Wed, Sep 13, 2006 at 12:5
"Mr. Dan" <[EMAIL PROTECTED]> writes:
>> How are you doing the copies, exactly? SQL COPY command, psql \copy,
>> something else?
> We've tried SQL COY and psql \copy and always get random results - 0,1, or 2
> blocks of 25 rows missing.
Hmph. If it happens with a SQL COPY command then psql see
This is pretty confusing. You mean that groups of 25 adjacent rows were
missing in the output?
Yes, isn't that interesting? It's always in a group of 25 rows. This is
always random. Say 800,000 to 800,025 out of 12 million represents one
random group of 25 rows.
What's the (24+1) supp
"Mr. Dan" <[EMAIL PROTECTED]> writes:
> Looking back and comparing the data, we realized that its always missing
> rows in 25 (24+1) rows sequences or we're calling it a block. So, there were
> 2 blocks of 25 missing in the 2nd attempt and 4 blocks of 25 missing in the
> third.
This is pretty
This behavior is on big tables.
6.5 GB - 12+ million records
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Yes - we are doing select count(*) fromÂ… the stats are worthless until you
vacuum and we aren't running vacuum. Plus those change too often to be
reliable, they just make a good guess
---(end of broadcast)---
TIP 9: In versions below 8.0, the pl
No, there are different blocks of records missing every time.
If you repeat the entire experiment, are the same records missing each
time? I'm wondering about flaky hardware as much as anything.
---(end of broadcast)---
TIP 1: if posting/
Hi,
Thanks for this quick response.
##Try dumping the second table with COPY TO and diff'ing the dump files to
get more detail about what's missing.##
We tried 3 times from a local file system, instead of the NFS mount (to try
to rule out hardware)
1st attempt: the data copied over fine
2
Sorry Tom, Somone had not put the reply to header in correctly..
-- Forwarded message --
From: Peter Childs <[EMAIL PROTECTED]>
Date: 12-Sep-2006 10:16
Subject: Re: [ADMIN] COPY FROM command v8.1.4
To: Tom Lane <[EMAIL PROTECTED]>
On 11/09/06, Tom Lane <[
"Mr. Dan" <[EMAIL PROTECTED]> writes:
> We have a table with 12028587 records in it.
> We do a COPY TO file of the records for this table.
> We count the number of records in the file, it has 12028587 lines.
> We do a COPY FROM that file into a table with identical structure as the
> first table.
We are having some serious problems with the PostgreSQL COPY FROM command
and we have no clue what to do with this at this point. I think we need to
ask for 'guru' help in diagnosing this problem. Here is exactly what we are
doing:
We have a table with 12028587 records in it.
We do a COPY TO f
20 matches
Mail list logo
