Re: [PATCH] pg_convert improvement

2023-11-27 Thread Yurii Rashkovskii
Hi Bertrand, > Did some minor changes in the attached: > > - Started the multi-line comment with an upper case and finished > it with a "." and re-worded a bit. > - Ran pgindent > > What do you think about the attached? > It looks great! > > Also, might be good to create a CF entry [1] so

Re: [PATCH] pg_convert improvement

2023-11-24 Thread Yurii Rashkovskii
Hi Bertrand, On Fri, Nov 24, 2023 at 6:26 AM Drouvot, Bertrand < bertranddrouvot...@gmail.com> wrote: > > The patch is pretty straightforward, I just have one remark: > > + /* if no actual conversion happened, return the original string */ > + /* (we are checking pointers to strings

[PATCH] pg_convert improvement

2023-11-24 Thread Yurii Rashkovskii
Hi, I propose a patch that ensures `pg_convert` doesn't allocate and copy data when no conversion is done. It is an unnecessary overhead, especially when such conversions are done frequently and for large values. I've tried measuring the performance impact, and the patched version has a small

Re: SET ROLE documentation improvement

2023-09-26 Thread Yurii Rashkovskii
On Mon, Sep 25, 2023 at 3:09 PM Nathan Bossart wrote: > On Fri, Sep 15, 2023 at 02:36:16PM -0700, Yurii Rashkovskii wrote: > > On Fri, Sep 15, 2023 at 1:47 PM Nathan Bossart > > > wrote: > >> I think another issue is that the aforementioned note doesn't mention >

Re: SET ROLE documentation improvement

2023-09-15 Thread Yurii Rashkovskii
On Fri, Sep 15, 2023 at 1:47 PM Nathan Bossart wrote: > On Fri, Sep 15, 2023 at 11:26:16AM -0700, Yurii Rashkovskii wrote: > > I believe SET ROLE documentation makes a slightly incomplete statement > > about what happens when a superuser uses SET ROLE. > > > > The doc

Re: ALTER ROLE documentation improvement

2023-09-15 Thread Yurii Rashkovskii
On Fri, Sep 15, 2023 at 1:53 PM Nathan Bossart wrote: > On Fri, Sep 15, 2023 at 11:46:35AM -0700, Yurii Rashkovskii wrote: > > It appears that 16.0 improved some of the checks in ALTER ROLE. > Previously, > > it was possible to do the following (assuming current_user is a

ALTER ROLE documentation improvement

2023-09-15 Thread Yurii Rashkovskii
Hi, It appears that 16.0 improved some of the checks in ALTER ROLE. Previously, it was possible to do the following (assuming current_user is a bootstrap user): ``` ALTER ROLE current_user NOSUPERUSER ``` As of 16.0, this produces an error: ``` ERROR: permission denied to alter role DETAIL:

SET ROLE documentation improvement

2023-09-15 Thread Yurii Rashkovskii
Hi, I believe SET ROLE documentation makes a slightly incomplete statement about what happens when a superuser uses SET ROLE. The documentation reading suggests that the superuser would lose all their privileges. However, they still retain the ability to use `SET ROLE` again. The attached patch

Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name

2023-07-04 Thread Yurii Rashkovskii
Nathan, On Mon, Jul 3, 2023 at 8:12 PM Nathan Bossart wrote: > On Mon, Jul 03, 2023 at 06:00:12PM -0700, Yurii Rashkovskii wrote: > > Great, thank you! The reason I was leaving the other constant in place to > > make upgrading extensions trivial (so that they don't

Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name

2023-07-03 Thread Yurii Rashkovskii
Nathan, On Mon, Jul 3, 2023 at 3:08 PM Nathan Bossart wrote: > On Sun, Jul 02, 2023 at 04:37:52PM -0700, Yurii Rashkovskii wrote: > > Thank you for revising the patch. While this is relatively minor, I think > > it should be set to MAXPGPATH directly to clarify their relationship

Re: Size vs size_t or, um, PgSize?

2023-07-03 Thread Yurii Rashkovskii
Daniel, On Mon, Jul 3, 2023 at 12:20 PM Daniel Gustafsson wrote: > > On 3 Jul 2023, at 21:14, Yurii Rashkovskii wrote: > > > That being said, going ahead with the global renaming of Size to size_t > will mostly eliminate this clash in, say, five years when old versions will &

Re: Size vs size_t or, um, PgSize?

2023-07-03 Thread Yurii Rashkovskii
Hi Thomas, On Mon, Jul 3, 2023 at 12:03 PM Thomas Munro wrote: > On Tue, Jul 4, 2023 at 6:46 AM Daniel Gustafsson wrote: > > > On 3 Jul 2023, at 20:32, Yurii Rashkovskii wrote: > > > If there's a willingness to try this out, I am happy to prepare a > patch. > &g

Size vs size_t or, um, PgSize?

2023-07-03 Thread Yurii Rashkovskii
Hi, I've run into an issue of a name clash with system libraries. Specifically, the `Size` type seems to be just an alias for `size_t` and, at least on macOS, it clashes with the core SDK, as it is also defined by MacTypes.h, which is used by some of the libraries one may want to use from within

Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name

2023-07-02 Thread Yurii Rashkovskii
Hi Nathan, On Fri, Jun 30, 2023 at 2:39 PM Nathan Bossart wrote: > > In v4, I've introduced a new BGW_LIBLEN macro and set it to the default > value of MAXPGPATH (1024). This way, the value can live in bgworker.h like > the other BGW_* macros do. Plus, this should make the assertion that >

Re: [PATCH] Allow Postgres to pick an unused port to listen

2023-05-11 Thread Yurii Rashkovskii
On Thu, May 11, 2023 at 10:36 AM Alvaro Herrera wrote: > On 2023-May-11, Yurii Rashkovskii wrote: > > > ``` > > 127.0.0.1=5432 ::1=54321 > > ``` > > > > Basically, a space-delimited set of address/port pairs (delimited by `=` > to > > allow IPv6 ad

Re: [PATCH] Allow Postgres to pick an unused port to listen

2023-05-11 Thread Yurii Rashkovskii
Alvaro, Tom, On Mon, May 8, 2023 at 4:49 PM Tom Lane wrote: > Alvaro Herrera writes: > > This made me wonder if storing the unadorned port number is really the > > best way. Suppose we did extend things so that we listen on different > > ports on different interfaces; how would this scheme

Re: [PATCH] Allow Postgres to pick an unused port to listen

2023-05-11 Thread Yurii Rashkovskii
Hi Denis, Great catch. I've amended the patch to fix this issue with the documentation (V3). On Tue, May 9, 2023 at 2:25 PM Denis Laxalde wrote: > The documentation fails to build for me: > > $ ninja docs > [1/2] Generating doc/src/sgml/postgres-full.xml with a custom command > FAILED:

Re: [PATCH] Allow Postgres to pick an unused port to listen

2023-05-07 Thread Yurii Rashkovskii
Hi Cary, Thank you so much for the review. It's very valuable, and you caught an important issue with it that I somehow missed (not updating the .pid file with the selected port number). I'm not sure how it escaped me (perhaps I was focusing too much on the log file to validate the behaviour).

Re: [PATCH] Support % wildcard in extension upgrade filenames

2023-05-02 Thread Yurii Rashkovskii
On Mon, May 1, 2023 at 11:05 PM Eric Ridge wrote: > > > We expect the .so's own minor version number to suffice for that, > > but I realize that that might not be the most user-friendly answer. > > One of my desires is that the on-disk .so's filename be associated with > the pg_extension entry

Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name

2023-04-24 Thread Yurii Rashkovskii
You're absolutely right. Here's v3. On Mon, Apr 24, 2023 at 6:30 PM Aleksander Alekseev < aleksan...@timescale.com> wrote: > Hi, > > > This is a very good catch and a suggestion. I've slightly reworked the > patch, and I also made this static assertion to have less indirection and, > therefore,

Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name

2023-04-24 Thread Yurii Rashkovskii
Aleksander, On Mon, Apr 24, 2023 at 1:01 PM Aleksander Alekseev < aleksan...@timescale.com> wrote: > > The patch is backwards-compatible and ensures that bgw_library_name > stays *at least* as long as BGW_MAXLEN. Existing external code that uses > BGW_MAXLEN is a length boundary (for example, in

Re: [PATCH] Allow Postgres to pick an unused port to listen

2023-04-20 Thread Yurii Rashkovskii
Aleksander, On Thu, Apr 20, 2023 at 1:22 PM Aleksander Alekseev < aleksan...@timescale.com> wrote: > Hi, > > > Also, I don't think there's a case for distributed systems here because > we're only managing a single computer's resource: the allocation of local > ports. > > I don't suggest building

Re: [PATCH] Allow Postgres to pick an unused port to listen

2023-04-19 Thread Yurii Rashkovskii
Alexander, On Wed, Apr 19, 2023 at 11:44 PM Aleksander Alekseev < aleksan...@timescale.com> wrote: > Hi, > > Here are my two cents. > > > > I would like to suggest a patch against master (although it may be > worth > > > backporting it) that makes it possible to listen on any unused port. > > >

Re: [PATCH] Allow Postgres to pick an unused port to listen

2023-04-18 Thread Yurii Rashkovskii
Stephen, > You could just drop another file into the data directory that just > contains > > the port number ($PGDATA/port). However, if we ever do multiple ports, > that > > would still require a change in the format of that file, so I don't know > if > > that's actually better than a). > I

Re: [PATCH] Allow Postgres to pick an unused port to listen

2023-04-12 Thread Yurii Rashkovskii
Hi Tom, On Thu, Apr 13, 2023 at 9:17 AM Tom Lane wrote: > Yurii Rashkovskii writes: > > Thank you all for the feedback. It's quite useful. I think it is > important > > to separate this into two concerns: > > > 1. Letting Postgres pick an unused port. > >

Re: [PATCH] Allow Postgres to pick an unused port to listen

2023-04-12 Thread Yurii Rashkovskii
Tom, Robert, Greg, Andrew, On Thu, Apr 13, 2023 at 12:56 AM Tom Lane wrote: > Robert Haas writes: > > On Wed, Apr 12, 2023 at 1:31 PM Greg Stark wrote: > >> I don't object to using the pid file as the mechanism -- but it is a > >> bit of an awkward UI for shell scripting. I imagine it would

Re: [PATCH] Allow Postgres to pick an unused port to listen

2023-04-11 Thread Yurii Rashkovskii
Hi Robert, On Tue, Apr 11, 2023 at 12:54 AM Robert Haas wrote: > On Fri, Apr 7, 2023 at 5:34 PM Yurii Rashkovskii wrote: > > I'm trying to understand what's wrong with reading port from the pid > file (if Postgres writes information there, it's surely so that somebody > can rea

Re: [PATCH] Allow Postgres to pick an unused port to listen

2023-04-07 Thread Yurii Rashkovskii
Hi Andrew, On Fri, Apr 7, 2023, 7:07 p.m. Andrew Dunstan wrote: > > On 2023-03-29 We 07:55, Tom Lane wrote: > > Yurii Rashkovskii writes: > > I would like to suggest a patch against master (although it may be worth > backporting it) that makes it possible to listen on a

Re: [PATCH] Allow Postgres to pick an unused port to listen

2023-04-06 Thread Yurii Rashkovskii
Hi Tom, On Wed, Mar 29, 2023 at 6:55 PM Tom Lane wrote: > Yurii Rashkovskii writes: > > I would like to suggest a patch against master (although it may be worth > > backporting it) that makes it possible to listen on any unused port. > > I think this is a bad

Re: [PATCH] Support % wildcard in extension upgrade filenames

2023-04-02 Thread Yurii Rashkovskii
I want to chime in on the issue of lower-number releases that are released after higher-number releases. The way I see this particular problem is that we always put upgrade SQL files in release "packages," and they obviously become static resources. While I [intentionally] overlook some details

Re: [PATCH] Allow Postgres to pick an unused port to listen

2023-03-29 Thread Yurii Rashkovskii
Hi Tom, Thank you for your feedback. Below are my comments. On Wed, Mar 29, 2023 at 6:55 PM Tom Lane wrote: > Yurii Rashkovskii writes: > > I would like to suggest a patch against master (although it may be worth > > backporting it) that makes it possible to listen on any unu

[PATCH] Allow Postgres to pick an unused port to listen

2023-03-28 Thread Yurii Rashkovskii
Hi, I would like to suggest a patch against master (although it may be worth backporting it) that makes it possible to listen on any unused port. The main motivation is running colocated instances of Postgres (such as test benches) without having to coordinate port allocation in an unnecessarily

Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name

2023-03-13 Thread Yurii Rashkovskii
for little to no benefit. On Mon, Mar 13, 2023 at 10:35 AM Nathan Bossart wrote: > On Mon, Mar 13, 2023 at 07:57:47AM -0700, Yurii Rashkovskii wrote: > > However, there are use cases where [potentially] longer names are > > expected/desired; for example, test benches (where li

[PATCH] Extend the length of BackgroundWorker.bgw_library_name

2023-03-13 Thread Yurii Rashkovskii
Hi, I want to suggest a patch against master (it may also be worth backporting it) that makes it possible to use longer filenames (such as those with absolute paths) in `BackgroundWorker.bgw_library_name`. `BackgroundWorker.bgw_library_name` currently allows names up to BGW_MAXLEN-1, which is