Re: [HACKERS] Write Ahead Logging for Hash Indexes - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] Write Ahead Logging for Hash Indexes
Date
Msg-id 20170315131845.GP9812@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] Write Ahead Logging for Hash Indexes  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] Write Ahead Logging for Hash Indexes  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] Write Ahead Logging for Hash Indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Amit,

* Amit Kapila (amit.kapila16@gmail.com) wrote:
> On Wed, Mar 15, 2017 at 12:53 AM, Stephen Frost <sfrost@snowman.net> wrote:
> >  If that's the case then
> > this does seem to at least be less of an issue, though I hope we put in
> > appropriate comments about it.
>
> I think we have sufficient comments in code especially on top of
> function _hash_alloc_buckets().

I don't see any comments regarding how we have to be sure to handle
an out-of-space case properly in the middle of a file because we've made
it sparse.

I do see that mdwrite() should handle an out-of-disk-space case, though
that just makes me wonder what's different here compared to normal
relations that we don't have an issue with a sparse WAL'd hash index but
we can't handle it if a normal relation is sparse.

Additional comments here would be overkill if we think that the lower
layers are already all set up to handle such a case properly and we
don't have to do anything special, but I had understood that we didn't
generally think that sparse files would just work.  I'm certainly happy
to be wrong there because, if that's the case, it'd be a great way to
improve the problems we have returning large chunks of free space in the
middle of a relation to the OS, but if there is a real concern here then
we need to work out what it is and probably add comments or possibly add
code to address whatever it is.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Allow pg_dumpall to work without pg_authid