Hi,
Some time ago, I had this errors frequently showed in logs after some
autovacuum in some tables(pg 9.6). VACUUM FULL or CLUSTER in this tables
show the same and not complete the tasks (showed by some table bloat
select).
Then, I did a full dump/restore into a new version (10.2) and everything
2018-04-06 9:39 GMT-03:00 Tomas Vondra :
>
>
> On 04/06/2018 02:09 AM, Alexandre Arruda wrote:
> > Hi,
> >
> > Some time ago, I had this errors frequently showed in logs after some
> > autovacuum in some tables(pg 9.6). VACUUM FULL or CLUSTER in this tables
>
2018-04-06 13:11 GMT-03:00 Tomas Vondra :
>
>
> On 04/06/2018 04:29 PM, Alexandre Arruda wrote:
> > 2018-04-06 9:39 GMT-03:00 Tomas Vondra > <mailto:tomas.von...@2ndquadrant.com>>:
> >
> >
> >
> > On 04/06/2018 02:09 AM, Alexandre Arruda wro
2018-04-09 18:23 GMT-03:00 Peter Geoghegan :
>
> On Mon, Apr 9, 2018 at 7:01 AM, Tomas Vondra
> wrote:
> > The bigger question is whether this can actually detect the issue. If
> > it's due to an storage issue, then perhaps yes. But if you only see
> > multixact issues consistently and nothing els
2018-04-09 22:16 GMT-03:00 Peter Geoghegan :
> On Mon, Apr 9, 2018 at 5:55 PM, Alexandre Arruda wrote:
>> I ran amcheck in all index of a table and I only get empty returns.
>
> Did you try doing so with the "heapallindexed" option? That's what's
> r
2018-04-09 23:51 GMT-03:00 Peter Geoghegan :
> On Mon, Apr 9, 2018 at 6:56 PM, Alexandre Arruda wrote:
>> (... and all other indexes returns null too)
>>
>> I tried with bt_index_check too. Same results.
>
> That's interesting, because it tells me that you have
2018-04-10 19:53 GMT-03:00 Andres Freund :
> On 2018-04-10 08:31:20 -0300, Alexandre Arruda wrote:
>> 2018-04-09 23:51 GMT-03:00 Peter Geoghegan :
>> > On Mon, Apr 9, 2018 at 6:56 PM, Alexandre Arruda
>> > wrote:
>> >> (... and all other indexes ret
2018-04-10 19:09 GMT-03:00 Peter Geoghegan :
> On Tue, Apr 10, 2018 at 4:31 AM, Alexandre Arruda wrote:
>> Actualy, I first notice the problem in logs by autovacuum:
>>
>> 2018-04-10 08:22:15.385 -03 [55477] CONTEXT: automatic vacuum of
>> table "production.p
2018-04-10 19:53 GMT-03:00 Andres Freund :
> On 2018-04-10 08:31:20 -0300, Alexandre Arruda wrote:
>> 2018-04-09 23:51 GMT-03:00 Peter Geoghegan :
>> > On Mon, Apr 9, 2018 at 6:56 PM, Alexandre Arruda
>> > wrote:
>> >> (... and all other indexes ret
Em seg, 28 de mai de 2018 às 16:44, Andres Freund escreveu:
>
> Hi,
>
> I think I found the bug, and am about to post a fix for it belo
> https://postgr.es/m/20180525203736.crkbg36muzxrj...@alap3.anarazel.de.
>
> Greetings,
>
> Andres Freund
Hi Andres,
In end of April we did a complete dump/relo
Em seg., 7 de dez. de 2020 às 12:53, Chris Stephens
escreveu:
> Hello,
>
> We have a need to display some very simple reports generated from views in
> an rds postgres database. We need little more functionality beyond simple
> filtering, column hiding, sorting, grouping. Anything much beyond tha
The best solution that I have found is kick all connections and execute a
select for update to /dev/null in the affected tables, i.e.:
psql -o /dev/null -c "select * from table for update" database
After this, the vacuum is executed w/o problems again.
Best regards,
Alexandre
Em qua, 7 de nov
Sorry to revive this post, but I have the same problem:
I set a streaming replication slave with this steps:
1) create a physical replication slot in master
2) pg_basebackup -S slot (...)
3) create a recovery.conf with primary_conninfo, primary_slot_name and
recovery_min_apply_delay = '4d'
4) star
13 matches
Mail list logo
