From: | Adrien NAYRAT <adrien(dot)nayrat(at)anayrat(dot)info> |
---|---|
To: | <pgsql-performance(at)lists(dot)postgresql(dot)org> |
Subject: | Re: ERROR: found xmin from before relfrozenxid |
Date: | 2019-01-25 08:18:55 |
Message-ID: | 18832d21-2d98-1041-6d55-47d8c04d0531@anayrat.info |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 1/24/19 3:14 PM, Mariel Cherkassky wrote:
> I'm checking the full version.
> As you said I saw that in 9.6.9 there was a fix for the next bug :
>
> Avoid spuriously marking pages as all-visible (Dan Wood, Pavan Deolasee,
> Álvaro Herrera)
>
> This could happen if some tuples were locked (but not deleted). While
> queries would still function correctly, vacuum would normally ignore
> such pages, with the long-term effect that the tuples were never frozen.
> In recent releases this would eventually result in errors such as "found
> multixact nnnnn from before relminmxid nnnnn".
>
> So basically, he just need to upgrade in order to fix it ? Or there is
> something else that need to be done?
>
>
Hello,
The fix prevent this error occur, but it doesn't fix tuples impacted by
this bug.
Did you try this : psql -o /dev/null -c "select * from table for update"
database
As suggested by Alexandre Arruda :
https://www.postgresql.org/message-id/CAGewt-ukbL6WL8cc-G%2BiN9AVvmMQkhA9i2TKP4-6wJr6YOQkzA%40mail.gmail.com
Regards,
From | Date | Subject | |
---|---|---|---|
Next Message | Mariel Cherkassky | 2019-01-25 17:20:30 | Re: ERROR: found xmin from before relfrozenxid |
Previous Message | Saurabh Nanda | 2019-01-25 07:17:31 | Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"? |