Creating a role in in the newly created timeline takes ~17 seconds

Compute hangs on CREATE ROLE ... for around 17 seconds. Reproduced well on staging and locally. See all logs bellow.
Storage logs:
pageserver_1   | 2022-08-09T15:29:17.758172Z  INFO tenant_create{tenant=a1684bf9828faf9b6b9a9db0a61c7ada}: created directory structure in /data/tenants/a1684bf9828faf9b6b9a9db0a61c7ada
pageserver_1   | 2022-08-09T15:29:17.758207Z  INFO tenant_create{tenant=a1684bf9828faf9b6b9a9db0a61c7ada}:saving tenantconf: save tenantconf to /data/tenants/a1684bf9828faf9b6b9a9db0a61c7ada/config
pageserver_1   | 2022-08-09T15:29:17.758324Z  INFO POST /v1/tenant/ 201 Created
pageserver_1   | 2022-08-09T15:29:17.758751Z  INFO /timeline_create{tenant=a1684bf9828faf9b6b9a9db0a61c7ada new_timeline=Some(b96d1f01d025879ce6c421b1d483fa64) lsn=None}: running initdb in /data/tenants/a1684bf9828faf9b6b9a9db0a61c7ada/tmp-timeline-b96d1f01d025879ce6c421b1d483fa64...
pageserver_1   | 2022-08-09T15:29:18.217039Z  INFO /timeline_create{tenant=a1684bf9828faf9b6b9a9db0a61c7ada new_timeline=Some(b96d1f01d025879ce6c421b1d483fa64) lsn=None}: reached end of WAL at 0/16960E8
pageserver_1   | 2022-08-09T15:29:18.268002Z  INFO /timeline_create{tenant=a1684bf9828faf9b6b9a9db0a61c7ada new_timeline=Some(b96d1f01d025879ce6c421b1d483fa64) lsn=None}: created root timeline b96d1f01d025879ce6c421b1d483fa64 timeline.lsn 0/16960E8
pageserver_1   | 2022-08-09T15:29:18.283020Z  INFO wal_receiver_main: Processing timeline update: Add(ZTenantTimelineId { tenant_id: a1684bf9828faf9b6b9a9db0a61c7ada, timeline_id: b96d1f01d025879ce6c421b1d483fa64 })
pageserver_1   | 2022-08-09T15:29:18.283074Z  INFO POST /v1/tenant/a1684bf9828faf9b6b9a9db0a61c7ada/timeline/ 201 Created
pageserver_1   | 2022-08-09T15:29:18.283152Z  INFO activating tenant a1684bf9828faf9b6b9a9db0a61c7ada
pageserver_1   | 2022-08-09T15:29:18.283345Z  INFO wal_connection_manager{id=a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64}: WAL receiver broker started, connecting to etcd
pageserver_1   | 2022-08-09T15:29:18.283392Z  INFO wal_connection_manager{id=a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64}:etcd_subscription: Subscribing to broker value updates, key: SubscriptionKey { cluster_prefix: "neon", kind: Operation(ZTenantTimelineId { tenant_id: a1684bf9828faf9b6b9a9db0a61c7ada, timeline_id: b96d1f01d025879ce6c421b1d483fa64 }, Safekeeper, Safekeeper(TimelineInfo)) }
pageserver_1   | 2022-08-09T15:29:18.284828Z  INFO wal_connection_manager{id=a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64}: Subscribed for etcd timeline changes, waiting for new etcd data
safekeeper3_1  | 2022-08-09T15:29:18.892696Z  INFO {tid=16}: got query "START_WAL_PUSH postgresql://(null):@<IP_ADDRESS>:6400"
safekeeper3_1  | 2022-08-09T15:29:18.892723Z  INFO {tid=16}:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper1_1  | 2022-08-09T15:29:18.892810Z  INFO {tid=16}: got query "START_WAL_PUSH postgresql://(null):@<IP_ADDRESS>:6400"
safekeeper1_1  | 2022-08-09T15:29:18.892836Z  INFO {tid=16}:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper4_1  | 2022-08-09T15:29:18.892953Z  INFO {tid=16}: got query "START_WAL_PUSH postgresql://(null):@<IP_ADDRESS>:6400"
safekeeper4_1  | 2022-08-09T15:29:18.892976Z  INFO {tid=16}:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper3_1  | 2022-08-09T15:29:18.903474Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: start handshake with wal proposer <IP_ADDRESS>:52850 sysid 0 timeline 1
safekeeper4_1  | 2022-08-09T15:29:18.903486Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: start handshake with wal proposer <IP_ADDRESS>:57316 sysid 0 timeline 1
safekeeper1_1  | 2022-08-09T15:29:18.903475Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: start handshake with wal proposer <IP_ADDRESS>:41078 sysid 0 timeline 1
safekeeper4_1  | 2022-08-09T15:29:18.905135Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: initialized storage for timeline b96d1f01d025879ce6c421b1d483fa64, flush_lsn=0/0, commit_lsn=0/0, peer_horizon_lsn=0/0
safekeeper4_1  | 2022-08-09T15:29:18.905146Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: processed greeting from proposer [166, 232, 201, 252, 54, 110, 66, 173, 202, 87, 15, 37, 179, 254, 137, 218], sending term 0
safekeeper3_1  | 2022-08-09T15:29:18.905135Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: initialized storage for timeline b96d1f01d025879ce6c421b1d483fa64, flush_lsn=0/0, commit_lsn=0/0, peer_horizon_lsn=0/0
safekeeper3_1  | 2022-08-09T15:29:18.905148Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: processed greeting from proposer [166, 232, 201, 252, 54, 110, 66, 173, 202, 87, 15, 37, 179, 254, 137, 218], sending term 0
safekeeper4_1  | 2022-08-09T15:29:18.905205Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: timeline a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64 active=true now
safekeeper3_1  | 2022-08-09T15:29:18.905205Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: timeline a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64 active=true now
safekeeper1_1  | 2022-08-09T15:29:18.905134Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: initialized storage for timeline b96d1f01d025879ce6c421b1d483fa64, flush_lsn=0/0, commit_lsn=0/0, peer_horizon_lsn=0/0
safekeeper1_1  | 2022-08-09T15:29:18.905148Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: processed greeting from proposer [166, 232, 201, 252, 54, 110, 66, 173, 202, 87, 15, 37, 179, 254, 137, 218], sending term 0
safekeeper1_1  | 2022-08-09T15:29:18.905205Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: timeline a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64 active=true now
safekeeper4_1  | 2022-08-09T15:29:18.907337Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: processed VoteRequest for term 1: VoteResponse { term: 1, vote_given: 1, flush_lsn: 0/0, truncate_lsn: 0/0, term_history: [], timeline_start_lsn: 0/0 }
safekeeper1_1  | 2022-08-09T15:29:18.907337Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: processed VoteRequest for term 1: VoteResponse { term: 1, vote_given: 1, flush_lsn: 0/0, truncate_lsn: 0/0, term_history: [], timeline_start_lsn: 0/0 }
safekeeper3_1  | 2022-08-09T15:29:18.907844Z  INFO {tid=16}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: processed VoteRequest for term 1: VoteResponse { term: 1, vote_given: 1, flush_lsn: 0/0, truncate_lsn: 0/0, term_history: [], timeline_start_lsn: 0/0 }
pageserver_1   | 2022-08-09T15:29:18.908706Z  INFO basebackup{timeline=b96d1f01d025879ce6c421b1d483fa64 tenant=a1684bf9828faf9b6b9a9db0a61c7ada}: starting
pageserver_1   | 2022-08-09T15:29:18.908737Z  INFO basebackup{timeline=b96d1f01d025879ce6c421b1d483fa64 tenant=a1684bf9828faf9b6b9a9db0a61c7ada}: taking basebackup lsn=0/16960E8, prev_lsn=0/1696070 (full_backup=false)
safekeeper4_1  | 2022-08-09T15:29:18.907919Z ERROR {tid=16}: query handler for 'START_WAL_PUSH postgresql://(null):@<IP_ADDRESS>:6400' failed: failed to run ReceiveWalConn
safekeeper4_1  |
safekeeper4_1  | Caused by:
safekeeper4_1  |     connection closed unexpectedly
safekeeper4_1  |
safekeeper4_1  | Stack backtrace:
safekeeper4_1  |    0: safekeeper::receive_wal::ProposerPollStream::new::{{closure}}
safekeeper4_1  |              at /home/runner/safekeeper/src/receive_wal.rs:146:33
safekeeper4_1  |       std::sys_common::backtrace::__rust_begin_short_backtrace
safekeeper4_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys_common/backtrace.rs:123:18
safekeeper4_1  |    1: std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}
safekeeper4_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/thread/mod.rs:484:17
safekeeper4_1  |       <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
safekeeper4_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/panic/unwind_safe.rs:271:9
safekeeper4_1  |       std::panicking::try::do_call
safekeeper4_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:406:40
safekeeper4_1  |       std::panicking::try
safekeeper4_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:370:19
safekeeper4_1  |       std::panic::catch_unwind
safekeeper4_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panic.rs:133:14
safekeeper4_1  |       std::thread::Builder::spawn_unchecked::{{closure}}
safekeeper4_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/thread/mod.rs:483:30
safekeeper4_1  |       core::ops::function::FnOnce::call_once{{vtable.shim}}
safekeeper4_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/ops/function.rs:227:5
safekeeper4_1  |    2: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
safekeeper4_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/alloc/src/boxed.rs:1694:9
safekeeper4_1  |       <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
safekeeper4_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/alloc/src/boxed.rs:1694:9
safekeeper4_1  |       std::sys::unix::thread::Thread::new::thread_start
safekeeper4_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys/unix/thread.rs:106:17
safekeeper4_1  |    3: start_thread
safekeeper4_1  |    4: clone
safekeeper3_1  | 2022-08-09T15:29:18.907926Z ERROR {tid=16}: query handler for 'START_WAL_PUSH postgresql://(null):@<IP_ADDRESS>:6400' failed: failed to run ReceiveWalConn
safekeeper3_1  |
safekeeper3_1  | Caused by:
safekeeper3_1  |     connection closed unexpectedly
safekeeper3_1  |
safekeeper3_1  | Stack backtrace:
safekeeper3_1  |    0: safekeeper::receive_wal::ProposerPollStream::new::{{closure}}
safekeeper3_1  |              at /home/runner/safekeeper/src/receive_wal.rs:146:33
safekeeper3_1  |       std::sys_common::backtrace::__rust_begin_short_backtrace
safekeeper3_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys_common/backtrace.rs:123:18
safekeeper3_1  |    1: std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}
safekeeper3_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/thread/mod.rs:484:17
safekeeper3_1  |       <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
safekeeper3_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/panic/unwind_safe.rs:271:9
safekeeper3_1  |       std::panicking::try::do_call
safekeeper3_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:406:40
safekeeper3_1  |       std::panicking::try
safekeeper3_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:370:19
safekeeper3_1  |       std::panic::catch_unwind
safekeeper3_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panic.rs:133:14
safekeeper3_1  |       std::thread::Builder::spawn_unchecked::{{closure}}
safekeeper3_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/thread/mod.rs:483:30
safekeeper3_1  |       core::ops::function::FnOnce::call_once{{vtable.shim}}
safekeeper3_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/ops/function.rs:227:5
safekeeper3_1  |    2: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
safekeeper3_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/alloc/src/boxed.rs:1694:9
safekeeper3_1  |       <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
safekeeper3_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/alloc/src/boxed.rs:1694:9
safekeeper3_1  |       std::sys::unix::thread::Thread::new::thread_start
safekeeper3_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys/unix/thread.rs:106:17
safekeeper3_1  |    3: start_thread
safekeeper3_1  |    4: clone
safekeeper1_1  | 2022-08-09T15:29:18.907919Z ERROR {tid=16}: query handler for 'START_WAL_PUSH postgresql://(null):@<IP_ADDRESS>:6400' failed: failed to run ReceiveWalConn
safekeeper1_1  |
safekeeper1_1  | Caused by:
safekeeper1_1  |     connection closed unexpectedly
safekeeper1_1  |
safekeeper1_1  | Stack backtrace:
safekeeper1_1  |    0: safekeeper::receive_wal::ProposerPollStream::new::{{closure}}
safekeeper1_1  |              at /home/runner/safekeeper/src/receive_wal.rs:146:33
safekeeper1_1  |       std::sys_common::backtrace::__rust_begin_short_backtrace
safekeeper1_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys_common/backtrace.rs:123:18
safekeeper1_1  |    1: std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}
safekeeper1_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/thread/mod.rs:484:17
safekeeper1_1  |       <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
safekeeper1_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/panic/unwind_safe.rs:271:9
safekeeper1_1  |       std::panicking::try::do_call
safekeeper1_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:406:40
safekeeper1_1  |       std::panicking::try
safekeeper1_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:370:19
safekeeper1_1  |       std::panic::catch_unwind
safekeeper1_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panic.rs:133:14
safekeeper1_1  |       std::thread::Builder::spawn_unchecked::{{closure}}
safekeeper1_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/thread/mod.rs:483:30
safekeeper1_1  |       core::ops::function::FnOnce::call_once{{vtable.shim}}
safekeeper1_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/ops/function.rs:227:5
safekeeper1_1  |    2: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
safekeeper1_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/alloc/src/boxed.rs:1694:9
safekeeper1_1  |       <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
safekeeper1_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/alloc/src/boxed.rs:1694:9
safekeeper1_1  |       std::sys::unix::thread::Thread::new::thread_start
safekeeper1_1  |              at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys/unix/thread.rs:106:17
safekeeper1_1  |    3: start_thread
safekeeper1_1  |    4: clone
pageserver_1   | 2022-08-09T15:29:18.971531Z  INFO basebackup{timeline=b96d1f01d025879ce6c421b1d483fa64 tenant=a1684bf9828faf9b6b9a9db0a61c7ada lsn="0/16960E8"}: done
safekeeper3_1  | 2022-08-09T15:29:19.010661Z  INFO {tid=18}: got query "START_WAL_PUSH postgresql://(null):@<IP_ADDRESS>:6400"
safekeeper3_1  | 2022-08-09T15:29:19.010771Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: start handshake with wal proposer <IP_ADDRESS>:59281 sysid<PHONE_NUMBER>009506341 timeline 0
safekeeper4_1  | 2022-08-09T15:29:19.010886Z  INFO {tid=18}: got query "START_WAL_PUSH postgresql://(null):@<IP_ADDRESS>:6400"
safekeeper4_1  | 2022-08-09T15:29:19.010994Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: start handshake with wal proposer <IP_ADDRESS>:56988 sysid<PHONE_NUMBER>009506341 timeline 0
safekeeper1_1  | 2022-08-09T15:29:19.010737Z  INFO {tid=18}: got query "START_WAL_PUSH postgresql://(null):@<IP_ADDRESS>:6400"
safekeeper1_1  | 2022-08-09T15:29:19.010844Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: start handshake with wal proposer <IP_ADDRESS>:63964 sysid<PHONE_NUMBER>009506341 timeline 0
safekeeper3_1  | 2022-08-09T15:29:19.013596Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: processed greeting from proposer [218, 202, 6, 157, 239, 195, 80, 22, 0, 15, 251, 63, 1, 74, 205, 247], sending term 1
safekeeper4_1  | 2022-08-09T15:29:19.013604Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: processed greeting from proposer [218, 202, 6, 157, 239, 195, 80, 22, 0, 15, 251, 63, 1, 74, 205, 247], sending term 1
safekeeper1_1  | 2022-08-09T15:29:19.013603Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: processed greeting from proposer [218, 202, 6, 157, 239, 195, 80, 22, 0, 15, 251, 63, 1, 74, 205, 247], sending term 1
safekeeper1_1  | 2022-08-09T15:29:19.015199Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: processed VoteRequest for term 2: VoteResponse { term: 2, vote_given: 1, flush_lsn: 0/0, truncate_lsn: 0/0, term_history: [], timeline_start_lsn: 0/0 }
safekeeper4_1  | 2022-08-09T15:29:19.015191Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: processed VoteRequest for term 2: VoteResponse { term: 2, vote_given: 1, flush_lsn: 0/0, truncate_lsn: 0/0, term_history: [], timeline_start_lsn: 0/0 }
safekeeper3_1  | 2022-08-09T15:29:19.015191Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: processed VoteRequest for term 2: VoteResponse { term: 2, vote_given: 1, flush_lsn: 0/0, truncate_lsn: 0/0, term_history: [], timeline_start_lsn: 0/0 }
safekeeper3_1  | 2022-08-09T15:29:19.015419Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: received ProposerElected ProposerElected { term: 2, start_streaming_at: 0/16960E8, term_history: [(2, 0/16960E8)], timeline_start_lsn: 0/16960E8 }
safekeeper1_1  | 2022-08-09T15:29:19.015484Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: received ProposerElected ProposerElected { term: 2, start_streaming_at: 0/16960E8, term_history: [(2, 0/16960E8)], timeline_start_lsn: 0/16960E8 }
safekeeper4_1  | 2022-08-09T15:29:19.015576Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: received ProposerElected ProposerElected { term: 2, start_streaming_at: 0/16960E8, term_history: [(2, 0/16960E8)], timeline_start_lsn: 0/16960E8 }
safekeeper4_1  | 2022-08-09T15:29:19.061122Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: setting timeline_start_lsn to 0/16960E8
safekeeper4_1  | 2022-08-09T15:29:19.061144Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: setting local_start_lsn to 0/16960E8
safekeeper3_1  | 2022-08-09T15:29:19.062336Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: setting timeline_start_lsn to 0/16960E8
safekeeper3_1  | 2022-08-09T15:29:19.062355Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: setting local_start_lsn to 0/16960E8
safekeeper1_1  | 2022-08-09T15:29:19.063584Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: setting timeline_start_lsn to 0/16960E8
safekeeper1_1  | 2022-08-09T15:29:19.063606Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: setting local_start_lsn to 0/16960E8
safekeeper4_1  | 2022-08-09T15:29:19.064144Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: start receiving WAL since 0/16960E8
safekeeper3_1  | 2022-08-09T15:29:19.065667Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: start receiving WAL since 0/16960E8
safekeeper1_1  | 2022-08-09T15:29:19.066570Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: start receiving WAL since 0/16960E8
safekeeper2_1  | 2022-08-09T15:29:19.160400Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:19.379867Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:19.659637Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:20.164084Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:20.381612Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:20.660998Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:21.166260Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:21.384760Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:21.663114Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:22.169242Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:22.386691Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:22.665738Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:23.172628Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:23.388432Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:23.669240Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:24.175326Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:24.391773Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:24.673281Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:25.177125Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:25.394718Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:25.675564Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:26.179618Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:26.397173Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:26.678888Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:27.182494Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:27.400190Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:27.681465Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:28.185458Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:28.403784Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:28.683011Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:29.188687Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:29.406461Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:29.685162Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:30.191271Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:30.409675Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:30.687244Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:31.194692Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:31.412481Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:31.689874Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:32.197641Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:32.415257Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:32.692889Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:33.200918Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:33.417447Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:33.695165Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper3_1  | 2022-08-09T15:29:34.079695Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: restart decoder from 0/0 to 0/16960E8
safekeeper4_1  | 2022-08-09T15:29:34.079842Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: restart decoder from 0/0 to 0/16960E8
safekeeper1_1  | 2022-08-09T15:29:34.079698Z  INFO {tid=18}:WAL acceptor{timeline=b96d1f01d025879ce6c421b1d483fa64}: restart decoder from 0/0 to 0/16960E8
safekeeper2_1  | 2022-08-09T15:29:34.204111Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
pageserver_1   | 2022-08-09T15:29:34.204261Z  INFO wal_connection_manager{id=a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64}: Switching to new connection candidate: NewWalConnectionCandidate { safekeeper_id: NodeId(3), wal_source_connstr: "host=safekeeper3 port=6500 options='-c ztimelineid=b96d1f01d025879ce6c421b1d483fa64 ztenantid=a1684bf9828faf9b6b9a9db0a61c7ada'", reason: NoExistingConnection }
pageserver_1   | 2022-08-09T15:29:34.204384Z  INFO walreceiver_connection{id=a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64}: connecting to host=safekeeper3 port=6500 options='-c ztimelineid=b96d1f01d025879ce6c421b1d483fa64 ztenantid=a1684bf9828faf9b6b9a9db0a61c7ada'
pageserver_1   | 2022-08-09T15:29:34.206057Z  INFO walreceiver_connection{id=a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64}:safekeeper_handle_db: connected!
safekeeper3_1  | 2022-08-09T15:29:34.206194Z  INFO {tid=21}: got query "IDENTIFY_SYSTEM"
pageserver_1   | 2022-08-09T15:29:34.206421Z  INFO walreceiver_connection{id=a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64}: IdentifySystem { systemid:<PHONE_NUMBER>009506341, timeline: 1, xlogpos: 0/1696B98, dbname: None }
pageserver_1   | 2022-08-09T15:29:34.206586Z  INFO walreceiver_connection{id=a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64}: last_record_lsn 0/16960E8 starting replication from 0/16960E8, server is at 0/1696B98...
safekeeper3_1  | 2022-08-09T15:29:34.207056Z  INFO {tid=21}: got query "START_REPLICATION PHYSICAL 0/16960E8"
safekeeper3_1  | 2022-08-09T15:29:34.207247Z  INFO {tid=21}:WAL sender{timeline=b96d1f01d025879ce6c421b1d483fa64}: Start replication from 0/16960E8 till None
pageserver_1   | 2022-08-09T15:29:34.207956Z  INFO walreceiver_connection{id=a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64}: caught up at LSN 0/1696B98
safekeeper2_1  | 2022-08-09T15:29:34.420074Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:34.697776Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
pageserver_1   | 2022-08-09T15:29:35.116197Z  INFO walreceiver_connection{id=a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64}: Created database 1663/16386, copied 1010 blocks in 292 rels
safekeeper2_1  | 2022-08-09T15:29:35.206118Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:35.422676Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:35.700604Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:36.208611Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:36.425320Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:36.703245Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:37.212075Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control
safekeeper2_1  | 2022-08-09T15:29:37.427751Z  INFO broker:{timeline=a1684bf9828faf9b6b9a9db0a61c7ada}: loading control file ./a1684bf9828faf9b6b9a9db0a61c7ada/b96d1f01d025879ce6c421b1d483fa64/safekeeper.control

Compute log:
2022-08-09 15:29:18.889 UTC [main] INFO: starting compute for project steep-fog-243105, operation 8c8ef877-e0c0-4cfc-8c31-1e8f0cb0899f, tenant a1684bf9828faf9b6b9a9db0a61c7ada, timeline b96d1f01d025879ce6c421b1d483fa64
2022-08-09 15:29:18.890 UTC [main] INFO: starting safekeepers syncing
2022-08-09 15:29:18.890 UTC [http-endpoint] INFO: starting HTTP server on <IP_ADDRESS>:3080
2022-08-09 15:29:18.890 UTC [compute-monitor] INFO: watching Postgres activity at postgresql://cloud_admin@localhost/postgres
2022-08-09 15:29:18.891 GMT [12] LOG:  skipping missing configuration file "/var/db/postgres/compute/pgdata/postgresql.auto.conf"
2022-08-09 15:29:18.891 GMT [12] LOG:  creating missing WAL directory "pg_wal"
2022-08-09 15:29:18.892 GMT [12] LOG:  connecting with node <IP_ADDRESS>:6500
2022-08-09 15:29:18.892 GMT [12] LOG:  connecting with node <IP_ADDRESS>:6500
2022-08-09 15:29:18.892 GMT [12] LOG:  connecting with node <IP_ADDRESS>:6500
2022-08-09 15:29:18.892 GMT [12] LOG:  connected with node <IP_ADDRESS>:6500
2022-08-09 15:29:18.892 GMT [12] LOG:  connected with node <IP_ADDRESS>:6500
2022-08-09 15:29:18.892 GMT [12] LOG:  connected with node <IP_ADDRESS>:6500
2022-08-09 15:29:18.905 GMT [12] LOG:  proposer connected to quorum (2) safekeepers, propTerm=1
2022-08-09 15:29:18.905 GMT [12] LOG:  requesting vote from <IP_ADDRESS>:6500 for term 1
2022-08-09 15:29:18.905 GMT [12] LOG:  requesting vote from <IP_ADDRESS>:6500 for term 1
2022-08-09 15:29:18.905 GMT [12] LOG:  requesting vote from <IP_ADDRESS>:6500 for term 1
2022-08-09 15:29:18.907 GMT [12] LOG:  got VoteResponse from acceptor <IP_ADDRESS>:6500, voteGiven=1, epoch=0, flushLsn=0/0, truncateLsn=0/0, timelineStartLsn=0/0
2022-08-09 15:29:18.907 GMT [12] LOG:  got VoteResponse from acceptor <IP_ADDRESS>:6500, voteGiven=1, epoch=0, flushLsn=0/0, truncateLsn=0/0, timelineStartLsn=0/0
2022-08-09 15:29:18.907 GMT [12] LOG:  got votes from majority (2) of nodes, term 1, epochStartLsn 0/0, donor <IP_ADDRESS>:6500, truncate_lsn 0/0
2022-08-09 15:29:18.907 UTC [main] INFO: safekeepers synced at LSN 0/0
2022-08-09 15:29:18.907 UTC [main] INFO: getting basebackup@0/0 from pageserver host=<IP_ADDRESS> port=6400
2022-08-09 15:29:18.995 UTC [main] INFO: checking pg_hba.conf
2022-08-09 15:29:18.995 UTC [main] INFO: updated pg_hba.conf to allow external connections
2022-08-09 15:29:19.006 GMT [19] LOG:  starting PostgreSQL 14.4 on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
2022-08-09 15:29:19.006 GMT [19] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2022-08-09 15:29:19.006 GMT [19] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2022-08-09 15:29:19.007 GMT [20] LOG:  [ZENITH] found 'zenith.signal' file. setting prev LSN to 0/1696070
2022-08-09 15:29:19.007 GMT [20] LOG:  database system was shut down at 2022-08-09 15:29:18 GMT
2022-08-09 15:29:19.007 GMT [20] LOG:  starting with zenith basebackup at LSN 0/16960E8, prev 0/1696070
2022-08-09 15:29:19.007 GMT [20] LOG:  Continue writing WAL at 0/16960E8
2022-08-09 15:29:19.009 GMT [19] LOG:  database system is ready to accept connections
2022-08-09 15:29:19.010 GMT [24] LOG:  [NEON_SMGR] libpagestore: connected to 'host=<IP_ADDRESS> port=6400'
2022-08-09 15:29:19.010 GMT [27] LOG:  [NEON_SMGR] libpagestore: connected to 'host=<IP_ADDRESS> port=6400'
2022-08-09 15:29:19.010 GMT [26] LOG:  connecting with node <IP_ADDRESS>:6500
2022-08-09 15:29:19.010 GMT [26] LOG:  connecting with node <IP_ADDRESS>:6500
2022-08-09 15:29:19.010 GMT [26] LOG:  connecting with node <IP_ADDRESS>:6500
2022-08-09 15:29:19.010 GMT [26] LOG:  connected with node <IP_ADDRESS>:6500
2022-08-09 15:29:19.010 GMT [26] LOG:  connected with node <IP_ADDRESS>:6500
2022-08-09 15:29:19.010 GMT [26] LOG:  connected with node <IP_ADDRESS>:6500
2022-08-09 15:29:19.013 GMT [26] LOG:  proposer connected to quorum (2) safekeepers, propTerm=2
2022-08-09 15:29:19.013 GMT [26] LOG:  requesting vote from <IP_ADDRESS>:6500 for term 2
2022-08-09 15:29:19.013 GMT [26] LOG:  requesting vote from <IP_ADDRESS>:6500 for term 2
2022-08-09 15:29:19.013 GMT [26] LOG:  requesting vote from <IP_ADDRESS>:6500 for term 2
2022-08-09 15:29:19.015 GMT [26] LOG:  got VoteResponse from acceptor <IP_ADDRESS>:6500, voteGiven=1, epoch=0, flushLsn=0/0, truncateLsn=0/0, timelineStartLsn=0/0
2022-08-09 15:29:19.015 GMT [26] LOG:  got VoteResponse from acceptor <IP_ADDRESS>:6500, voteGiven=1, epoch=0, flushLsn=0/0, truncateLsn=0/0, timelineStartLsn=0/0
2022-08-09 15:29:19.015 GMT [26] LOG:  bumped epochStartLsn to the first record 0/16960E8
2022-08-09 15:29:19.015 GMT [26] LOG:  got votes from majority (2) of nodes, term 2, epochStartLsn 0/16960E8, donor <IP_ADDRESS>:6500, truncate_lsn 0/16960E8
2022-08-09 15:29:19.015 GMT [26] LOG:  sending elected msg to node 3 term=2, startStreamingAt=0/16960E8 (lastCommonTerm=0), termHistory.n_entries=1 to <IP_ADDRESS>:6500, timelineStartLsn=0/16960E8
2022-08-09 15:29:19.015 GMT [26] LOG:  sending elected msg to node 1 term=2, startStreamingAt=0/16960E8 (lastCommonTerm=0), termHistory.n_entries=1 to <IP_ADDRESS>:6500, timelineStartLsn=0/16960E8
2022-08-09 15:29:19.015 GMT [26] LOG:  WAL proposer starts streaming at 0/16960E8
2022-08-09 15:29:19.015 GMT [26] LOG:  got VoteResponse from acceptor <IP_ADDRESS>:6500, voteGiven=1, epoch=0, flushLsn=0/0, truncateLsn=0/0, timelineStartLsn=0/0
2022-08-09 15:29:19.015 GMT [26] LOG:  sending elected msg to node 8 term=2, startStreamingAt=0/16960E8 (lastCommonTerm=0), termHistory.n_entries=1 to <IP_ADDRESS>:6500, timelineStartLsn=0/16960E8
2022-08-09 15:29:19.068 GMT [26] LOG:  standby "walproposer" is now a synchronous standby with priority 1
2022-08-09 15:29:19.097 GMT [30] LOG:  [NEON_SMGR] libpagestore: connected to 'host=<IP_ADDRESS> port=6400'
2022-08-09 15:29:19.105 UTC [main] INFO: postgres roles:
2022-08-09 15:29:19.105 UTC [main] INFO: processing role renames
                                 - cloud_admin:(null)
                                 - pg_database_owner:(null)
                                 - pg_read_all_data:(null)
                                 - pg_write_all_data:(null)
                                 - pg_monitor:(null)
                                 - pg_read_all_settings:(null)
                                 - pg_read_all_stats:(null)
                                 - pg_stat_scan_tables:(null)
                                 - pg_read_server_files:(null)
                                 - pg_write_server_files:(null)
                                 - pg_execute_server_program:(null)
                                 - pg_signal_backend:(null)
2022-08-09 15:29:19.106 UTC [main] INFO: cluster spec roles:
2022-08-09 15:29:19.106 UTC [main] INFO: role name: 'ololobus'
2022-08-09 15:29:19.106 UTC [main] INFO: role create query: 'CREATE ROLE "ololobus" '
2022-08-09 15:29:19.392 GMT [32] LOG:  [NEON_SMGR] libpagestore: connected to 'host=<IP_ADDRESS> port=6400'
2022-08-09 15:29:19.824 UTC [tokio-runtime-worker] INFO: serving /ready GET request
2022-08-09 15:29:19.825 UTC [tokio-runtime-worker] INFO: serving /status GET request
2022-08-09 15:29:19.926 UTC [tokio-runtime-worker] INFO: serving /ready GET request
2022-08-09 15:29:19.927 UTC [tokio-runtime-worker] INFO: serving /status GET request
2022-08-09 15:29:20.028 UTC [tokio-runtime-worker] INFO: serving /ready GET request
...
2022-08-09 15:29:35.076 UTC [tokio-runtime-worker] INFO: serving /ready GET request
2022-08-09 15:29:35.076 UTC [tokio-runtime-worker] INFO: serving /status GET request
2022-08-09 15:29:35.082 UTC [main] INFO: role grant query: 'GRANT pg_read_all_data, pg_write_all_data TO "ololobus"'
2022-08-09 15:29:35.082 UTC [main] INFO: role name: 'web_access'
2022-08-09 15:29:35.082 UTC [main] INFO: role create query: 'CREATE ROLE "web_access" '
                                 - ololobus:[FILTERED] -> create
2022-08-09 15:29:35.087 UTC [main] INFO: role grant query: 'GRANT pg_read_all_data, pg_write_all_data TO "web_access"'
                                 - web_access:[FILTERED] -> create
                                 - postgres:cloud_admin
                                 - template1:cloud_admin
                                 - template0:cloud_admin
2022-08-09 15:29:35.101 UTC [main] INFO: postgres databases:
2022-08-09 15:29:35.101 UTC [main] INFO: processing delta operations on databases
2022-08-09 15:29:35.101 UTC [main] INFO: cluster spec databases:
                                 - main:ololobus -> create
2022-08-09 15:29:35.106 UTC [main] INFO: reassigning dependent objects of to-be-deleted roles
2022-08-09 15:29:35.106 UTC [main] INFO: processing role deletions
2022-08-09 15:29:35.107 UTC [main] INFO: cluster spec grants:
2022-08-09 15:29:35.107 UTC [main] INFO: grant query GRANT CREATE ON DATABASE "main" TO "ololobus", "web_access"
2022-08-09 15:29:35.109 GMT [35] LOG:  [NEON_SMGR] libpagestore: connected to 'host=<IP_ADDRESS> port=6400'
2022-08-09 15:29:35.138 UTC [main] INFO: finished configuration of compute for project steep-fog-243105

Looks like something is wrong with walreceiver indeed, I'll try to prepare a patch that can fix the issue.

It seems that startup time has become better after the #2253. I'm closing this issue, but if you have another case with a long startup time you can create a new issue with the logs attached.


fix: remove deprecated queries

What: fix: remove deprecated queries

Why: Closes #223

How: Removed the queries and updated tests for those old queries to use the newer ByDisplayValue variant.
Checklist:

[ ] Documentation added to the docs site N/A
[x] Typescript definitions updated
[x] Tests
[x] Ready to be merged

BREAKING CHANGE: This removes the deprecated queries ByValue and BySelectText. Use ByDisplayValue instead.

Note: this is on the next branch because it's a breaking change that I want to combine with #202 👍


[BUG] Join on missing field in Batch File Write to System32

Describe the bug
In the following search Batch File Write to System32 it's defined a join on process_guid, _time, however process_guid is not a defined field in either of the subsearches.
Expected behavior
process_guid needs to be added to the by part of both the Filesystem search and Processes search

Looks like the bulk update I did for proc_guid -> process_guid a few months ago missed this one.
My local search is configured as you suggest already, I'll probably make a pull request to correct the issue.
Standby


folds aren't open on game start

I just fixed it. Thank you for reporting.
https://github.com/johngrib/vim-game-code-break/commit/1a8dd469b849864956aa3ddeda7700105e7c6c92


Github Actions problem with final upload of the artefact if H.264 or X11 is defined

Since I'm just concentrating on Android at the moment, I can just report a problem for this build.
Symptom: The upload of the final artefact fails, because the GH script tries to upload a package which doesn't exist:

Reason:
In libwebrtc-bin/build/common.mk there is some magic applied to the package name, depending on whether H264 and/or X11 is defined. The final upload doesn't take that possible renaming in account.
libwebrtc-bin/build/common.mk:
PACKAGE_NAME := libwebrtc

ifneq (x$(TARGET_OS),x)
PACKAGE_NAME += -$(TARGET_OS)
endif
ifneq (x$(TARGET_CPU),x)
PACKAGE_NAME += -$(TARGET_CPU)
endif

ifeq ($(USE_H264),1)
RTC_USE_H264 := rtc_use_h264=true
PACKAGE_NAME += -h264
else
RTC_USE_H264 := rtc_use_h264=false
endif

ifeq ($(USE_X11),1)
RTC_USE_X11 := rtc_use_x11=true
PACKAGE_NAME += -x11
else
RTC_USE_X11 := rtc_use_x11=false
endif

Leads to a package libwebrtc-android-h264.tar.xz. The upload tries to upload libwebrtc-android.tar.xz
libwebrtc-bin/.github/workflows/build.yml:
      - name: Upload artifact
        uses: actions/upload-artifact@v3
        with:
          name: libwebrtc-${{ matrix.name }}.tar.xz
          path: package/libwebrtc-${{ matrix.name }}.tar.xz

libwebrtc-bin is not planned to distribute H264 or X11-compatible binaries, so it does not support renaming packages depending on flags.
Distribution of H.264-compatible binaries is not planned because it may infringe on patents.
https://www.ffmpeg.org/legal.html
Also, this repository is not the libwebrtc-bin repository.

Yes, forget about. Thanks.


Custom http_code stats

Hi,
I have hacked up locust to provide me with some custom stats, so that I can count the different occurrences of certain status codes. So far I have this working well when running the process by itself however, If fails to give me the stats when running in distributed mode.
I guess I need to do something here to send the stats back from the slave to the master or for the master to recognise them. Would someone be able to point me in the correct direction please ?
Thanks
Mark

@pixie79 do you have an example on how you've done it in standalone mode. @heyman, is there an easy way to do it ?


Feature request: allow customizing server$ HTTP method

Currently, all requests done on the client-side for a server$ function are POST requests. This makes sense as a default, but there are many possible use-cases for server$ for simply querying data, where a GET request would be more appropriate. This is not just semantics, with the problem I run into the impossibility of caching server$ requests on Vercel's Edge Network. Therefore, I would appreciate the option to select a different HTTP method. For context, I raised this issue for pRPC (OrJDev/prpc#73), which uses server$ for a query$ function under the hood, which therefore is limited by Solid Start.

Awesome – can't wait!

Not sure why POST would even make sense as the default, actually...
What is the default of HTML (<form> tag without method specified)?: GET
What is the default CURL uses?: GET
What is the default of fetch?: GET
IMHO there is only one sane default for requests and that is GET...

@Download The only reason POST makes sense is because the server functions utilizes the request body, something that GET cannot offer. However, GET can be potentially supported, ideally if the function has no arguments or if the arguments can be safely encoded in the url.
Other methods should work just fine

This has been implemented in SolidStart in 0.5.x via the GET method.


Add fallback when function missing name attribute

Some callables do not have a __name__ attribute, for example those returned by functools.partial (see here). Using getattr(fun, '__name__', '[unknown name]') instead of just fun.__name__ prevents an AttributeError being thrown when attaching  __name__ and __doc__ in this case.

Thanks! It seems that the automatic tests failed for Python 3 reasons though. Can you take a look at that?

Hey Matt, the test which failed for Python 3 was test_flatten.test_flatten_dict. I ran the tests a few times in Python 3.5 on my local machine and found that that test sometimes passed and sometimes failed.
I've had a closer look and when failures do occur the two arrays being compared in the test appear to be mismatched by a significant amount (suggesting that it's not just some floating point precision problem), for example one time I ran the test the two arrays were
array([  1.000000e+00,   4.000000e+00,   7.000000e+00,   9.000000e+00,
         4.152500e-01,   1.218706e-01,   7.217785e-01,   2.730539e-01,
         7.993437e-01,   7.420543e-01,   5.231172e-01,   3.809207e-01,...

and
 array([  3.000000e+00,   4.152500e-01,   1.218706e-01,   7.217785e-01,
         2.730539e-01,   7.993437e-01,   7.420543e-01,   5.231172e-01,
         3.809207e-01,   5.419064e-01,   3.785590e-01,   2.119098e-01,...

Anyway it looks like there's some problem with flatten that is unrelated to the changes in this pr.

Thanks, you're totally right! We'll fix the flatten issue.

I fixed the issue you found.  It was due to not calling sorted() when iterating the elements of a dictionary.  Thanks for the debugging help!


option to count WPM

Hello,
Just wondering if an option to show WPM could be made available.
Thank you.

hey @neonfrontier could you elaborate what you mean with "WPM"?

Sorry that means "Words Per Minute".

Ahh got it, well, I'd love to see a PR for this ✨

@davidlday typing speed. :)


refactor (PART II) Split local exchange operators from loc…

…al exchanger
Problem Summary:
This is a PR which wants to decouple the local exchanger and local exchange operators.
Since all type of exchangers are similar as exchange sink does, I plan to use exchanger to split data in both local exchange operators and exchange sink operators.
Release note
None
Check List (For Author)

Test

[ ] Regression test
[ ] Unit Test
[ ] Manual test (add detailed scripts or steps below)
[ ] No need to test or manual test. Explain why:

[ ] This is a refactor/code format and no logic has been changed.
[ ] Previous test can cover this change.
[ ] No code files have been changed.
[ ] Other reason

Behavior changed:

[ ] No.
[ ] Yes.

Does this need documentation?

[ ] No.
[ ] Yes.

Check List (For Reviewer who merge this PR)

[ ] Confirm the release note
[ ] Confirm test cases
[ ] Confirm document
[ ] Add branch pick label

run buildall

run buildall


Add dtype resolver

Codecov Report
Patch coverage: 100.00% and no project coverage change.

Comparison is base (676abad) 100.00% compared to head (d09ac68) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #36   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            5         5
  Lines          111       115    +4
  Branches         6         6
=========================================
+ Hits           111       115    +4

Impacted Files
Coverage Δ

src/hya/pytorch.py
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Add HTTP Support

This is useful for when you have nodered behind a ssl terminating reverse proxy, such as traefik, or nginx.
There's a new UI option for selecting 'protocol' (http or https). When https is selected, the cert and key text boxes are visible, and they are hidden when http is selected, since they're not relevant for http.
Fixes issue #11

@DeanCording could you take a look at this PR and provide feedback?

Thanks @vkhurana,
I'm working on the API 2.0 version at the moment and will incorporate the HTTP support with it.

That sounds good @DeanCording, by when do you think that'll be done?
I've currently patched the node locally, and i'm using the patched version. I'd rather not do that :)
If 2.0 is far out, maybe we can merge this for now, to unblock others too?


Assertion Front-End: Initial Version

This PR contains a PoC front-end for Assurance Assertions, and is currently running at https://oafdev1.westus2.cloudapp.azure.com.

https://user-images.githubusercontent.com/47256853/233919010-6e9a3ed0-de1d-4080-95fc-e702872d6651.mov
PR #135
Commit 1: Fixed missing python library psycopg2 in requirements.txt, that is currently used in the project.
Commit 2:I had some hiccups setting up this project and building the local dev environment. I have noted my steps and created a README that might be useful for new contributors. Please review it and let me know if that would be something valuable / needs any changes or not really required atm.
Commit 3: Home page slack carousel mentions the Slack channel, but there is no link to it anywhere within the website. This UI change will open slack channel for existing current members, or open the webpage shown in the video for new users.

Will merge into main tomorrow to not conflict with the Mentee's demo


Stepfunction not detecting changes to nested stacks

Describe the bug
We had our initial implementation using 1.2 of control tower customisations and moved to 2.1 recently. We use cloud formation nested stacks to deploy specific things to target OUs and accounts. In our of recent update, we realised that step function is not picking up any changes to child stack in a nested stack. Looking through the customisation code, we realised this was due to an improvement introduced in 2.0 to optimise the flow by comparing cloudformation templates using filecmp here.
To Reproduce
Deploy a nested stack to a target OU or account using CT customisation flow. Introduce an update to one of the child stacks in the nested stack. As part of customisation execution, step functions will not detect the change and hence no stackset update will be triggered
Expected behavior
Updates should be detected by CT customisation step function and changes should be pushed using stackset updates
Please complete the following information about the solution:

[X] Version: v2.1.0
[X] Region: ap-southeast-2
[X] Was the solution modified from the version published on this repository? - No
[ ] If the answer to the previous question was yes, are the changes available on GitHub?
[X] Have you checked your service quotas for the sevices this solution uses?
[X] Were there any errors in the CloudWatch Logs? [How to enable debug mode?] - No (https://docs.aws.amazon.com/solutions/latest/amazon-cloudwatch-monitoring-framework/troubleshooting.html)

Additional context
If this issue is not getting prioritised, please update the documentation so that it is a known limitation with nested stacks and CT customisation

The support to analyze the nested stacks is not supported. The template (file or remote path) in the manifest is only file is compared with the deployed stack set template.

@groverlalit Can we please have documentation updated to reflect this? Especially for teams who were using older version and upgrading to latest?

Hi @yogiwiz The code you referred to in ticket was shipped in v1.1. It has been always only comparing the templates (top-level) in the manifest and not the nested stacks. Thanks.


Fixed issue #58 - convert splunk_installer to a real resource

Fixed issue #58 Converted the splunk_installer definition into a custom resource
Fixed issue #101 Added sensitive true to the execute resource
Fixed issue #118 removed omnios platform tests
bumped chef-vault dependency to ~> 3.1.1
moved content from files/default and templates/default in accordance with modern file specificity rules
require Chef 13.11 or newer
Removed (undocumented) support for Solaris (OmniOS) platform; omnios is not a platform
that can currently be tested under ChefSpec and Test Kitchen.

Description
This converts the splunk_installer definition to a custom resource.
Issues Resolved
#58
#101
#118
Check List

[X] All tests pass. See https://github.com/chef-cookbooks/community_cookbook_documentation/blob/master/TESTING.MD
[X] New functionality includes testing.
[X] New functionality has been documented in the README if applicable
[X] All commits have been signed for the Developer Certificate of Origin. See https://github.com/chef-cookbooks/community_cookbook_documentation/blob/master/CONTRIBUTING.MD

@haidangwa Thanks for taking this on. It's going to be nice to have a real resource here.


Progress Circle Show Text

Hello Guys,
Am I wrong or the progress circle text (current percentage) does not show when the current progress is 0?
Right now if I send progress={0} , no text at all will be shown.

This is fixed in 3.2.0.


Fix writePlot3dCoef()

Purpose
Fixes the bug discussed in #40
Type of change

Bugfix (non-breaking change which fixes an issue)

Testing
Follow the steps described in the issue, now the code does not error out and the output file is ordered correctly to be read by Tecplot.
Checklist
Put an x in the boxes that apply.

[x] I have run unit and regression tests which pass locally with my changes (although that small function is probably not covered)
[ ] I have added new tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation

@bbrelje @joanibal this PR should be ready to go, it's a small but pretty useful fix!

@marcomangano do you happen to know when the character flag was introduced? will this break backward compatibility with any versions of numpy that you know of?

@bbrelje I briefly mention it in the linked issue. I think the character flag has been around for a few versions, but the code broke with numpy>=1.18. I tried the fix on numpy==1.16 and it works. As that is the minimum requirement for our supported versions I do not foresee any issue, but it is your call in case you want to make a new release.
We should probably add a test for this, but I believe there are other relevant parts of the code with higher priority, right?


problem decoding and renaming

As you can see, the decoding of the file is done but without renaming and a file is persisting.

Is this still an issue ?

Closing this issue.  Please re-open if needed.


[SPARK-41416][SQL] Rewrite self join in in predicate to aggregate

What changes were proposed in this pull request?
Transforms the SelfJoin resulting in duplicate rows used for IN predicate to aggregation.
For IN predicate, duplicate rows does not have any value. It will be overhead.
Ex: TPCDS Q95: following CTE is used only in IN predicates for only one column comparison ({@code ws_order_number}).
This results in exponential increase in Joined rows with too many duplicate rows.
WITH ws_wh AS
(
       SELECT ws1.ws_order_number,
              ws1.ws_warehouse_sk wh1,
              ws2.ws_warehouse_sk wh2
       FROM   web_sales ws1,
              web_sales ws2
       WHERE  ws1.ws_order_number = ws2.ws_order_number
       AND    ws1.ws_warehouse_sk <> ws2.ws_warehouse_sk)

Could be optimized as below:
WITH ws_wh AS
    (SELECT ws_order_number
      FROM  web_sales
      GROUP BY ws_order_number
      HAVING COUNT(DISTINCT ws_warehouse_sk) > 1)

Optimized CTE scans table only once and results in unique rows.
Why are the changes needed?
Optimize TPCDS Q95,  reference code
https://github.com/rohankumardubey/hetu/blob/master/presto-main/src/main/java/io/prestosql/sql/planner/iterative/rule/TransformUnCorrelatedInPredicateSubQuerySelfJoinToAggregate.java
Does this PR introduce any user-facing change?
No
How was this patch tested?
Added UT

Can one of the admins verify this patch?


Release updates

Checklist

[ ] Test your changes as thoroughly as possible before you commit them. Preferably, automate your test by unit/integration tests.
[ ] If this PR comes from a fork, please Allow edits from maintainers
[ ] Set a speaking title. Format: {task_name} (closes #{issue_number}). For example: Use logger (closes #41)
[ ] Link your Pull Request to an issue (if applicable)
[ ] Create Work In Progress [WIP] pull requests only if you need clarification or an explicit review before you can continue your work item.
[ ] Make sure that your PR is not introducing unncessary reformatting (e.g., introduced by on-save hooks in your IDE)
[ ] Check our Contribution Guidelines

Description

Your merge cause the pull request #41  to be closed. Problem is the description of the default issue template causing the #41 PR mentioned all the time.
Could you please open it again?


tools/version.sh: Fix version number to get on master branch

Summary
When we get the nuttx version from git on the master branch, we get
'10.1.0-RC1' by 'git tag --sort=v:refname'. It would be better to get
'10.1.0' with '--sort=taggerdate' option.
Impact
None
Testing

I have some sort of a recollection that taggerdate caused problems, but I can't remember neither can I produce any issue with the given command. So, LGTM.

I just tested this and get the result from the first describe not the second check. So it is still reporting wrong the wrong version.

@davids5
Yes, it Is another problem.
Would your problem be solved if I pushed the following change?
diff --git a/tools/version.sh b/tools/version.sh
index 5e54eae3b7..51bb4ad220 100755
--- a/tools/version.sh
+++ b/tools/version.sh
@@ -75,7 +75,7 @@ if [ -z ${VERSION} ] ; then

   # If the VERSION does not match X.Y.Z, retrieve version from the tag

-  if [[ ! ${VERSION} =~ ([0-9]+)\.([0-9]+)\.([0-9]+) ]] ; then
+  if [[ ! ${VERSION} =~ nuttx-([0-9]+)\.([0-9]+)\.([0-9]+) ]] ; then
     VERSION=`git -C ${WD} tag --sort=taggerdate | grep -E "nuttx-[0-9]+\.[0-9]+\.[0-9]+" | tail -1 | cut -d'-' -f2-`
   fi

I have some sort of a recollection that taggerdate caused problems, but I can't remember neither can I produce any issue with the given command. So, LGTM.

Correct please do not merge this!
If we create a bug fix for say 10.0.2 you will now start seeing that as the latest version.

@davids5
Yes, it Is another problem.
Would your problem be solved if I pushed the following change?
diff --git a/tools/version.sh b/tools/version.sh
index 5e54eae3b7..51bb4ad220 100755
--- a/tools/version.sh
+++ b/tools/version.sh
@@ -75,7 +75,7 @@ if [ -z ${VERSION} ] ; then

   # If the VERSION does not match X.Y.Z, retrieve version from the tag

-  if [[ ! ${VERSION} =~ ([0-9]+)\.([0-9]+)\.([0-9]+) ]] ; then
+  if [[ ! ${VERSION} =~ nuttx-([0-9]+)\.([0-9]+)\.([0-9]+) ]] ; then
     VERSION=`git -C ${WD} tag --sort=taggerdate | grep -E "nuttx-[0-9]+\.[0-9]+\.[0-9]+" | tail -1 | cut -d'-' -f2-`
   fi

That if part will always be false, VERSION doesn't contain nuttx-.

I have some sort of a recollection that taggerdate caused problems, but I can't remember neither can I produce any issue with the given command. So, LGTM.

Correct please do not merge this!
If we create a bug fix for say 10.0.2 you will now start seeing that as the latest version.

Yeah, I think we saw this with the 9.1.1 patch.  I couldn't reproduce it locally because I didn't create any new tags. So in this case if we do taggerdate on master, it could report an old version with a newer tag.

If we create a bug fix for say 10.0.2 you will now start seeing that as the latest version.

Yes, I am aware of this problem.
I hope that , as the rules for tagging by maintainers, after creating nuttx-10.0.2 tag on 'release/10.0' branch,  they update a  tag of the latest version.
$ git tag 10.1.0  -f -a
Is this operation difficult or complex?

If we create a bug fix for say 10.0.2 you will now start seeing that as the latest version.

Yes, I am aware of this problem.
I hope that , as the rules for tagging by maintainers, after creating nuttx-10.0.2 tag on 'release/10.0' branch, they update a tag of the latest version.
$ git tag nuttx-10.1.0 -f -a
Is this operation difficult or complex?

Why would you update an unrelated tag and force push it, that seems very incorrect.

The following patch fix the way git sorts the tag name:
diff --git a/tools/version.sh b/tools/version.sh
index f0e5efbaaa..beac1d1ab2 100755
--- a/tools/version.sh
+++ b/tools/version.sh
@@ -76,7 +76,7 @@ if [ -z ${VERSION} ] ; then
   # If the VERSION does not match X.Y.Z, retrieve version from the tag

   if [[ ! ${VERSION} =~ ([0-9]+)\.([0-9]+)\.([0-9]+) ]] ; then
-    VERSION=`git -C ${WD} tag --sort=v:refname | grep -E "nuttx-[0-9]+\.[0-9]+\.[0-9]+" | tail -1 | cut -d'-' -f2-`
+    VERSION=`git -C ${WD} -c 'versionsort.suffix=-' tag --sort=v:refname | grep -E "nuttx-[0-9]+\.[0-9]+\.[0-9]+" | tail -1 | cut -d'-' -f2-`
   fi

 fi

Reference: https://stackoverflow.com/a/52680984

Result in

So this makes me wonder if the annotated tag on the master branch at the release point?
With this change

@btashton
On the advice of @gustavonihei , I have changed this PR to add -c 'versionsort.suffix=-'. Will this PR be accepted? If not, I will close it.

@btashton
On the advice of @gustavonihei , I have changed this PR to add -c 'versionsort.suffix=-'. Will this PR be accepted? If not, I will close it.

Probably should have been -RC to filter off the full suffix but that is not too important here. Thanks for making this change!


Not enough Hi-C reads for scaffolding

When I run SALSA, I get the following messages:
bedfile loaded
Starting Iteration 1
bedfile started
bedfile loaded
Loading Hi-C links
Hybrid scaffold graph loaded, nodes = 266 edges = 185
Hi-C implied edges = 0
Starting Iteration 2
bedfile started
bedfile loaded
Starting Iteration 2
WARNING: Not enough Hi-C reads for scaffolding
Loading Hi-C links
Hybrid scaffold graph loaded, nodes = 92 edges = 53
Hi-C implied edges = 0
Starting Iteration 3
bedfile started
bedfile loaded
Starting Iteration 3
WARNING: Not enough Hi-C reads for scaffolding
Loading Hi-C links
Hybrid scaffold graph loaded, nodes = 226 edges = 113
Hi-C implied edges = 0

Our HiC data is quite deep, I get a 7.3GB bam file for each read pair. I followed the Arima Genomics pipeline linked in the Readme to preprocess the reads, this is the head of the sorted bed file that is the input to SALSA (the size of the bed file is 6.1GB):
000000F_0	2651629	2651705	NB500937:320:HGKNFAFXY:1:11101:10000:10373/1	60	-
000000F_0	3368380	3368427	NB500937:320:HGKNFAFXY:1:11101:10000:10373/2	60	+
000000F_0	280823	280899	NB500937:320:HGKNFAFXY:1:11101:10000:14278/1	60	-
000009F_0	361371	361447	NB500937:320:HGKNFAFXY:1:11101:10000:14278/2	60	+
000003F_0	1463548	1463606	NB500937:320:HGKNFAFXY:1:11101:10000:1502/1	60	-
000003F_0	1600628	1600702	NB500937:320:HGKNFAFXY:1:11101:10000:1502/2	60	+
000003F_0	290132	290208	NB500937:320:HGKNFAFXY:1:11101:10000:17747/1	60	-
000021F_0	87027	87102	NB500937:320:HGKNFAFXY:1:11101:10000:17747/2	60	+
000008F_0	449604	449680	NB500937:320:HGKNFAFXY:1:11101:10000:18735/1	60	-
000008F_0	449457	449533	NB500937:320:HGKNFAFXY:1:11101:10000:18735/2	60	+

Is there anything wrong with the formatting? I think I can rule out that we did not sequence deep enough.

I think the warning is being printed too frequently, even if there are good weight links in the data. There aren't very many nodes in your graph (I'd guess your assembly is pretty continuous). The formatting of the file looks OK. Can you check for files named contig_links_scaled_iteration_* in your output, are there edges there that have weight > 1? If so I think it is scaffolding, just outputting the warning incorrectly.


Create PR template

Thought we might want to create one of these like we have for the internal guide. Followed these instructions: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository

@jehchow #sign-off and feel free to add anything to make this better!

@jehchow #sign-off and feel free to add anything to make this better!

Looks good!


Allow Advanced Avatar Settings to Override SDK Parameters

Once an SDK has registered a parameter (either through an SDK or OSC), you cannot drive that parameter through the Advanced Avatar Settings, until the Parameter is deleted from cache.

Is there a reason to enforce the cached values into the game at all?
Because there are other ways to drive parameters, like using animator drivers, or triggers. How OSC worked in VRC is you set the value when receiving a OSC message and that's it.
I have no data to support this since I didn't test, but I think keeping a cache updated by checking every frame will be less performant than just getting the value straight from the source when needed.

Is there a reason to enforce the cached values into the game at all?

It makes it easier to identify which of our parameters are parameters we are currently controller, if we ever do have the scenario when we need to know.

Asking because there are other ways to drive parameters, like using animator drivers, or triggers. How OSC worked in VRC is you set the value upon receiving a OSC message and that's it.

Don't forget that because of the OSC Debug menu, they too also have to cache which parameters are OSC driven and not.

keeping a cache updated by checking every frame will be less performant than just getting the value straight from the source when needed.

The source that we pull data from is that cache, a.k.a.
string parametername = "..."
float value = ParameterManager.Parameters[parametername]

Which is not going to tank your game's FPS. At most, it'll use a couple of KBs of memory.

I'm sorry if I'm being too picky/annoying (feel free to tell me so).

Nah no worries, I strive to design the mod as performant as possible!
However, my current plan is this. There's a method in the ViewManager (the thingy that controls cohtml stuffz) where I can hook into one of the UI Bindings, called CVRAppCallChangeAnimatorParam. Upon this invocation, I can simply remove the cached parameter, which will give all control back to the user, until OSC or the SDK requests control of the parameter again.

The change has been pushed to c02fc30 and seems to function properly.


Mask Blur changes

Mask blur used to blur the outer regions of the mask, but now it blurs the entire mask.
While this change was probably intended, I prefer the old behaviour. Maybe we can get a new node that works like before?

the way the mask is applied shouldn't have changed... I'll check later, what's the difference that you are noticing again? Can you post an example?

As you can see the entire mask is blurred. Unless I remember wrong, only the edges were blurred before?

as I can tell, this is the right behavior :smile:  By edges you mean corners?
60 is a very big value for blur, if you set it to like 20 it should look exactly like before

Hmm, yeah, you're right. Somehow I can't seem to reproduce what I saw before. I must have done something weird... 😛
Sorry about that. I'll close this issue.


No errors are returned when referencing nonexistent files

When using the file URL schema in storage.file.contents.remote to include some file, and this file can't be found, no errors are given.

It seems to be fixed now, thanks!


[GH-#4] Fix build test, changes connect operation

Updating the test to run in-memory mode, allowing us to test the database command without loading the DB file.
Triggers:
Closes #4

Merged


Ignore "Preparing answer..." comments - prefer 👀 emoji

The "Preparing answer..." comment can be quite noisy and spammy. Is there a way to turn it off?
IMO, the best experience is to put the 👀 emoji on the comment.

in the configuration file:
[config]
publish_output_progress=true
set it to false

This can be done in repo level by adding these lines to .pr_agent.toml.
We still would like to implement the eyes emoji on the calling comment.. @idavidov maybe you can help?

@okotek yes, let me take a look on it

#182 added this functionality by default on GitHub. Still need to implement on Gitlab

@never-known-soldier FYI

In my deployment, I've also added the 👀 on the PR description with the GitHub app if automatically handling a command for the pull request. I can contribute that back if there's interest.

@tjwp could you please raise new pr request.


Provide documentation for the load manager and bundles

Ensuring proper traffic distribution in Pulsar is an essential administrative function. We currently have very little documentation on this.

@lucperkins is this done?


Fix #378: mpif90->mpifort,mpirun->mpiexec globally

Avg response time
coverage on master

![Issue Stats][PR response img]
![Codecov branch][coverage]

Summary of changes
Global search and replace on the above strings
Rationale for changes
See #378

Oh, I've made a more complete/thorough fix in the branch I'm working on


UPDATE/DELETE only supports WHERE-clauses on primary keys

Not sure if this belongs here, or noria proper. But it is a blocker for me.
Nov 25 19:33:09.359 INFO listening on port 3306
Nov 25 19:35:25.776 WARN Ignoring DROP TABLE query: "DROP TABLE IF EXISTS piwik_test_table, piwik_test_table_temp"
Nov 25 19:35:25.791 WARN ignoring unsupported query "ALTER TABLE piwik_test_table ADD COLUMN other_value INT DEFAULT 0" and returning empty results
Nov 25 19:35:25.793 INFO Adding ad-hoc query "SELECT * FROM piwik_test_table" to Noria as q_a0d2afefe8ead9ad
thread 'conn-0' panicked at 'UPDATE/DELETE only supports WHERE-clauses on primary keys', src/utils.rs:110:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
thread 'conn-1' panicked at 'called `Result::unwrap()` on an `Err` value: ErrorMessage { msg: "no view or table named \'piwik_test_table_temp\'" }', src/libcore/result.rs:1189:5

This is a restriction of Noria itself, not just of the shim. The issue here is that a DELETE on a non-primary key would be very inefficient, requiring a full scan of all shards of the relevant base table. It may be that the feature is critical enough that that is warranted though.
That said, this is a research prototype, and since this is not a research focus, it is unfortunately unlikely it'll be fixed any time soon. If you want to dig into the code though, I'd be happy to take a look at a PR!

To be honest I am very keen to contribute, and I dove into the code to try. I've never written a SQL query engine, however, so not sure where to learn to create a reasonable PR. I've done a little bit on the frameless library for spark though.

Ah, excellent! I think the tricks is going to be to first dig into this crate for where that error is raised. See if you can make the shim not reject the DELETE and have it instead send it as normal. The delete should make it to node/special/base.rs (from memory), which is what handles the deletes. You may need to modify table.rs so that it sends a DELETE that's not on the primary key to every shard rather than just the "appropriate" shard (since there is no appropriate shard for a non-keyed DELETE).


Add missing character within README.

Opened the repo up as I was curious.
Saw a missing character.
Apologies if this is considered spam or low effort.

I appreciate the attention to detail!


How to training on huge text dataset

What is your question?
I have a ddp program running on 8 nodes, and I need to load a very huge text dataset ( >30 GB) in this task. However, when I loaded it to dataloader, the program stuck. The intuition is to split my dataset into fractions with smaller size, so every time the dataloader only need to load a small fraction of dataset. Does pytorch-lightning have any support for it? Or any suggestion for solving such problem?
What's your environment?
OS: [Linux]
Packaging [pip]
Version [0.10.0]

Can you tell which part of your script is failing? PyTorch datasets do not need to load all of the data at once if implemented properly, perhaps you can share your Dataset implementation?


[SPARK-45007][INFRA] Fix merged pull requests resolution

What changes were proposed in this pull request?

This PR fixes the resolution for merged pull requests. It appears that the user "asfgit" is no longer closing pull requests, but rather the committers are.
Why are the changes needed?

Bugfix, make the merge script re-runnable again if you accidentally abort cherry-pick or change your mind later for backporting.

Closes #42714 from HyukjinKwon/SPARK-45000.

Authored-by: Hyukjin Kwon<EMAIL_ADDRESS>Signed-off-by: Dongjoon Hyun<EMAIL_ADDRESS>Enter a branch name [branch-3.5]:

Was this patch authored or co-authored using generative AI tooling?

cc @dongjoon-hyun @HyukjinKwon @cloud-fan thanks

Thanks @dongjoon-hyun @cloud-fan and @HyukjinKwon for the check


Correct tls1.3-draft19 intermediate secret derivation

Checklist

[x] tests are updated

Description of change
Prior to this change, openssl truncated the label "derived secret" to 7 or 3 bytes by mistake (depending on the host's pointer size). The problem was the usual sizeof(ptr-to-char) vs sizeof(char[]) confusion.
With this change in place, I can handshake with another draft19 implementation. I've regenerated the tests, and corroborated those values with the other implementation.

Note this assumes @snhenson or @mattcaswell can confirm the test case changes - I just reviewed the actual code change itself.

Awesome! Thanks @ctz!
@t-j-h I have verified the test results. All looks good.
Pushed!


clarify output of bootstrap command

The bootstrap command's output should be clearer. Here's an example of the current output:
The current template configuration is:
name: test-bootstrap
repository: git@github.com:mykmelez/test-bootstrap.git
description: A template app bootstrapped with oghliner.
license: Apache-2.0
Would you like to change any of the above configuration values? yes
Project name: test-bootstrap
Repository URL: git@github.com:mykmelez/test-bootstrap.git
Description: A template app bootstrapped with oghliner.

We can definitely collapse the installation part.

Here's a proposed redesign:
Bootstrapping current directory as Oghliner app…

Your app has been bootstrapped!  Just commit the changes and push the commit
to the origin/master branch:

git commit -m"initial version of Oghliner app" --all
git push origin master

Then you can build, offline, and deploy the app using *gulp* commands.

ℹ For more information about building, offlining, and deployment, see:
    https://mozilla.github.io/oghliner/

Notes:

As with #148 and its implementation in #149, checkmarks are green, the informational message (ℹ) is blue, and the Git commands you are instructed to enter are bold gray. Text surrounded by asterisks is bold.
The question you are asked in the beginning of the process (Would you like to change its configuration?) should display the options and capitalize the default one (y/N).
The command should list the files being created, but it shouldn't list the npm dependencies being installed.


HexApi And Lavalink

Please Help About HexApi And Lavalink
Error = "Invalid response received; this may indicate that Lavalink is not running, or is running on a port different to the one you passed to add_node."
Error = "In embed.image.url: Scheme "none" is not supported. Scheme must be one of ('http', 'https')."
Error = "discord.ext.commands.errors.CommandInvokeError: Command raised an exception: KeyError: 'HexApi'"
Please Help.

As mentioned on the first line itself of the README, this repo isn't being maintained any more.
It may contain code which may/may not work. I have kept this repo just for the reference for new bot developers. The bot as whole wont work just some commands may still work though.
The current version of HexBot is private and no longer open sourced.
HexAPI is private API and Lavalink needs to be updated every few days (blame YT) so don't expect it to be working with this super old version.


Crash on type annotations with 'or'

Not good practice necessarily but how would one go about writing this if possible at all?
Basic example:
def func() -> list or dict: return []
Debug from a complex example:
	def next(self, asObj: bool = False) -> numpy.ndarray or list:
                                            ^
------------------------------------------------------------

src/ipo.py:351:45: Compiler crash in AnalyseExpressionsTransform
File 'Nodes.py', line 436, in analyse_expressions: StatListNode(ipo.py:2:0)
File 'Nodes.py', line 436, in analyse_expressions: StatListNode(ipo.py:337:0)
File 'Nodes.py', line 4578, in analyse_expressions: PyClassDefNode(ipo.py:337:0,
    name = 'Calendar')
File 'Nodes.py', line 436, in analyse_expressions: StatListNode(ipo.py:338:1)
File 'Nodes.py', line 5159, in analyse_expressions: SingleAssignmentNode(ipo.py:351:1)
File 'Nodes.py', line 5279, in analyse_types: SingleAssignmentNode(ipo.py:351:1)
File 'ExprNodes.py', line 9225, in analyse_types: PyCFunctionNode(ipo.py:351:1,
    binding = True,
    is_temp = 1,
    pymethdef_cname = '__pyx_mdef_9ipo_8Calendar_7next',
    result_is_used = True,
    use_managed_ref = True)
File 'ExprNodes.py', line 9270, in analyse_default_args: PyCFunctionNode(ipo.py:351:1,
    binding = True,
    is_temp = 1,
    pymethdef_cname = '__pyx_mdef_9ipo_8Calendar_7next',
    result_is_used = True,
    use_managed_ref = True)
File 'ExprNodes.py', line 9358, in analyse_annotation: PyCFunctionNode(ipo.py:351:1,
    binding = True,
    is_temp = 1,
    pymethdef_cname = '__pyx_mdef_9ipo_8Calendar_7next',
    result_is_used = True,
    use_managed_ref = True)
File 'ExprNodes.py', line 11858, in analyse_types: BoolBinopNode(ipo.py:351:54,
    is_temp = True,
    operator = 'or',
    result_is_used = True,
    use_managed_ref = True)
File 'ExprNodes.py', line 664, in analyse_types: BoolBinopResultNode(ipo.py:351:45,
    is_temp = True,
    result_is_used = True,
    use_managed_ref = True)
File 'ExprNodes.py', line 462, in not_implemented: BoolBinopResultNode(ipo.py:351:45,
    is_temp = True,
    result_is_used = True,
    use_managed_ref = True)

Compiler crash traceback from this point on:
  File "/home/misantroop/.local/lib/python3.7/site-packages/Cython/Compiler/ExprNodes.py", line 462, in not_implemented
    (self.__class__.__name__, method_name))
InternalError: Internal compiler error: BoolBinopResultNode.analyse_types not implemented
Traceback (most recent call last):
  File "setup.py", line 13, in <module>
    ext_modules = cythonize("src/*.py", language_level=3),
  File "/home/misantroop/.local/lib/python3.7/site-packages/Cython/Build/Dependencies.py", line 1096, in cythonize
    cythonize_one(*args)
  File "/home/misantroop/.local/lib/python3.7/site-packages/Cython/Build/Dependencies.py", line 1219, in cythonize_one
    raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: src/ipo.py

Use object. There's nothing in common with those two types at a C-level, so Cython can't do any optimisations here. For parameters, you could potentially use fused types.

The correct type to use here would be typing.Union[list, dict] (though Cython wouldn't be able to do anything with it). We shouldn't crash, however.

According to PEP 604, which is being discussed for Python 3.10, the future syntax for this will be list | dict. (But I agree that a crash is not a good way to signal that ;-) )

Looks like that PEP was accepted ( https://github.com/python/peps/commit/6c2e277b088913a6255c2bfd4adacb150c3c8902 ).


hugo server fails to refresh when filename includes NFC characters in MacOS

I'm using hugo inside a Dropbox folder in MacOS.
Dropbox renames a NFD Unicode filename to NFC automatically.
And when the filename includes NFC characters, hugo fails to refresh the content.
$ hugo new posts/ü.md
/Users/ironsand/Dropbox/www/mysite/content/posts/ü.md created
$ hugo server -D --disableFastRender
# edit the file here
# -----------------------
Change detected, rebuilding site.
2021-04-16 18:42:33.639 +0900
Source changed "/Users/ironsand/Dropbox/www/mysite/content/posts/ü.md": WRITE
Total in 144 ms

hugo detects when the file changed, but the change doesn't appear in the browser.
What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.82.0+extended darwin/amd64 BuildDate=unknown

Does this issue reproduce with the latest release?
yes

As a workaround you can ... rename the file.

Related to issue #2203 , and commit 39df772 (I'm working on this issue, first time contribution)


[OCPCLOUD-1362] Add ephemeral storage support

This PR adds ephemeral storage support for Azure. To enable it, users need to set EphemeralStorageLocation value in DiskSettings to 'Local', and optionally define OSDisk caching type.

/approve
This is good to go once the dependency issues are sorted

/test govet

/test govet

/test unit

/retest

FYI, there is no need for UPSTREAM: <carry>: anymore since this repo is not a fork

All looks fine, but is it possible to add a unit test here https://github.com/openshift/machine-api-provider-azure/blob/main/pkg/cloud/azure/services/virtualmachines/virtualmachines_test.go#L50?

/retest

/retest


Feature Request: CNAME records

I love this plugin, but would it be possible to add a feature where the plugin loads a list of CNAME records for my local network zone?
for example, I have a local server with multiple services running in docker including an NGINX reverse proxy on port 80/443 that forwards traffic to the correct port depending on hostname of HTTP/S request.  For this to solution to work multiple hostnames must resolve to the same IP.
In this example the A record would be populated from the omada clients list:
server.omada.home A <IP_ADDRESS>
to get the reverse proxy to route to the correct container, I would need a CNAME (or A) record to be added to the local zone too:
smokeping.omada.home CNAME server.omada.home

Hi. CoreDNS supports a file plugin where you can serve records from a file. See https://coredns.io/plugins/file/

thanks for the quick reply dougbw!  I was just looking at the coredns docs.

Feature is already present


temp lineup with openshift api (projected -> shared)

had to tear down my cluster, so I have not run the e2e's yet @coreydaley
let's see how much those blow up in the interim via PR
otherwise, I'll manually test tomorrow/Thursday
Ideally I'd like, when fixing the operator make deploy, to use latest names for various assets and CRD types

/test unit

/test verify

yeah the daemonset deployment is not working here either
need to debug

got it sorted pretty quick .... just some tweaks to the new deploy.sh script ... tests running locally with the image from this repo
let's see how CI does

/hold
need namespace tweaks for CI

/hold cancel

/test all

install failed
/retest

more install / terraform failures
will wait a bit before retesting

/retest

OK got green CI @coreydaley @adambkaplan  .... unless you all want more tweaks to this, if we can lgtm it and get it to merge, we can retry the rehearsals in https://github.com/openshift/release/pull/21044
I believe those rehearsals should pass after this merges

/lgtm


Mobile URL handling

This is a good improvement, really appreciate the work on it.  Before I have my team start doing work on this, has anyone looked at Jitsi URL registration handling?  I know on iOS it's just org.jitsi.meet:// vs https:// to open directly in the Jitsi app.

@jespino / @aaronrothschild on above

Thanks @jeff-mccoy flagging this and for your interest to work on this plugin :)

@jeff-mccoy really cool improvement, that works on android too. My concern is about handling it with other clients (for example text based clients, or after the plugin is disabled). We can mitigate that registering the protocol in the desktop app, and probably adding a config flag to enable/disable this feature. This is only going to be part of the slack attachment alternative view, not the regular post view, so is not going to affect the webapp/desktop app while the plugin is loaded.

That seems reasonable, we have a little over 50k users across a few different Mattermost instances with Jitsi deployed in K8s per-env, so we can generate plenty of test data for this as well.

@jeff-mccoy great, feel free to send a PR with a initial proposal and we can iterate over that.

Hi @jeff-mccoy ! Have you looked into this? Are you planning to send a PR?
If you are not able, please let me know, so I can make this a help wanted ticket. :smile:

Hi @jeff-mccoy ! Have you looked into this? Are you planning to send a PR?
If you are not able, please let me know, so I can make this a help wanted ticket. :smile:


Always error when cluster annotations in mapbox (The error also occurs in the swift + mapbox example)

There is a serious error that disables the library for mapbox. It also occurs in the swift (Xcode 11.1) example provided. I attach a video. When you zoom in to see the annotations and zoom out quickly, the library stops clustering the annotations and they are grouped in a strange way.

Please help. Thank you

Hello. I commented on this Bug a week ago. Is this library unsupported?


[Mosaic GPU] Add CUPTI profiler alongside events-based implementation

Thanks, I applied the patch and moved CUPTI-specific tests to a separate target which I marked with tags = ["noasan"].


Add Example File Server

In-Memory Static File Server, Optimized For Low Latency, Optimal For Single Page Applications.

This method is not optimal for large files, because it does not use streaming.


grid visual artifact within modal when width is 100%

I have a modal which contains a grid which should be 100% of the modal width. Upon initial loading of the modal, there is a visual artifact of the grid beyond the boundary of my modal. If I re-size my browser window, the artifact will disappear and the grid will "snap" in place where it should be and start obeying the 100% width boundary of my modal window.
This only seems to happen when loading a grid in a modal. My primary grid on the main page is set to width: 100% and has no issue.
Initial load:

After resizing:

This is the CSS I have for the grid:

Hey actually this issue is part of ui-view-port directive, as a part of workaround replace ui-grid div with following code.

Use following code on your controller.
  $scope.getTableStyle= function() {
                        return {
                           width: "100%",
                           height:"100%"
  };

};

Hey actually this issue is part of ui-view-port directive, as a part of workaround replace ui-grid div with following code.
<div  ui-grid="gridOpt" class="grid" style="width:100%" ng-style="getTableStyle()" <div>
Use following code on your controller.

$scope.getTableStyle= function() {
return {
width: "100%",
height:"100%"
};
};

I got the same issue. And @lifinanalytics, your workaround doesn't work for me. If the parent container's width has been set by %, Grid cannot get the correct width of parent container's width. When resizing occurs, because of parent container won't be rendered again, Grid can get correct width.
Any other solution or ETA?
Thanks.

Do this after setting data, as a workaround.
window.dispatchEvent(new Event('resize'));

@tony0918 it worked very well for me ,actually was facing issue on displaying ui-grid under angular ui-tabs where i was  reloading the grid data on some ui events but on every time the data refresh happens grid used to go out of the container specified, after this fix and it works well even on window resize.
So coming to your issue  with % size it is required to have parent width set before child can render , So there is no way you can render the table without setting parent width and height. All i suggest you to work on your source code somehow to render the parent before rendering ui-grid.
@httpete your solution is not consistent , even though you trigger resize event in some cases it doesn't work like mine in where am displaying grid in multiple tabs where ui-grid resize event won't get triggered due out of view port.

Thanks @lifinanalytics. Could you please share me some code to manage the rendering order?

        /* This is the grid hack to fix the bad layout in all browsers */
        setTimeout(function(){
            var evt = document.createEvent('UIEvents');
            evt.initUIEvent('resize', true, false,window,0);
            window.dispatchEvent(evt);
        }, 100);

If someone could throw together a quick plunker for this that would make it a lot easier to provide a fix.

OK I made a plunker: http://plnkr.co/edit/PLqG0GeD1iAredRARp8K?p=preview

The problem here is that for determining the grid width, gridUtil is detecting that when the grid is initialized, it has an offsetWidth of 0, so it creates a "fake" (cloned) element that it attaches to the document with visibility: hidden in order to measure it.
This causes a problem because with width: 100% when attached to the document body the grid will just fill up the whole space. THEN when the real grid is in the modal it takes up way more space than it should.
The "detached/hidden element" measurement probably needs to be adjusted to account for this case.

@longshot5112, et al. Can you try again with latest unstable?

No further comment for over a month, solution provided that probably resolves the issue.  Closing, please re-raise if there is a reliable recreate or more information.


Session time out explain

As in this doc , it says there was hard coded time out for 10 hours in previous release. But we don't need such statement now because we are already in 5.5.0 and in documentation better not to mention the previous version number. We will try to explain about current version detail against all previous versions. Went ?
https://docs.wso2.com/display/IS550/Configuring+Session+Timeout

Thank you for your contribution!
We are closing this issue since it has not been prioritized for a long time. Chances are that it has already been solved in more recent versions. If not, we will be re-evaluating this when it becomes a priority.


Add retry and DLQ support for the Kafka binder

Fixes #498

Honour the retry settings from ConsumerProperties;
Add an additional  enableDlq option in KafkaConsumerProperties that enables forwarding failed messages to a DLQ topic.

Rebased, merged as fa42b62074bc37d196586122fed8f65639263eb7


test the running time of loop version of qr_conditions

The original qr_conditions is
function qr_conditions(A, x)
  return vcat(
    vec(UpperTriangular(Q' * Q) + LowerTriangular(R) - I - Diagonal(R)),
    vec(Q * R - A),
  )
end

However, the test shows that its much slower than the following for loop version
function qr_conditions_dev(A, x)
  (; Q, R) = x
  m, n = size(A, 1), size(A, 2)
  res_A = copy(A)
  res_R = Matrix{eltype(A)}(I, n, n)
  for i in 1:m
    for j in 1:n
      for k in 1:n
        res_A[i, j] -= Q[i, k] * R[k, j]
        if i == 1 && j < k
          res_R[k, j] += R[k, j]
        end
        if j <= k
          res_R[j, k] -= Q[i, k] * Q[i, j]
        end
      end
    end
  end
  return vcat(vec(res_A), vec(res_R))
end

In terms of size(5, 3) matrices, that former one is
2.311390 seconds (5.85 M allocations: 266.937 MiB, 6.47% gc time, 99.81% compilation time)

while the latter one is
0.023781 seconds (2.46 k allocations: 131.417 KiB, 98.84% compilation time)

The reason is that the fomer one access each elements of the matrices for many times, which is redundant.
So, we consider rewrite these conditions. But we currently use Zygote as our AD system, which doesn't support in-place operation. And that's the problem to be solved.

A few comments:

How did you time the functions? Post the script here. Make sure to use BenchmarkTools.
You can avoid the vcat in your implementation by allocating a single result vector and making views out of them then reshape each view into a matrix. Something like this reshape(@view(res[1:m*n]), m, n)'. This will share the memory with res. You should be able to have a single allocation only when you use BenchmarkTools.

Codecov Report

Merging #11 (c7ee211) into main (69313bd) will decrease coverage by 20.12%.
The diff coverage is 0.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff             @@
##             main      #11       +/-   ##
===========================================
- Coverage   98.97%   78.86%   -20.12%
===========================================
  Files           1        1
  Lines          98      123       +25
===========================================
  Hits           97       97
- Misses          1       26       +25

Impacted Files
Coverage Δ

src/DifferentiableFactorizations.jl
78.86% <0.00%> (-20.12%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Also please turn the notebook into a test file in the tests folder.

The code you benchmark should always be inside a function. Also try multiple matrix sizes.

Yeah, this time I only test the function.
Besides I tried different sizes, and found that our for loop implementation is faster than the matrix multiplication version when the size is small,

and slower in the cases of large matrices.

These are two typical tests and there are some more tests in the notebook script.
Do you think it's reasonable?


Add text streaming for responce

Thanks for the suggestion. It will be added soon.
However, one downside to streaming is that the agents won't be able to keep track of their history when streaming is turned on. The user will be responsible for storing chat history, which isn't a big deal but something to be aware of.

Thanks