Re: truncating pg_multixact/members

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: truncating pg_multixact/members
Date: 2013-12-28 21:47:40
Message-ID: 1388267260.20441.YahooMailNeo@web122302.mail.ne1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:

> 1. slru.c doesn't consider file names longer than 4 hexadecimal chars.

> Fixing (1) is simple: we can have each SLRU user declare how many digits
> to have in file names.  All existing users but pg_multixact/members
> should declare 4 digits; that one should declare 5.  That way, the
> correct number of zeroes are allocated at the start point and we get
> nice, equal-width file names.  Eventually, predicate.c can change to
> wider file names and get rid of some strange code it has to deal with
> overrun.

That would be nice.

There would be the issue of how to deal with pg_upgrade, though. If
I remember correctly, there is no strong reason not to blow away
any existing files in the pg_serial subdirectory at startup (the
way NOTIFY code does), and at one point I had code to do that.  I
think we took that code out because the files would be deleted
"soon enough" anyway.  Barring objection, deleting them at startup
seems like a sane way to handle pg_upgrade issues when we do
increase the filename size.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-12-28 22:16:01 Re: planner missing a trick for foreign tables w/OR conditions
Previous Message David Rowley 2013-12-28 20:36:20 Re: [PATCH] Regression tests in windows ignore white space