Re: time sorted UUIDs

Tomas Vondra made an extension to have sequential uuid: https://www.2ndquadrant.com/en/blog/sequential-uuid-generators/ https://github.com/tvondra/sequential-uuids -- Adrien NAYRAT

Re: impact of auto explain on overall performance

On 3/14/19 9:23 AM, Justin Pryzby wrote: On Thu, Mar 14, 2019 at 07:29:17AM +, Stephan Schmidt wrote: i’m currently working on a high Performance Database and want to make sure that whenever there are slow queries during regular operations i’ve got all Information about the query in my log

Re: ERROR: found xmin from before relfrozenxid

On 3/13/19 1:59 PM, Mariel Cherkassky wrote: Hey, The query was the first thing that I tried, it didnt solve the issue. Guess I'll update to the latest version. I read releases notes and I don't find any item that could be related to the error you encounter. It could be either another bug in p

Re: ERROR: found xmin from before relfrozenxid

On 3/12/19 8:58 AM, Mariel Cherkassky wrote: Apparently the issue appeared again in the same database but on different table . In the last time dumping and restoring the table helped. However, I dont understand why another table hit the bug if it was fixed in 9.6.9 while my db version is 9.6.10

Re: ERROR: found xmin from before relfrozenxid

On 1/26/19 11:56 AM, Mariel Cherkassky wrote: Update to the minor version should be an easy solution - yum update postgresql . What did you mean by carful Sorry, I meant, do not forget to apply update to be sure same bug do not happen again.

Re: ERROR: found xmin from before relfrozenxid

On 1/25/19 6:20 PM, Mariel Cherkassky wrote: I'm getting this issue when I try to connect to a specific db. Does it matters what table I specify ? Should I just choose a random table from the problematic db? If I'll dump the db and restore it it can help ? Error message is on "db1.public.table

Re: ERROR: found xmin from before relfrozenxid

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

Re: performance statistics monitoring without spamming logs

On 07/10/2018 08:38 PM, Justin Pryzby wrote: On Tue, Jul 10, 2018 at 01:54:12PM -0400, Patrick Hemmer wrote: I'm looking for a way of gathering performance stats in a more usable way than turning on `log_statement_stats` (or other related modules). The problem I have with the log_*_stats family

Re: performance statistics monitoring without spamming logs

On 07/13/2018 12:25 AM, Lukas Fittl wrote: On Tue, Jul 10, 2018 at 11:38 AM, Justin Pryzby > wrote: > 2. Make stats available in `pg_stat_statements` (or alternate view that > could be joined on). The block stats are already available here, but > others l