utilities to rebuild commit logs from wal
Before we reinvent the wheel here, does anyone know of utilities to build commit logs from wal segments? Or even to just fill with commits? I figure it is worth asking before I write one.
Re: Code of Conduct plan
that a CoC committee needs to be international and used to addressing these sorts of issues. > > > Be very careful in attempting to codify 'correct' behaviour! >> >> > Correct. I think one way to look at all of this is, "if you wouldn't say > it to your boss or a client don't say it here". That too has problems but > generally speaking I think it keeps the restrictions rational. > > I will post a more specific set of thoughts here but in general I think the presumption ought to be that people are trying to work together. Misunderstanding can happen. But let's try to act in a collegial and generally respectful way around eachother. -- Best Regards, Chris Travers Database Administrator Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com Saarbrücker Straße 37a, 10405 Berlin
Re: pg_rewind and postgresql.conf
On Fri, May 4, 2018 at 2:06 PM, Isaac Morland <isaac.morl...@gmail.com> wrote: > Would it work to use ALTER SYSTEM (postgresql.auto.conf)? Or is that > copied by pg_rewind also? > Yes that is copied currently by pg_rewind, as are server logs if they are in the data directory. I think replication slots also might be copied but would have to check. > > Even if so, using the ALTER SYSTEM command after pg_rewind might be an > easy way of correcting the port back to what you want without doing more > complicated processing or re-writing the entire postgresql.conf. > > On 4 May 2018 at 06:59, Tatsuo Ishii <is...@sraoss.co.jp> wrote: > >> Currently pg_rewind copies all files including postgresql.conf. It >> would be nice if pg_rewind has an option to not copy >> postgresql.conf. I sometimes create multiple PostgreSQL database >> clusters with different port number which postmaster is listening on >> for a testing purpose. So existing postgresql.conf on the target >> cluster being overwritten by pg_rewind is annoying. I believe there >> are some use cases where different port numbers are used among >> PostgreSQL database clusters in the real world. >> >> Comments? >> -- >> Tatsuo Ishii >> SRA OSS, Inc. Japan >> English: http://www.sraoss.co.jp/index_en.php >> Japanese:http://www.sraoss.co.jp >> >> > -- Best Regards, Chris Travers Database Administrator Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com Saarbrücker Straße 37a, 10405 Berlin
Re: pg_rewind and postgresql.conf
On Fri, May 4, 2018 at 12:59 PM, Tatsuo Ishii <is...@sraoss.co.jp> wrote: > Currently pg_rewind copies all files including postgresql.conf. It > would be nice if pg_rewind has an option to not copy > postgresql.conf. I sometimes create multiple PostgreSQL database > clusters with different port number which postmaster is listening on > for a testing purpose. So existing postgresql.conf on the target > cluster being overwritten by pg_rewind is annoying. I believe there > are some use cases where different port numbers are used among > PostgreSQL database clusters in the real world. > > Comments? > I totally agree. Ideally, rewind would just rewind data dirs by default and provide an option to include other files as specified by the administrator. However I ran out of time this time to do this patch and hope to submit again after 11 is finalized. There are two other things that would really be nice to make work too (but think that's another major version away): 1. Make pg_rewind work over the replication protocol so it doesn't require db superuser 2. Unify, to the extent possible, the code base with pg_basebackup. > -- > Tatsuo Ishii > SRA OSS, Inc. Japan > English: http://www.sraoss.co.jp/index_en.php > Japanese:http://www.sraoss.co.jp > > -- Best Regards, Chris Travers Database Administrator Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com Saarbrücker Straße 37a, 10405 Berlin
Re: Feature Request - DDL deployment with logical replication
On Fri, Mar 30, 2018 at 9:26 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > > Our team in PostgresPro is also very interested in this discussion, > because we are using logical decoding in multimaster. > Right now in multimaster DDLs are replicated in this same way as in > pglogical, using "logical messages" with correspondent DDL statements. > There are a couple of problems related with this approach, for example mix > of DDL with DML (create table as...) which we have addressed in multimaster. > > As an alternative we have considered possibility to replicate updates of > catalog tables. In this case we need to address the following issues: > 1. Map OIDs > 2. Perform direct manipulation with files (i.e. truncate, alter table,...) > One very important note here is that since truncate is not replicated there are cases where people are relying on current behaviour. For example, we are going to use logical replication specifically for this reason as a way of replacing our current FDW-based push approach. If truncate is ever replicated, it would be really nice to be able to specify not to replicate it on the subscription level. > 3. Send invalidations > > Looks like it will be not so easy to implement this approach because we > have to repeat or somehow reuse substantial part of executor code for this > DDL nodes. > And definitely this approach works only for Postgres-to-Postgres > replication. > > So it will be very interesting for us to know roadmap for DDL support in > logical replication. > > > -- > Konstantin Knizhnik > Postgres Professional: http://www.postgrespro.com > The Russian Postgres Company > > > -- Best Regards, Chris Travers Database Administrator Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com Saarbrücker Straße 37a, 10405 Berlin
