On Wed, Apr 18, 2012 at 7:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> jon.plotky@gmail.com writes:
> > Issue: After adding one new column to each of two different tables, que=
rying
> > 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. =A0Could 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. =A0However, if that new connection is what's going to examine
> pg_attribute, maybe the issue is that it's looking before the ALTER has
> committed?
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).
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, tom lane
Thanks for the response and insight!