| 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: | Whole Thread | Raw Message | 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 |