the
index so Postgres can at least warn you? Or not use the messed up
index altogether instead of silently returning no data?
On Sun, Jun 6, 2021 at 2:06 PM Omar Kilani wrote:
>
> We do use ON CONFLICT… it doesn’t work because the index is both “good” and
> “bad” at the same time.
>
> On
We do use ON CONFLICT… it doesn’t work because the index is both “good” and
“bad” at the same time.
On Sun, Jun 6, 2021 at 2:03 PM Justin Pryzby wrote:
> On Sun, Jun 06, 2021 at 03:54:48AM -0700, Omar Kilani wrote:
> > What I sort of don't get is... before we insert anyth
Hey Chap,
Yeah, I understand. Just ruling out the bad hardware scenario.
Plus the next person to Google this will hopefully stumble upon this
thread. :)
Regards,
Omar
On Sun, Jun 6, 2021 at 9:36 AM Chapman Flack wrote:
> On 06/06/21 11:08, Omar Kilani wrote:
> > I&
n: 1
Files scanned: 7068
Blocks scanned: 524565247
Bad checksums: 0
Regards,
Omar
On Sun, Jun 6, 2021 at 9:15 AM Magnus Hagander wrote:
>
> On Sun, Jun 6, 2021 at 5:19 PM Omar Kilani wrote:
> >
> > Hey Tom,
> >
> > The database was pg_dump'ed out of 10.4 and pg_
guess I can try some older versions of 11.x on this cluster for
completeness' sake.
Regards,
Omar
On Sun, Jun 6, 2021 at 8:18 AM Omar Kilani wrote:
>
> Hey Tom,
>
> The database was pg_dump'ed out of 10.4 and pg_restore'd into 11.2 on
> a RHEL 7.x machine.
>
>
e index
has somehow got itself into this state, and I'm fairly sure it's not
the hardware.
Thanks again.
Regards,
Omar
On Sun, Jun 6, 2021 at 8:08 AM Tom Lane wrote:
>
> Omar Kilani writes:
> > This is a very old database (2004) that has moved forward via pg_upgrade. I
&g
I missed one of your questions before -- no, it wasn't created with
CREATE INDEX CONCURRENTLY. That index was created by 11.2's pg_restore
roughly 2 years ago.
On Sun, Jun 6, 2021 at 6:53 AM Omar Kilani wrote:
>
> I just remembered, I have… many… snapshots of the on disk data
servers and they all had the
same issue. Presumably the index would be “corrupt” in the same way across
multiple very different machines from WAL apply?
On Sun, Jun 6, 2021 at 6:41 AM Omar Kilani wrote:
> Hey David,
>
> Hmmm… it wasn’t init on 11.x.
>
> This is a very old database
table just before the REINDEX.
I’m 99.9% confident the hardware isn’t bad.
The only time we’ve seen this is with Unicode input.
Regards,
Omar
On Sun, Jun 6, 2021 at 4:59 AM David Rowley wrote:
> On Sun, 6 Jun 2021 at 22:55, Omar Kilani wrote:
> > There seems to be a weird bug in
Hi,
There seems to be a weird bug in Postgres (last tested 11.12) where it
allows an INSERT into a table with a UNIQUE / UNIQUE CONSTRAINT index
on a TEXT/VARCHAR when there's already a value present in that index,
but only for UTF-8 input.
I just had this happen on our user table and it somehow
Hi,
I happened to be running some postgres on zfs on Linux/aarch64 tests
and tested this patch.
Kernel: 4.18.0-305.el8.aarch64
CPU: 16x3.0GHz Ampere Alta / Arm Neoverse N1 cores
ZFS: 2.1.0-rc6
ZFS options: options spl spl_kmem_cache_slab_limit=65536 (see:
https://github.com/openzfs/zfs/issues/12
11 matches
Mail list logo
