Re: Corrupted Store?

--000000000000e5989a0642851b77
Content-Type: text/plain; charset="UTF-8"

Hi Andre,

I can't give you any advice, but report that we are using VW with a
PostgreSQL database (version 9.2), and never seen any corruption issue in
the past 19 years. Our DB was sometimes missing indexes that had been added
to the Store schema by newer VW versions, but that did not seem to cause
any issues.
We have a mechanism to add signatures to published packages, to detect
missing code when loading them, and that also did not report any unexpected
damage for quite a while now. Moving stuff from one package to another
would sometimes cause missing in the VW 7 era, but not anymore.

Holger


Am Fr., 31. Okt. 2025 um 19:35 Uhr schrieb andre <[email protected]
>:

> For the first time in decades I encountered a strange issue with Store in
> a PostgreSQL database. Some packages did not find published versions in the
> Store (when they were definitely published).
>
> It turned out the database needed a re-index, which fixed the issue.
>
> Is this a cause for concern? I've never seen a need for re-indexing. If
> anything that should be a performance consideration only.
>
> Should I be worried about a corrupted Store now? I've published updated
> bundles and packages while some indexes may have been compromised. I guess
> any publication would have failed if a bundle/package was affected by the
> broken index, or would it?
>
> Is there a safe way to check Store integrity?
>
> Best,
> Andre

--000000000000e5989a0642851b77
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Andre,</div><div><br></div><div>I can&#39;t give y=
ou any advice, but report that we are using VW with a PostgreSQL database (=
version 9.2), and never seen any corruption issue in the past 19 years. Our=
 DB was sometimes missing indexes that had been added to the Store schema b=
y newer VW versions, but that did not seem to cause any issues.</div><div>W=
e have a mechanism to add signatures to published packages, to detect missi=
ng code when loading them, and that also did not report any unexpected dama=
ge for quite a while now. Moving stuff from one package to another would so=
metimes cause missing in the VW 7 era, but not anymore.</div><div><br></div=
><div>Holger</div><div><br></div></div><br><div class=3D"gmail_quote gmail_=
quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Am Fr., 31. Okt. 202=
5 um 19:35=C2=A0Uhr schrieb andre &lt;<a href=3D"mailto:on.the.timeline@gma=
il.com">[email protected]</a>&gt;:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">For the first time in decades I encountered a st=
range issue with Store in a PostgreSQL database. Some packages did not find=
 published versions in the Store (when they were definitely published).<br>
<br>
It turned out the database needed a re-index, which fixed the issue.<br>
<br>
Is this a cause for concern? I&#39;ve never seen a need for re-indexing. If=
 anything that should be a performance consideration only.<br>
<br>
Should I be worried about a corrupted Store now? I&#39;ve published updated=
 bundles and packages while some indexes may have been compromised. I guess=
 any publication would have failed if a bundle/package was affected by the =
broken index, or would it?<br>
<br>
Is there a safe way to check Store integrity?<br>
<br>
Best,<br>
Andre</blockquote></div>

--000000000000e5989a0642851b77--