Re: BUG #4565: nextval not updated during wal replication, leading to pk violations

Tom Lane wrote:
> Marc Schablewski <ms(at)clickware(dot)de> writes:
>
>> cache_value is set to one for all sequences. As far as I can tell, they
>> were all created by a plain CREATE SEQUENCE seq_name and no other
>> settings changed. And as we found out later this "loss of information"
>> hit some indexes as well.
>>
>
>
>> We took a fresh backup yesterday and again we saw that only the last WAL
>> generated during the backup run was restored on our backup system. I'm
>> sure that this is the real problem.
>>
>
> This is beginning to sound like an error in your backup/restore
> procedures. Please describe exactly what you're doing.
>
> regards, tom lane
>
>
I'm sorry. It was all my fault. If been a bit to picky about the files I
copy, and I didn't copy the files directly under the cluster directory.
I thought, there are just the config files, so what's the point. But
this way of course, I didn't copy the backup_label either. It was never
there when I looked, because it was either before or after running a
backup. Reading and especially understanding the manual sometimes helps.
doh!

Now everything seems to work fine, but we are still testing. At least
what we see in the logs is more reasonable. Now the .backup file is
requested first, then the WALs. There is one strange thing left, though.
The server first requests the second WAL, then the first one, then the
second again and then it processes them in order (second, third, fourth,
...). Is this normal?

I hope I didn't distract you from your regular work too much. Thanks again.

Marc