On Wed, Apr 18, 2012 at 7:44 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> jon(dot)plotky(at)gmail(dot)com writes:
> > Issue: After adding one new column to each of two different tables, querying
> > pg_attribute shows the new column in one table but not the other.
> This is a bit hard to believe, and your log extract certainly doesn't
> provide any evidence to support the statement. Could we see a complete
> self-contained test case?
> > - Postgresql log shows difference after the two ALTER TABLE statements (see
> > below), with a "forked new backend" message always following the ALTER TABLE
> > that does not update pg_attribute. Don't know if this has anything to do
> > with anything, but the log messages are always the same
> That only suggests a new incoming connection, which seems probably
> unrelated. However, if that new connection is what's going to examine
> pg_attribute, maybe the issue is that it's looking before the ALTER has
This is what's happening. The stack is Rails, ActiveRecord,
connection pooler pgbouncer, and Postgresql. The ActiveRecord class
that doesn't see the column update uses a specific connection pool.
Unfortunately ActiveRecord uses the default pool connection to alter
the table associated with that class, then tries to update the class
attributes by querying pg_attribute using the class specific
connection pool (generating the new connection in the log).
> regards, tom lane
Thanks for the response and insight!
In response to
pgsql-bugs by date
|Next:||From: Amit Kapila||Date: 2012-04-19 02:38:50|
|Subject: FW: clarification for generate join implied equalities|
|Previous:||From: Tom Lane||Date: 2012-04-18 23:44:55|
|Subject: Re: BUG #6601: Inconsistent behavior of ALTER TABLE ADD COLUMN |