[Dachs-support] Key (table_name)=(xxx.epn_core) already, exists.

Sebastian Walter sebastian.walter at fu-berlin.de
Fri Sep 28 13:10:27 CEST 2018


Hi Markus,

Thank you very much for your help. The documentation reads very well!

Indeed, I had renamed my resource directory, and after the first failing 
import try, I had renamed it back to the old name.

Now, I did what you told me, dachs purge, dachs drop, and as I had a 
registered service, I did import the one from my last backup first. This 
way I, I hope, it should all be like it was before.

Then I did my table update with gavo imp q.rd (and kept the same name 
for now).

Everything seems to work fine, as far as I can tell.

Thanks! Best regards,
Sebastian

On 09/28/2018 08:41 AM, Markus Demleitner wrote:
> Hi Sebastian,
>
> On Thu, Sep 27, 2018 at 06:26:26PM +0200, Sebastian Walter wrote:
>> After a while, I try to update my service data table, but even if I just
>> leave everything as it was before, I get the error that my table already
>> exists. I do not remember that I had to delete my data table, but I did an
>> gavo update in the meantime.
>>
>> The exact error message from my "gavo imp q.rd" is:
>>
>> Exception payload: duplicate key value violates unique constraint
>> "tables_pkey" DETAIL:  Key (table_name)=(fub_wms.epn_core) already
>> exists.
> I had expected that to be in my list of common problems with DaCHS,
> but surprisingly, it wasnt.
>
> So, I've written up
>
> http://docs.g-vo.org/DaCHS/commonproblems.html#duplicate-key-value-violates-unique-constraint-tables-pkey
>
> which now reads:
>
>    This typically happens on ``dachs imp``.  The immediate reason is that
>    ``dachs imp`` tries to insert a metadata row for one of the tables it
>    just created into the ``dc.tablemeta`` system table, but a row for that
>    name is already present.  For instance, if you're importing into
>    ``arihip.main``, DaCHS would like to note that the new table's
>    definition can be found at ``arihip/q#main``. Now, if ``dc.tablemeta``
>    already says ``arihip.main`` was defined in ``quicktest/q#main``,
>    there's a problem that DaCHS can't resolve by itself.
>
>    90% of the time, the underlying reason is that you renamed an RD (or a
>    resource directory).  Since the identifier of an RD (the RD id) is just
>    is relative path of the RD to the inputs directory (minus the ``.rd``),
>    and the RD id is used in many places in DaCHS, you have to be careful
>    when you do that (essentially: ``dachs drop --all old/rd; mv old new;
>    dachs imp new/rd``).
>
>    If you're seeing the above message, it's already too late for that
>    careful way.  The simple way to repair things nevertheless is to look
>    for the table name (it should be given in the DETAILS of the error
>    message) and simply tell DaCHS to forget all about that table::
>
>      dachs purge arigfh.main
>
>    This might leave other traces of the renamed RD in the system, which
>    might lead to trouble later.  If you want to be a bit more throrough,
>    figure out the RD id of the vanished RD by running ``psql gavo`` and
>    asking something like::
>
>      select sourcerd from dc.tablemeta where tablename='arihip.main'
>
>    This will give you the RD id of the RD that magically vanished, and you
>    can then say::
>
>      dachs drop -f old/rdid
>
>    DaCHS will then hunt down all traces of the old RD and delete them.
>
>    Don't do this without an acute need; such radical measures will clean up
>    DaCHS' mind, but in a connected society, amnesia can be a strain on the
>    rest of the society.  In the VO case, ``dachs drop -f`` might, for
>    instance, cause stale registry records if you had registered services
>    inside of the RD you force-drop.
>
> I notice it's gotten a bit too long, but is that at least understandable?
>
> Suggestions for improvement always welcome...
>
>         -- Markus
> _______________________________________________
> Dachs-support mailing list
> Dachs-support at g-vo.org
> http://lists.g-vo.org/cgi-bin/mailman/listinfo/dachs-support




More information about the Dachs-support mailing list