[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