Re: Error with index on unlogged table

On Sat, Nov 21, 2015 at 11:30 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Fri, Nov 20, 2015 at 4:11 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> For master and perhaps 9.5, I would think that a dedicated WAL record
>> type enforcing the fsync is the way to go. This special treatment
>> would go only for btree and spgist when they use INIT_FORKNUM and we
>> would not impact other relation types and code paths with this
>> behavior.
>
> So, I have been looking at that, and finished with the attached to
> implement this idea. This way, it is possible to control at replay if
> a relation should be synced to disk just after replaying a FPI or a
> set of FPIs. This makes btree and spgist init forks more consistent at
> replay with what is done on master by syncing them immediately, which
> is not a bad thing to me.

Depending on the type of index used on an unlogged table, the failure
happening is quite various. With gist and btree, a promoted standby
will complain about an empty page. With brin, the standby will
complain with a floating-point error:
ERROR: 22P01: floating-point exception
DETAIL: An invalid floating-point operation was signaled. This
probably means an out-of-range result or an invalid operation, such as
division by zero.
LOCATION: FloatExceptionHandler, postgres.c:2702

Now with gin, the system becomes actually unresponsive, being stuck on
PGSemaphoreLock and unable to answer to signals:
frame #1: 0x000000010a29f7cf
postgres`PGSemaphoreLock(sema=0x00000001138df118) + 63 at
pg_sema.c:387
frame #2: 0x000000010a348e81
postgres`LWLockAcquire(lock=0x000000010acc5dc0, mode=LW_EXCLUSIVE) +
369 at lwlock.c:1026
frame #3: 0x000000010a3190b1 postgres`LockBuffer(buffer=208,
mode=2) + 289 at bufmgr.c:3240
frame #4: 0x0000000109f341e1
postgres`ginHeapTupleFastInsert(ginstate=0x00007fff55d06a08,
collector=0x00007fff55d069d8) + 849 at ginfast.c:309
frame #5: 0x0000000109f1383f
postgres`gininsert(fcinfo=0x00007fff55d09010) + 431 at gininsert.c:531

I am still investigating for a correct fix, looking at reinit.c the
code in charge of copying the init fork as the main fork for a
relation at the end of recovery looks to be doing its job correctly...
Regards,
--
Michael