On 05/11/2013 04:58 PM, Bruce Momjian wrote:
On Fri, May 10, 2013 at 08:03:38PM -0400, Bruce Momjian wrote:
OK, this verifies that the table had a lot of DDL churn. I have no idea
how to pursue this further because I am unsure how we are going to
replicate the operations performed on this
On Sun, May 12, 2013 at 10:43:41PM -0400, Evan D. Hoffman wrote:
Adding dropping a column resolved the problem. Currently vacuuming the new
cluster. Thanks for your help everybody!
Great! Someday we will figure out what caused it.
On Mon, May 13, 2013 at 09:36:51AM -0400, Steve Singer wrote:
On 05/11/2013 04:58 PM, Bruce Momjian wrote:
On Fri, May 10, 2013 at 08:03:38PM -0400, Bruce Momjian wrote:
OK, this verifies that the table had a lot of DDL churn. I have no idea
how to pursue this further because I am unsure how
Bruce Momjian br...@momjian.us writes:
On Fri, May 10, 2013 at 08:03:38PM -0400, Bruce Momjian wrote:
On Fri, May 10, 2013 at 12:36:21PM -0400, Evan D. Hoffman wrote:
pg.dropped.16 INTEGER /* dummy */,
pg.dropped.17 INTEGER /* dummy */,
Adding dropping a column resolved the problem. Currently vacuuming the
new cluster. Thanks for your help everybody!
On Sat, May 11, 2013 at 4:58 PM, Bruce Momjian br...@momjian.us wrote:
On Fri, May 10, 2013 at 08:03:38PM -0400, Bruce Momjian wrote:
On Fri, May 10, 2013 at 12:36:21PM
On Fri, May 10, 2013 at 08:03:38PM -0400, Bruce Momjian wrote:
On Fri, May 10, 2013 at 12:36:21PM -0400, Evan D. Hoffman wrote:
pg.dropped.16 INTEGER /* dummy */,
pg.dropped.17 INTEGER /* dummy */,
pg.dropped.18 INTEGER /* dummy
On Thu, May 9, 2013 at 06:19:31PM -0400, Bruce Momjian wrote:
pg_upgrade already deals with the new code deciding not to create a
toast table (by forcing it to do so anyway in binary upgrade mode).
Yes, a good point I had forgotten. postgres --binary-upgrade mode can
force the toast
On 2013-05-10 07:25:35 -0400, Bruce Momjian wrote:
On Thu, May 9, 2013 at 06:19:31PM -0400, Bruce Momjian wrote:
pg_upgrade already deals with the new code deciding not to create a
toast table (by forcing it to do so anyway in binary upgrade mode).
Yes, a good point I had forgotten.
If it's of any value, here's the create statements for the table from the
pg_upgrade logs:
--
-- Name: setupinfo; Type: TABLE; Schema: bpm; Owner: postgres; Tablespace:
--
-- For binary upgrade, must preserve pg_type oid
SELECT binary_upgrade.set_next_pg_type_oid('17306'::pg_catalog.oid);
--
On Fri, May 10, 2013 at 12:36:21PM -0400, Evan D. Hoffman wrote:
pg.dropped.16 INTEGER /* dummy */,
pg.dropped.17 INTEGER /* dummy */,
pg.dropped.18 INTEGER /* dummy */,
pg.dropped.19 INTEGER /* dummy */,
On Thu, May 9, 2013 at 10:20:12AM -0400, Evan D. Hoffman wrote:
From the 9.1 cluster (port 5432):
db=# SELECT relname, relfilenode, relkind from pg_class where oid = 2938685;
relname| relfilenode | relkind
---+-+-
On Thu, May 9, 2013 at 03:23:20PM -0400, Evan D. Hoffman wrote:
I just did the whole process over from the beginning. here's the full output:
Copying user relation files
/var/lib/pgsql/9.1/data/base/16406/3016054
Mismatch of relation OID in database db: old OID 2938685,
On Thu, May 9, 2013 at 03:52:42PM -0400, Evan D. Hoffman wrote:
That's correct. Here's what substitutionlist_pkey looks like in the new
cluster. From this, it looks like it's actually correct (the oid for
substitutionlist_pkey is correct) but pg_upgrade thinks it's wrong and dies.
I'll
On Thu, May 9, 2013 at 04:21:05PM -0400, Evan D. Hoffman wrote:
Looks like your guess was correct:
[ehoffman@dev-db2 ~]$ psql -Upostgres db -p 5433
psql (9.2.4)
Type help for help.
db=# SELECT oid, relname, reltoastrelid, reltoastidxid FROM pg_class
db-# WHERE
Bruce Momjian br...@momjian.us writes:
OK, that's progress. Having received the table schema privately via
email, I see several 'character varying(40)' fields in the schema. So
the question is how was this table able to get away without a TOAST
table in 9.1, while 9.2 created one for an
On Thu, May 9, 2013 at 05:11:43PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
OK, that's progress. Having received the table schema privately via
email, I see several 'character varying(40)' fields in the schema. So
the question is how was this table able to get away
I believe the history of this cluster is that it started on 9.0 and was
upgraded to 9.1 via pg_upgrade. The instance I'm working on was created as a
streaming replica, then I broke the replication to make it a standalone master
specifically for testing pg_upgrade to 9.2.
On May 9, 2013, at
On Thu, May 9, 2013 at 10:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In any case, it seems like pg_upgrade ought to have a strategy for
dealing with tables acquiring toast tables like this,
Acquiring toast tables seems pretty trivial to deal with. *Losing* a
toast table might be a bit more
Greg Stark escribió:
On Thu, May 9, 2013 at 10:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In any case, it seems like pg_upgrade ought to have a strategy for
dealing with tables acquiring toast tables like this,
Acquiring toast tables seems pretty trivial to deal with. *Losing* a
toast
On Thu, May 9, 2013 at 06:05:14PM -0400, Alvaro Herrera wrote:
Greg Stark escribió:
On Thu, May 9, 2013 at 10:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In any case, it seems like pg_upgrade ought to have a strategy for
dealing with tables acquiring toast tables like this,
Acquiring
On Thu, May 9, 2013 at 05:41:39PM -0400, Evan D. Hoffman wrote:
I believe the history of this cluster is that it started on 9.0 and
was upgraded to 9.1 via pg_upgrade. The instance I'm working on was
created as a streaming replica, then I broke the replication to make
it a standalone master
Hmm... the database itself predates me, so I can't say for sure what
encoding it was created with, but when I did a pg_dumpall -s it
showed every database in the cluster uses SET client_encoding =
'UTF8';
On Thu, May 9, 2013 at 7:25 PM, Bruce Momjian br...@momjian.us wrote:
On Thu, May 9, 2013
On Thu, May 9, 2013 at 09:22:55PM -0400, Evan D. Hoffman wrote:
Hmm... the database itself predates me, so I can't say for sure what
encoding it was created with, but when I did a pg_dumpall -s it
showed every database in the cluster uses SET client_encoding =
'UTF8';
OK, that's good to
On Wed, May 8, 2013 at 02:27:18PM -0400, Evan D. Hoffman wrote:
If you want to start the old cluster, you will need to remove
the .old suffix from /var/lib/pgsql/9.1/data/global/pg_control.old.
Because link mode was used, the old cluster cannot be safely
started once the new cluster has been
24 matches
Mail list logo
