Re: [Gnumed-bugs] Fixup Server failed

[slappinjohn]

gnumed_v22=> SET default_transaction_read_only to off;
SET
gnumed_v22=> BEGIN;
BEGIN
gnumed_v22=> DROP INDEX gm.access_log_pkey CASCADE;
ERROR:  cannot drop index gm.access_log_pkey because constraint
access_log_pkey on table gm.access_log requires it
TIP:  You can drop constraint access_log_pkey on table gm.access_log
instead.
gnumed_v22=> SELECT * FROM gm.access_log WHERE pk = 67314;
ERROR:  current transaction is aborted, commands ignored until end of
transaction block
gnumed_v22=> ROLLBACK;
ROLLBACK

Am 03.09.19 um 22:12 schrieb Karsten Hilbert:
> The next step would be to try
>
> BEGIN;
> DROP INDEX gm.access_log_pkey CASCADE;
> SELECT * FROM gm.access_log WHERE pk = 67314;
> ROLLBACK;
>
> Karsten
>
>> Gesendet: Dienstag, 03. September 2019 um 22:05 Uhr
>> Von: "slappinjohn" <address@hidden>
>> An: "Karsten Hilbert" <address@hidden>
>> Cc: address@hidden
>> Betreff: Re: [Gnumed-bugs] Fixup Server failed
>>
>> gnumed_v22=> REINDEX VERBOSE TABLE gm.access_log;
>> ERROR:  syntax error at or near "VERBOSE"
>> ZEILE 1: REINDEX VERBOSE TABLE gm.access_log;
>>                  ^
>> gnumed_v22=> REINDEX  TABLE gm.access_log;
>> ERROR:  could not create unique index "access_log_pkey"
>> DETAIL:  Key (pk)=(67314) is duplicated.
>>
>> Am 03.09.19 um 21:53 schrieb Karsten Hilbert:
>>>> brings the same result - only one line. Shall I set the options back to
>>>> on afterwards?
>>> Should not make a difference as it is not persistent
>>> beyond the connection.
>>>
>>> Just for kicks, can you try a manual REINDX ?
>>>
>>>    REINDEX VERBOSE TABLE gm.access_log;
>>>
>>> (as gm-dbo)
>>>
>>> That should fail the same way as fixup did.
>>>
>>> Karsten
>>>
>>>
>>>> Am 02.09.19 um 22:55 schrieb Karsten Hilbert:
>>>>> On Mon, Sep 02, 2019 at 10:30:59PM +0200, slappinjohn wrote:
>>>>>
>>>>>>  pk_audit | row_version |         modified_when         | modified_by | 
>>>>>> pk   |                  user_action                 
>>>>>> ----------+-------------+-------------------------------+-------------+-------+-----------------------------------------------
>>>>>>    593079 |           0 | 2019-07-23 06:26:59.141724+00 | maan        |
>>>>>> 67314 | EMR access: pulling chart for identity [9672]
>>>>>> (1 Zeile)
>>>>> I had outsmarted myself: the old index still exists, and
>>>>> points to one of the rows (this one) with the pk of 67314.
>>>>>
>>>>> However, we need both, so we need to switch off the index for
>>>>> that query.
>>>>>
>>>>>
>>>>>   set enable_indexonlyscan to off;
>>>>>   set enable_indexscan to off;
>>>>>   SELECT * FROM gm.access_log WHERE pk = 67314;
>>>>>
>>>>> This should return both rows.
>>>>>
>>>>> Karsten
>>>>> --
>>>>> GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
>>>>>