Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > cur_datname here seems corrupted -- it points halfway into cur_nspname, > which is also a corrupt value.
Yeah. > And I think that's because we're not > checking that the namespace OID is a valid value before calling > get_namespace_name on it. No, because get_namespace_name should return NULL if it doesn't find any pg_namespace entry. That would work just as well for InvalidOid as for any other nonexistent schema OID. The part of your patch that adds a check on avw_database is clearly correct and necessary. I'm thinking the change you propose in perform_work_item is just overcomplicating code that's okay as it stands. We don't need to optimize for the schema-went-away case. What I'm suspicious of as the actual bug cause is the comment in perform_work_item about how we need to be sure that we're allocating these strings in a long-lived context. If, in fact, they were allocated in some context that could get reset during the PG_TRY (particularly in the error-cleanup path, which I bet we don't test), then the observed symptom that the pointers seem to be pointing at garbage could be explained. So what I'm thinking is that you need an error during perform_work_item, and/or more than one work_item picked up in the calling loop, to make this bug manifest. You would need to enter perform_work_item in a non-long-lived context, so the first time through the loop is probably safe anyway. BTW, it seems like the "Perform operations on collected tables." loop in do_autovacuum has probably got similar latent bugs. We take care to enter it in AutovacMemCxt initially, but it looks to me like subsequent iterations probably start out in some transaction context, because the PG_TRY around autovacuum_do_vac_analyze doesn't do anything about switching back to AutovacMemCxt. There needs to be a bit more clarity throughout this code about what CurrentMemoryContext ought to be at each point. Appropriate fixes might involve switching back to AutovacMemCxt after each of those PG_TRY blocks. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers