Re: ZFS filesystem - supported ?
‐‐‐ Original Message ‐‐‐ On Saturday, October 23rd, 2021 at 18:48, Mladen Gogala wrote: > On 10/23/21 09:37, Laura Smith wrote: > > > Hi Mladen, > > > > Yes indeed, snapshots is the primary reason, closely followed by > > zfssend/receive. > > > > I'm no stranger to using LVM snapshots with ext4/xfs but it requires a > > custom shell script to manage the whole process around backups. I feel the > > whole thing could well be a lot cleaner with zfs. > > > > Thank you for the links, I will take a look. > > > > Laura > > Yes, ZFS is extremely convenient. It's a volume manager and a file > > system, all rolled into one, with some additiional convenient tools. > > However, performance is a major concern. If your application is OLTP, > > ZFS might be a tad too slow for your performance requirements. On the > > other hand, snapshots can save you a lot of time with backups, > > especially if you have some commercial backup capable of multiple > > readers. If your application is OLTP, ZFS might be a tad too slow for > > your performance requirements. The only way to find out is to test. The > > ideal tool for testing is pgio: > > https://kevinclosson.net/2019/09/21/announcing-pgio-the-slob-method-for-postgresql-is-released-under-apache-2-0-and-available-at-github/ > > For those who do not know, Kevin Closson was the technical architect who > > has built both Exadata and EMC XTRemIO. He is now the principal engineer > > of the Amazon RDS. This part is intended only for those who would tell > > him that "Oracle has it is not good enough" if he ever decided to post here. > > Thank you Mladen for your very useful food for thought. I think my plan going forward will be to stick to the old XFS+LVM setup and (maybe) when I have some more time on my hands fire up a secondary instance with ZFS and do some experimentation with pgio. Thanks again !
Re: [Major version upgrade] pg_upgrade fails despite passing check mode
Thanks, let me try that out. But is there a way to know for sure if pg_upgrade will have any such problems? Other than FDW's owner, any other things I should check before upgrading other clusters? Regards Abhishek Bhola On Sat, Oct 23, 2021 at 12:20 AM Laurenz Albe wrote: > On Fri, 2021-10-22 at 17:11 +0900, Abhishek Bhola wrote: > > postgres@dxxxpgs03:/D1/datadg/data13$ /usr/pgsql-13/bin/pg_upgrade > -k --check > > --new-datadir='/D1/datadg/data13' > --old-datadir='/D1/datadg/data' > > --new-bindir='/usr/pgsql-13/bin' --old-bindir='/usr/pgsql-11/bin' > > > > *Clusters are compatible* > > > > But then while performing the actual upgrade, it failed saying the > "owner of a FDW should be a super user" > > > > So I started the old Postgres 11 again, changed the owner of that FDW to > a super user. > > > > Now when I try to run the upgrade (even in check mode) again, it says > "new cluster tablespace directory already exists" > > > > Is it safe to delete the new tablespace directories? > > Don't remove the tablespace directories, because they contain the original > data from the > old cluster. But there should be directories called PG_13_202007201, and > you have to > remove those. > > Yours, > Laurenz Albe > -- > Cybertec | https://www.cybertec-postgresql.com > > -- _This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報（以下、総称して「本情報」といいます。）は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。_
