On Mon, Jul 29, 2019 at 12:18:33PM +0200, Tomas Vondra wrote:
On Sun, Jul 28, 2019 at 09:53:20PM -0700, Andres Freund wrote:
Hi,
On 2019-07-28 21:21:51 +0200, Tomas Vondra wrote:
AFAICS it applies to 10+ versions, because that's where extended stats
were introduced. We certainly can't mess
On Sun, Jul 28, 2019 at 09:53:20PM -0700, Andres Freund wrote:
Hi,
On 2019-07-28 21:21:51 +0200, Tomas Vondra wrote:
AFAICS it applies to 10+ versions, because that's where extended stats
were introduced. We certainly can't mess with catalogs there, so this is
about the only backpatchable fix
On Mon, Jul 29, 2019 at 10:15:36AM +0100, Dean Rasheed wrote:
On Sun, 28 Jul 2019 at 11:15, Tomas Vondra wrote:
Attached is a patch fixing the error by not building extended stats for
the inh=true case (as already proposed in this thread). That's about the
simplest way to resolve this issue
On Sun, 28 Jul 2019 at 11:15, Tomas Vondra wrote:
>
> Attached is a patch fixing the error by not building extended stats for
> the inh=true case (as already proposed in this thread). That's about the
> simplest way to resolve this issue for v12. It should add a simple
> regression test too, I
Hi,
On 2019-07-28 21:21:51 +0200, Tomas Vondra wrote:
> AFAICS it applies to 10+ versions, because that's where extended stats
> were introduced. We certainly can't mess with catalogs there, so this is
> about the only backpatchable fix I can think of.
AFAIU the inh version wouldn't be used
On Sun, Jul 28, 2019 at 09:42:44AM -0700, Andres Freund wrote:
Hi,
On 2019-07-28 12:15:20 +0200, Tomas Vondra wrote:
Attached is a patch fixing the error by not building extended stats for
the inh=true case (as already proposed in this thread). That's about the
simplest way to resolve this
Hi,
On 2019-07-28 12:15:20 +0200, Tomas Vondra wrote:
> Attached is a patch fixing the error by not building extended stats for
> the inh=true case (as already proposed in this thread). That's about the
> simplest way to resolve this issue for v12. It should add a simple
> regression test too, I
On Tue, Jul 23, 2019 at 01:01:27PM -0700, Andres Freund wrote:
Hi,
On 2019-06-18 17:08:37 -0700, Andres Freund wrote:
On 2019-06-18 18:48:58 -0500, Justin Pryzby wrote:
> Ah: the table is an inheritence parent. If I uninherit its child, there's no
> error during ANALYZE. MV stats on the
Hi,
On 2019-06-18 17:08:37 -0700, Andres Freund wrote:
> On 2019-06-18 18:48:58 -0500, Justin Pryzby wrote:
> > Ah: the table is an inheritence parent. If I uninherit its child, there's
> > no
> > error during ANALYZE. MV stats on the child are ok:
>
> It's a "classical" inheritance parent,
y self
>> > LOCATION: simple_heap_update, heapam.c:4613
>>
>> > I'm guessing the issue is with pg_statistic_ext, which I haven't
>touched.
>> >
>> > Next step seems to be to truncate pg_statistic{,ext} and re-analyze
>the DB.
>>
>> Confi
essing the issue is with pg_statistic_ext, which I haven't touched.
> >
> > Next step seems to be to truncate pg_statistic{,ext} and re-analyze the DB.
>
> Confirmed the issue is there.
>
> ts=# analyze sectors;
> ERROR: tuple already updated by self
> ts=# begin; delete f
On Tue, Jun 18, 2019 at 5:09 PM Andres Freund wrote:
> > It might be interesting to set a breakpoint within heap_update(),
> > which is called by simple_heap_update() --technically, this is where
> > the reported failure occurs. From there, you could send an image of
> > the page to the list by
Andres Freund writes:
> I think the problem is pretty plainly that for inheritance tables we'll
> try to store extended statistics twice. And thus end up updating the
> same row twice.
They shouldn't be the same row though. If we're to try to capture
ext-stats on inheritance trees --- and I
Hi,
On 2019-06-18 17:00:09 -0700, Peter Geoghegan wrote:
> On Tue, Jun 18, 2019 at 4:49 PM Justin Pryzby wrote:
> > Sure:
> >
> > (gdb) bt
> > #0 errfinish (dummy=0) at elog.c:414
> > #1 0x0085e834 in elog_finish (elevel=,
> > fmt=) at elog.c:1376
> > #2 0x004b93bd in
Hi,
On 2019-06-18 18:48:58 -0500, Justin Pryzby wrote:
> Ah: the table is an inheritence parent. If I uninherit its child, there's no
> error during ANALYZE. MV stats on the child are ok:
It's a "classical" inheritance parent, not a builtin-partitioning type
of parent, right? And it contains
On Tue, Jun 18, 2019 at 4:49 PM Justin Pryzby wrote:
> Sure:
>
> (gdb) bt
> #0 errfinish (dummy=0) at elog.c:414
> #1 0x0085e834 in elog_finish (elevel=,
> fmt=) at elog.c:1376
> #2 0x004b93bd in simple_heap_update (relation=0x7fee161700c8,
> otid=0x1fb7f44, tup=0x1fb7f40) at
On Tue, Jun 18, 2019 at 06:48:58PM -0500, Justin Pryzby wrote:
> On Tue, Jun 18, 2019 at 06:12:33PM -0500, Justin Pryzby wrote:
> > ts=# ANALYZE sectors;
> > ERROR: XX000: tuple already updated by self
> > LOCATION: simple_heap_update, heapam.c:4613
> Ah: the table is an inheritence parent. If
t} and re-analyze the DB.
Confirmed the issue is there.
ts=# analyze sectors;
ERROR: tuple already updated by self
ts=# begin; delete from pg_statistic_ext; analyze sectors;
BEGIN
DELETE 87
ANALYZE
On Tue, Jun 18, 2019 at 04:30:33PM -0700, Andres Freund wrote:
> Any chance to get a backtrace for th
Hi,
On 2019-06-18 18:12:33 -0500, Justin Pryzby wrote:
> A customers DB crashed due to OOM. While investigating the issue in our
> report, I created MV stats, which causes this error:
>
> ts=# CREATE STATISTICS sectors_stats (dependencies) ON site_id,sect_id FROM
> sectors;
> CREATE STATISTICS
A customers DB crashed due to OOM. While investigating the issue in our
report, I created MV stats, which causes this error:
ts=# CREATE STATISTICS sectors_stats (dependencies) ON site_id,sect_id FROM
sectors;
CREATE STATISTICS
ts=# ANALYZE sectors;
ERROR: XX000: tuple already updated by self
20 matches
Mail list logo
