Re: Avoid undefined behavior with msvc compiler (src/include/port/pg_bitutils.h)

On Sat, Jul 29, 2023 at 7:37 PM Ranier Vilela wrote: > > Hi, > > The pg_leftmost_one_pos32 function with msvc compiler, > relies on Assert to guarantee the correct result. > > But msvc documentation [1] says clearly that > undefined behavior can occur. It seems that we should have "Assert(word !=

Re: UUID v7

On 10 Jul 2023, at 21:50, Peter Eisentraut wrote:I suggest we keep this thread to v7, which has pretty straightforward semantics for PostgreSQL.  v8 by definition has many possible implementations, so you're going to have to make pretty strong arguments that your

Re: Avoid undefined behavior with msvc compiler (src/include/port/pg_bitutils.h)

John Naylor writes: > It seems that we should have "Assert(word != 0);" at the top, which matches > the other platforms anyway, so I'll add that. That's basically equivalent to the existing Assert(non_zero). I think it'd be okay to drop that one and instead have the same Assert condition as other

Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"

Hello! On 26.07.2023 07:06, Thomas Munro wrote: New patches attached. Are they getting better? It seems to me that it is worth focusing efforts on the second part of the patch, as the most in demand. And try to commit it first. And seems there is a way to simplify it by adding a parameter

Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"

Sorry, attached the wrong version of the file. Here is the right one. Sincerely yours, -- Anton A. Melnikov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company alg_level_up.pdf Description: Adobe PDF document

Re: pg_rewind fails with in-place tablespace

On Fri, Jul 28, 2023 at 04:54:56PM +0900, Michael Paquier wrote: > I am finishing with the attached. Thoughts? Applied this one as bf22792 on HEAD, without a backpatch as in-place tablespaces are around for developers. If there are opinions in favor of a backpatch, feel free of course. -- Michae

Re: Support to define custom wait events for extensions

On Fri, Jul 28, 2023 at 12:43:36PM +0530, Bharath Rupireddy wrote: > 1. > - so an LWLock wait event might be reported as > - just extension rather than the > - extension-assigned name. > + if the extension's library is not loaded; so a custom wait event might > + be reported as

Re: New PostgreSQL Contributors

Bingo work! Thanks to all the contributors! Best, Dianjin Wang On Fri, Jul 28, 2023 at 11:29 PM Christoph Berg wrote: > The PostgreSQL contributors team has been looking over the community > activity and, over the first half of this year, has been recognizing > new contributors to be listed on

Adding a LogicalRepWorker type field

Hi hackers, BACKGROUND: The logical replication has different worker "types" (e.g. apply leader, apply parallel, tablesync). They all use a common structure called LogicalRepWorker, but at times it is necessary to know what "type" of worker a given LogicalRepWorker represents. Once, there were

Re: 回复：pg_rewind fails with in-place tablespace

On Mon, Jul 31, 2023 at 10:07:44AM +0800, Rui Zhao wrote: > However, I would like to bring your attention to another issue: > pg_upgrade fails with in-place tablespace. Another issue is still > waiting for approved. I have tested all the tools in src/bin with > in-place tablespace, and I believe th

Re: New PostgreSQL Contributors

Congrats! On Fri, Jul 28, 2023 at 10:29 PM Christoph Berg wrote: > The PostgreSQL contributors team has been looking over the community > activity and, over the first half of this year, has been recognizing > new contributors to be listed on > > https://www.postgresql.org/community/contributors/

Re: New PostgreSQL Contributors

On Fri, Jul 28, 2023 at 8:59 PM Christoph Berg wrote: > The PostgreSQL contributors team has been looking over the community > activity and, over the first half of this year, has been recognizing > new contributors to be listed on > > https://www.postgresql.org/community/contributors/ > > New Pos

Re: New PostgreSQL Contributors

Hi, On Fri, Jul 28, 2023 at 8:59 PM Christoph Berg wrote: > The PostgreSQL contributors team has been looking over the community > activity and, over the first half of this year, has been recognizing > new contributors to be listed on > > https://www.postgresql.org/community/contributors/ > > Ne

Re: add timing information to pg_upgrade

On Sun, Jul 30, 2023 at 2:44 AM Nathan Bossart wrote: > > On Sat, Jul 29, 2023 at 12:17:40PM +0530, Bharath Rupireddy wrote: > > While on this, I noticed a thing unrelated to your patch that there's > > no space between the longest status message of size 60 bytes and ok - > > 'Checking for incompa

Re: Support to define custom wait events for extensions

On Mon, Jul 31, 2023 at 6:40 AM Michael Paquier wrote: > > You are right that I am making things inconsistent here. Having a > behavior close to the existing LWLock and use "extension" when the > event cannot be found makes the most sense. I have been a bit > confused with the wording though of

Re: Support to define custom wait events for extensions

On 2023-07-31 10:10, Michael Paquier wrote: Attached is a new version. Thanks for all the improvements. I have some comments for v10. (1) - Extensions can add LWLock types to the list shown in - . In some cases, the name + Extensions can add Extension and + LWLo

Re: Support to define custom wait events for extensions

On Mon, Jul 31, 2023 at 12:07:40PM +0530, Bharath Rupireddy wrote: > We're not giving up and returning an unknown state in the v10 patch > unlike v9, no? This comment needs to change. Right. Better to be consistent with lwlock.c here. >> No, it cannot because we need the custom wait event string