On Wednesday, April 9, 2014 3:10:35 PM UTC-7, Daniel Farina wrote: > > On Fri, Apr 4, 2014 at 6:27 PM, Joe Van Dyk <[email protected]<javascript:>> > wrote: > > > > $ ls -ldc /mnt/postgresql/9.3/* > > [...] > > drwx------ 2 postgres postgres 4096 Apr 4 18:25 > /mnt/postgresql/9.3/pg_subtrans > > [...] > > > Heh. The last change time is recent, but so it is for several other > directories with thrashing contents, which is expected. Unfortunately > this diagnostic is not as useful as I had hoped because I forgot that > change time is useless on directories with changing entries. > > To make matters worse, I've never seen this bug in spite of all the > backups/restores I've done (automatically) which have fingered several > other obscure bugs. > > All in all, I'd like to pin down two things: > > 1) If one pokes at the tar files in S3 using a program like "tar", is > there no pg_subtrans directory entry in any of them? > > This would isolate the problem to the back-up routine rather than > the restore routines. > > 2) Presuming the first fact yields "yes, it's a problem in taking the > backup", If you take another base backup, does it routinely produce > such problems (i.e. this is workload-dependent, or even > deterministic)? > > Alternatively, if it's a problem in restore, well, life is much easier > because the specific manifest in each tar and can be put under a > microscope and the extraction routines can be fixed for everyone in a > point release. >
Just ran into this with a customer. In our case pg_subtrans exists but is empty on the primary. Unfortunately, the base backup is about 600GB in size, so it will be quite tedious to manually pull down all the segments. Does anyone have a script handy for this? -- You received this message because you are subscribed to the Google Groups "wal-e" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
