[Dachs-support] [itteam] gavo import lock
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Mon Nov 7 16:00:50 CET 2016
On Mon, Nov 07, 2016 at 12:38:16PM -0200, carlosadean at linea.gov.br wrote:
> Hi Markus,
> > output here? Clearly, this shouldn't happen; technically, DaCHS does
> > the upgrade to each schema version in a transaction of its own, so if
> > it has created the column_index, the DB should be at (at least)
> > schema
> > version 14, and it shouldn't try to re-create it.
> >
> > I'd be curious how the addition of the table column escaped the
> > transaction (if that's what's happening), and perhaps gavo
>
>
> [gavo at devel2 ~]$ gavo --version
> Software (0.9.7) Schema (14/13)
Ok, so it's fine that the machine tries to add the column_index. I
don't understand why it's already there, though. Postgres Manual
13.5 says "the table-rewriting forms of ALTER TABLE, are not
MVCC-safe" but then goes on to say that concurrent transactions would
only see an empty table, not that a rollback wouldn't take effect.
And a quick:
gavo=# begin;
BEGIN
gavo=# alter table tap_schema.columns add column junk smallint;
ALTER TABLE
gavo=# rollback;
ROLLBACK
confirms that the column shouldn't be there. I'll take this as a
data point and try to trigger an analogous problem next time gavo
upgrade needs a schema change.
Meanwhile: if you run
alter table tap_schema.columns drop column column_index
in psql gavo, the upgrade should run (when the faulty RDs are gone,
that is).
-- Markus
More information about the Dachs-support
mailing list