On Sun, Nov 06, 2011 at 09:34:24AM -0500, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > Any chance of getting the fix in patch format so we could test it on
> > this system?
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h=23998fe99c1220ba3a9eefee194e37ec1f14ae07
hi
jus
hubert depesz lubaczewski writes:
> checked lengths of the text/varchar columns in database.
> there are 16 such columns in the table.
> full report of lengths is in
> http://www.depesz.com/various/lengths.report.gz
> it was obtained using:
> select length( "first_text_column" ) as length_1, cou
On Fri, Nov 04, 2011 at 09:04:02PM -0400, Tom Lane wrote:
> that. And that they are the only rows that, in addition to the above
> conditions, contain data fields wide enough to require out-of-line
> toasting.
checked lengths of the text/varchar columns in database.
there are 16 such columns in
hubert depesz lubaczewski writes:
> Any chance of getting the fix in patch format so we could test it on
> this system?
http://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h=23998fe99c1220ba3a9eefee194e37ec1f14ae07
regards, tom lane
--
Sent via pgsql-general mail
On Fri, Nov 04, 2011 at 09:04:02PM -0400, Tom Lane wrote:
> Hah ... I have a theory.
>
> I will bet that you recently added some column(s) to the source table
> using ALTER TABLE ADD COLUMN and no default value, so that the added
> columns were nulls and no table rewrite happened. And that these
I wrote:
> A different line of thought is that there's something about these
> specific source rows, and only these rows, that makes them vulnerable to
> corruption during INSERT/SELECT. Do they by any chance contain any
> values that are unusual elsewhere in your table? One thing I'm
> wondering
On Friday, November 04, 2011 6:04:02 pm Tom Lane wrote:
> I wrote:
> > A different line of thought is that there's something about these
> > specific source rows, and only these rows, that makes them vulnerable to
> > corruption during INSERT/SELECT. Do they by any chance contain any
> > values th
On Fri, Nov 04, 2011 at 05:06:35PM -0700, Adrian Klaver wrote:
> Another question.
> Between 07/20/11 and this recent attempt did you do a CREATE TABLE AS on this
> table and not have corrupted rows?
don't remember.
Best regards,
depesz
--
The best thing about modern society is how easy it is
On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
> You said that pg_dump does not show the corruption. That could be
> because the data is coming out through the COPY code path instead of
> the SELECT code path. Could you try a pg_dump with --inserts (which
> will fetch the data with SEL
On Friday, November 04, 2011 3:43:48 pm hubert depesz lubaczewski wrote:
> On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
> > You said that pg_dump does not show the corruption. That could be
> > because the data is coming out through the COPY code path instead of
> > the SELECT code pa
hubert depesz lubaczewski writes:
> On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
>> You said that pg_dump does not show the corruption. That could be
>> because the data is coming out through the COPY code path instead of
>> the SELECT code path. Could you try a pg_dump with --inser
On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
> You said that pg_dump does not show the corruption. That could be
> because the data is coming out through the COPY code path instead of
> the SELECT code path. Could you try a pg_dump with --inserts (which
> will fetch the data with SEL
On Fri, Nov 04, 2011 at 06:18:55PM -0400, Tom Lane wrote:
> BTW, did you try the separate INSERT/SELECT yet? Does that show
> corruption?
pg_dump --inserts is still working.
i did create table (like), insert into ... select and it also shows the
problem, as I showed (with other data) in email:
2
I wrote:
> Good detective work. So now we at least have a believable theory about
> *what* is happening (something is stomping the first 8 data bytes of
> these particular rows), if not *why*.
Scratch that: something is stomping the first *six* bytes of data.
On a hunch I converted the original a
On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
> You said that pg_dump does not show the corruption. That could be
> because the data is coming out through the COPY code path instead of
> the SELECT code path. Could you try a pg_dump with --inserts (which
> will fetch the data with SEL
hubert depesz lubaczewski writes:
> OK. So based on it all, it looks like for some rows, first two columns got
> mangled.
Good detective work. So now we at least have a believable theory about
*what* is happening (something is stomping the first 8 data bytes of
these particular rows), if not *w
On 11/04/2011 01:47 PM, hubert depesz lubaczewski wrote:
On Fri, Nov 04, 2011 at 01:43:55PM -0700, Adrian Klaver wrote:
Does it tell you anything?
You are very thorough.
I hate mysteries. Especially the ones that break stuff.
Know the feeling.
I don't know enough about Postgres internal
On Fri, Nov 04, 2011 at 01:43:55PM -0700, Adrian Klaver wrote:
> >Does it tell you anything?
> You are very thorough.
I hate mysteries. Especially the ones that break stuff.
> I don't know enough about Postgres internals to be much help there.
> All I can point out is the problem seemed to appear
On 11/04/2011 01:17 PM, hubert depesz lubaczewski wrote:
On Thu, Nov 03, 2011 at 11:03:45PM +0100, hubert depesz lubaczewski wrote:
looking for some other info. will post as soon as i'll gather it, but
that will be in utc morning :(
I looked closer at the rows that got -1 xobject_id.
Does
On Thu, Nov 03, 2011 at 11:03:45PM +0100, hubert depesz lubaczewski wrote:
> looking for some other info. will post as soon as i'll gather it, but
> that will be in utc morning :(
I looked closer at the rows that got -1 xobject_id.
$ select magic_id, count(*) from qqq where xobject_id = -1 group
On Thu, Nov 03, 2011 at 06:02:04PM -0400, Tom Lane wrote:
> select * from pg_attribute where attrelid = 'sss.xobjects'::regclass
> and attisdropped;
no dropped columns.
looking for some other info. will post as soon as i'll gather it, but
that will be in utc morning :(
Best regards,
depesz
hubert depesz lubaczewski writes:
> i tried:
> create table qqq as select cmax as o_cmax, xmax as o_xmax, cmin as
> o_cmin, xmin as o_xmin, ctid as o_ctid, * from sss.xobjects;
> but the resulting table didn't have -1 values:
Oh, that's pretty interesting ... suggests that the targetlist has
> I would like to know the ctid's of the -1 rows in the copied table,
> along with the ctid's of the rows they share magic_ids with, and
> the ctid's of the rows with those same magic_ids in the original.
> I'm wondering whether the affected rows are physically clustered ...
i tried:
create table
Adrian Klaver writes:
> On Thursday, November 03, 2011 1:03:12 pm hubert depesz lubaczewski wrote:
>> as you can see counts of rows in created table are more or less
>> sensible, but whatever method I used - create table as, insert into,
>> using sychronized_scans (initially) or not (later) - copy
On Thursday, November 03, 2011 1:03:12 pm hubert depesz lubaczewski wrote:
> On Thu, Nov 03, 2011 at 10:55:20AM -0400, Tom Lane wrote:
>
> So, did some tests:
>
> as you can see counts of rows in created table are more or less
> sensible, but whatever method I used - create table as, insert int
On Thu, Nov 03, 2011 at 10:55:20AM -0400, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > index on xobject_id might be corrupted, but it doesn't explain that I
> > don't see duplicates with group_by/having query on xobjects, which uses
> > seqscan:
>
> I was just going to ask you to check
On Thursday, November 03, 2011 8:30:34 am hubert depesz lubaczewski wrote:
> On Thu, Nov 03, 2011 at 08:23:01AM -0700, Adrian Klaver wrote:
> > On Thursday, November 03, 2011 8:05:38 am hubert depesz lubaczewski wrote:
> > > On Thu, Nov 03, 2011 at 08:04:19AM -0700, Adrian Klaver wrote:
> > > > So
hubert depesz lubaczewski writes:
> other tests are running, but simple question - how to get number of rows
> affected from psql?
> create table xxx as select * from xobjects;
> returns just:
> SELECT
We fixed that in 9.0, but 8.4 won't provide the count (unless you care to
patch it). That's w
On Thu, Nov 03, 2011 at 08:23:01AM -0700, Adrian Klaver wrote:
> On Thursday, November 03, 2011 8:05:38 am hubert depesz lubaczewski wrote:
> > On Thu, Nov 03, 2011 at 08:04:19AM -0700, Adrian Klaver wrote:
> > > So just to be clear there is and never has been a -1 value for xobject_id
> > > in the
On Thu, Nov 03, 2011 at 04:21:37PM +0100, Alban Hertroys wrote:
> On 3 November 2011 09:25, hubert depesz lubaczewski wrote:
> > All looks good. pg_dump of the table also doesn't show any strange
> > problems, and is duplicate free. But:
> >
> > $ create table zzz as select * from sss.xobject
On Thursday, November 03, 2011 8:05:38 am hubert depesz lubaczewski wrote:
> On Thu, Nov 03, 2011 at 08:04:19AM -0700, Adrian Klaver wrote:
> > So just to be clear there is and never has been a -1 value for xobject_id
> > in the source table?
>
> yes. min value of xobject_id is 1000, and we had tr
On 3 November 2011 09:25, hubert depesz lubaczewski wrote:
> All looks good. pg_dump of the table also doesn't show any strange problems,
> and is duplicate free. But:
>
> $ create table zzz as select * from sss.xobjects;
> SELECT
>
> $ select xobject_id, count(*) from zzz group by 1 having c
On Thu, Nov 03, 2011 at 08:04:19AM -0700, Adrian Klaver wrote:
> So just to be clear there is and never has been a -1 value for xobject_id in
> the
> source table?
yes. min value of xobject_id is 1000, and we had trigger in place on the
table which logged all inserts/updates/deletes and the val
On Thursday, November 03, 2011 7:15:22 am hubert depesz lubaczewski wrote:
> On Thu, Nov 03, 2011 at 07:00:30AM -0700, Adrian Klaver wrote:
> > > I also verified that there are no concurrent updates that would set
> > > xobject_id to -1, so it's not a problem of isolation.
> > >
> > > During the n
On Thu, Nov 03, 2011 at 10:55:20AM -0400, Tom Lane wrote:
> > index on xobject_id might be corrupted, but it doesn't explain that I
> > don't see duplicates with group_by/having query on xobjects, which uses
> > seqscan:
> I was just going to ask you to check that. Weird as can be.
> Does plain ol
hubert depesz lubaczewski writes:
> index on xobject_id might be corrupted, but it doesn't explain that I
> don't see duplicates with group_by/having query on xobjects, which uses
> seqscan:
I was just going to ask you to check that. Weird as can be.
Does plain old "SELECT COUNT(*)" show a diff
On Thu, Nov 03, 2011 at 03:19:36PM +0100, Alban Hertroys wrote:
> On 3 November 2011 15:15, hubert depesz lubaczewski wrote:
> >> Do the xobject_id values have other negative numbers or is -1 just a
> >> special
> >> case? The only thing I can think of is a corrupted index on xobject_id.
> >
> >
On 3 November 2011 15:15, hubert depesz lubaczewski wrote:
>> Do the xobject_id values have other negative numbers or is -1 just a special
>> case? The only thing I can think of is a corrupted index on xobject_id.
>
> minimal xobject_id in source table is 1000.
>
> index on xobject_id might be cor
On Thu, Nov 03, 2011 at 07:00:30AM -0700, Adrian Klaver wrote:
> > I also verified that there are no concurrent updates that would set
> > xobject_id to -1, so it's not a problem of isolation.
> >
> > During the night I repeated the procedure and the rows that got duplicated
> > seem to be the sam
On Thursday, November 03, 2011 1:25:58 am hubert depesz lubaczewski wrote:
> Hi
> We have pretty weird situation, which seems to be impossible, but perhaps
> you'll notice something that will let me fix the problem.
>
> System: SunOS 5.11 snv_130
> Pg: PostgreSQL 8.4.7 on i386-pc-solaris2.11,
40 matches
Mail list logo
