From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: Deprecating Hash Indexes |
Date: | 2012-10-15 17:11:43 |
Message-ID: | 201210151911.43509.andres@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Monday, October 15, 2012 07:03:35 PM Simon Riggs wrote:
> On 15 October 2012 15:19, Andres Freund said...
>
> > I vote for at least logging a wal record when a hash index is modified
> > which uses incomplete actions to set 'indisready = false' in case its
> > replayed. That should only use a rather minor amount of code and should
> > help users to find problems faster.
>
> Good idea, though might be harder than it first appears.
> How do we issue just one of those per checkpoint, to minimise WAL?
I was thinking per checkpoint, per backend in order to not add any new locks.
> How do we make that change with a physical update WAL? Non-transactional
> update? During recovery?
Thats why I suggested using the incomplete actions/cleanup stuff, so we can do
the change when replay finished. Thats not enough for HS though... Can we get
away with putting a if (RecoveryInProgress()) ereport(...) in there?
Greetings,
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2012-10-15 17:18:55 | Re: WebSphere Application Server support for postgres |
Previous Message | Daniel Farina | 2012-10-15 17:10:53 | Re: Hash id in pg_stat_statements |