From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "luis garcia" <ldgarc(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: ¿¿¿past chunk end??? |
Date: | 2006-11-02 06:19:28 |
Message-ID: | 10773.1162448368@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"luis garcia" <ldgarc(at)gmail(dot)com> writes:
> Well about the changes I have made, they are working just fine. All the
> structures length have been updated and as I said we added 7 new fields
> to pg_class structure and there was no problem. The problem here is with
> relfrequency only.
pg_class is notoriously tricky to add fields to --- there are more
undocumented dependencies than you might think. If you check the
archives, there was a thread only a week or so back with someone who
was one or two edits short of getting such a change to work.
But what I'm wondering in your case is whether your code thinks it can
set relfrequency and/or the preceding field relfrequencytype to null.
You can't use a C struct to address any fields beyond the first
possibly-nullable field, because the constant offsets computed by the
compiler won't work. Also, initdb makes some assumptions derived from
this fact to decide which system-catalog columns to mark NOT NULL.
If "\d pg_class" shows not-null column markings that are at variance
with what you intend, you have a problem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2006-11-02 08:45:39 | Re: Writing WAL for relcache invalidation:pg_internal.init |
Previous Message | Oleg Bartunov | 2006-11-01 23:22:01 | Re: [HACKERS] Index greater than 8k |