Isn’t this a perfect opportunity to use the TRUNCATE command to quickly remove the data? And follow up by deleting the now empty tables?Regards,GusSent from my iPhoneOn Jul 19, 2023, at 7:33 PM, Rob Sargent wrote:
On 7/19/23 17:15, David Rowley wrote:
On Wed, 19
On 7/22/23 10:11, De Lan wrote:
Hi pgsql community,
Recently we found in a postgresql 11.19.0 alpine table there are two
rows with duplicate primary keys.
*Our questions:*
Any ideas on what might cause this behavior other than the collation? if
it is a well-known issue in the pgsql comm
>
> *Our questions:*
>
> Any ideas on what might cause this behavior other than the collation? if it
> is a well-known issue in the pgsql community or it really is the
> coalition that's the root cause, do we have mitigation for this kind of
> issue from happening in future?
>
>
>
> De,
>
> T
Hi pgsql community,
Recently we found in a postgresql 11.19.0 alpine table there are two rows
with duplicate primary keys.
*The table schema (anonymized):*
# \d+ app_specs;
Table "public.app_specs"
Column | Type | Collation | Nullable
>
> > I'm not sure what applied="public.pg", error="setting could not be
> applied"
> > means.
>
> No, "applied" is "f" (false), meaning that the setting is not actually
> usable.
> I'm a little surprised that it seems to have gotten into your live session
> anyway, although perhaps that's because
