Re: Re[2]: [PATCH] allow pg_current_logfile() execution under pg_monitor role
On Wed, Feb 14, 2024, 19:45 Tom Lane wrote: > "Pavlo Golub" writes: > > Oh, thanks! I forgot, indeed, to update docs and catalog version! My > > bad! > > Docs, yes, but don't include catversion bumps in submitted patches. > They'll just lead to merge problems when somebody else changes the > current catversion. We rely on the committer to remember to do this > (which is an imperfect system, but...) > Thanks for the clarification. > regards, tom lane >
Re[2]: [PATCH] allow pg_current_logfile() execution under pg_monitor role
On Mon, Feb 12, 2024 at 09:49:45AM -0600, Nathan Bossart wrote: Okay. I'll plan on committing this in the next few days. Here is what I have staged for commit. Oh, thanks! I forgot, indeed, to update docs and catalog version! My bad! In my defense, I was trying to find tests but I missed regress/sql/misc_functions.sql somehow. Now I will know. Thanks again! Best regards, Pavlo Golub
Re[2]: [PATCH] allow pg_current_logfile() execution under pg_monitor role
Are there any other functions that pg_monitor ought to have privileges for? Not that I'm aware of at the moment. This one was found by chance. Kind regards, Pavlo Golub
[PATCH] allow pg_current_logfile() execution under pg_monitor role
Hello, The patch attached fixes an oversight/inconsistency of disallowing the pg_monitor system role to execute pg_current_logfile([text]). pgwatch3=# create user joe; CREATE ROLE pgwatch3=# set role joe; SET pgwatch3=> select pg_current_logfile(); ERROR: permission denied for function pg_current_logfile pgwatch3=> reset role; RESET pgwatch3=# grant pg_monitor to joe; GRANT ROLE pgwatch3=# set role joe; SET pgwatch3=> select pg_current_logfile(); ERROR: permission denied for function pg_current_logfile pgwatch3=> select * FROM pg_ls_logdir(); name | size | modification --+--+ postgresql-2024-02-08_130906.log | 652 | 2024-02-08 13:10:04+01 (5 rows) Best regards, Pavlo Golub 0001-allow-pg_current_logfile-execution-under-pg_monitor-.patch Description: Binary data
GSoC 2024
Greetings -hackers and -mentors, Google Summer of Code is back for 2024! Please review this announcement blog post: https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html And please make yourself familiar with the GSoC 2024 timeline: https://developers.google.com/open-source/gsoc/timeline Now is the time to work on getting together a set of projects we'd like to have GSoC students work on over the summer. Like last year, we must have a good set of projects for students to choose from before the deadline for mentoring organizations. The deadline for Mentoring organizations to apply is February 6. The list of accepted organizations will be published on February 21. Unsurprisingly, we'll need to have an Ideas page again, so I've gone ahead and created one (copying last year's): https://wiki.postgresql.org/wiki/GSoC_2024 Google discusses what makes a good "Ideas" list here: https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html All the entries are marked with '2023' to indicate they were pulled from last year. If the project from last year is still relevant, please update it to '2024'. Make sure to revise all the information (in particular, list yourself as a mentor and remove the other mentors, as appropriate). Please also update the project's scope to be reasonable for the time students are asked. Having at least two mentors per project is an excellent idea to decrease the load. Please consider listing yourself as a co-mentor for projects with only one mentor listed. The program's goals are not limited solely to code writing. One of the goals is to inspire new developers to begin participating in open-source communities and to help open-source projects identify and bring in new developers. New entries are welcome and encouraged; note them as '2024' when you add them. Projects from last year that were worked on but had significant follow-on work to be completed are also welcome - update the description appropriately and mark it as being for '2024'. When we get closer to submitting our application, I'll clean out the '2023' entries that have yet to receive any updates. Also, if any projects are no longer appropriate (maybe they were completed, for example, and no longer need work), please feel free to remove them. We may have missed some updates where a GSoC project was achieved independently of GSoC. As a reminder, each idea on the page should be in the format that the other entries are in and should include: 1 Project Description 2 Skills needed 3 Difficulty Level 4 Project Size 5 Potential Mentors 6 Expected Outcomes 7 References As with last year, please consider PostgreSQL to be an "Umbrella" project, and anything that would be regarded as a "PostgreSQL Family" per the News/Announce policy [1] is likely to be acceptable as a PostgreSQL GSoC project. In other words, if you're a contributor or developer on WAL-G, barman, pgBackRest, pgwatch, pgagroal, pgexporter, pgmoneta, pgpool, pgbouncer, the PostgreSQL website (pgweb), the PgEU/PgUS website code (pgeu-system), pgAdmin4, DBeaver, HeidiSQL, pldebugger, pspg, the PG RPMs (pgrpms), the JDBC driver, the ODBC driver, or any of the many other PG Family projects, please feel free to add a project for consideration! Let's have another great year of GSoC with PostgreSQL! PGForce be with you! Best regards, Pavlo Golub, on behalf of PostgreSQL GSoC Admins [1]: https://www.postgresql.org/about/policies/news-and-events/
Re: psql's EDITOR behavior on Windows
On Wed, Dec 18, 2019 at 4:11 PM Tom Lane wrote: > > I wrote: > > Pavlo Golub writes: > >> I cannot find the reason why EDITOR value on Windows is quoted. > > > The comment you quoted explains it: apparently people expect > > paths-with-spaces to work in that value without any manual quoting. > > Actually, after digging in the git history and archives, the current > behavior seems to trace back to a discussion on pgsql-hackers on > 2004-11-15. The thread linkage in the archives seems rather incomplete, > but it boiled down to this: > > https://www.postgresql.org/message-id/9045.1100539151%40sss.pgh.pa.us > > ie, the argument that people could handle space-containing paths by > putting double quotes into the environment variable's value is just wrong. > Possibly Microsoft fixed that in the fifteen years since, but I'd want to > see some proof. Interesting. Thanks. I'll prepare a patch showing the case. > > regards, tom lane
psql's EDITOR behavior on Windows
Hello.
I cannot find the reason why EDITOR value on Windows is quoted. It
should not be. One may force quote env var if he wants to.
Right now, for example, one cannot use sublime, since to use it in a
proper way you should
SET EDITOR="C:\Program Files\Sublime\subl.exe" --wait
The problem can be solved by introducing PSQL_EDITOR_ARGS env var, but
just not quoting EDITOR command on Windows will work too.
psql\command.c:
static bool
editFile(const char *fname, int lineno)
{
...
/*
* On Unix the EDITOR value should *not* be quoted, since it might include
* switches, eg, EDITOR="pico -t"; it's up to the user to put quotes in it
* if necessary. But this policy is not very workable on Windows, due to
* severe brain damage in their command shell plus the fact that standard
* program paths include spaces.
*/
...
if (lineno > 0)
sys = psprintf("\"%s\" %s%d \"%s\"",
editorName, editor_lineno_arg, lineno, fname);
else
sys = psprintf("\"%s\" \"%s\"",
editorName, fname);
...
}
Re: Commitfest 2019-07, the first of five* for PostgreSQL 13
Greetings, Robert. You wrote 2019-08-01, 07:30: > On Thu, Aug 1, 2019 at 12:10 AM Thomas Munro wrote: > Hi all, > CF1 officially ends in about 8 hours, when August arrives on the > volcanic islands of Howard and Baker, according to CURRENT_TIMESTAMP > AT TIME ZONE '+12'. I'll probably mark it closed at least 8 hours > later than that because I'll be asleep. Anything that is waiting on > author and hasn't had any recent communication, I'm planning to mark > as returned with feedback. Anything that is clearly making good > progress but isn't yet ready for committer, I'm going to move to the > next CF. If you're a patch owner or reviewer and you can help move > your patches in the right direction, or have other feedback on the > appropriate state for any or all patches, then please speak up, I'd > really appreciate it. In all cases please feel free to change the > state or complain if you think I or someone else got it wrong; if I > recall correctly there is a way to get from "returned" to "moved to > next CF", perhaps via an intermediate state. Thanks! > As a normal lurker on hackers, it has been nice seeing the weekly updates. > Thanks for those. Yeap! Great job! Please, do the same for the rest of our lifes. :) > -- Rob > > -- > Thomas Munro > https://urldefense.proofpoint.com/v2/url?u=https-3A__enterprisedb.com=DwIBaQ=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw=51tHa8Iv1xJ6zHVF3Sip1AlXYA5E-AYBfRUwz6SDvrs=zzunjUZWnsNXR62PvYhl6kzf6VG6mHBPRpJodFEHOKg=b09bCdTOGVhOmxdWbWwiTx0FedVeDW7Ol0EJV6pN_BQ= -- Kind regards, Pavlo mailto:pavlo.go...@cybertec.at
Re: ReplicationSlotCtl: undefined reference
On Jun 13, 2019 17:56, Tom Lane wrote:Pavlo Golub writes: > Trying to build pg extension I've got error: > ``` > pglogical_monitoring.o:pglogical_monitoring.c:(.rdata$.refptr.ReplicationSlotCtl[.refptr.ReplicationSlotCtl]+0x0): undefined reference to `ReplicationSlotCtl' > collect2: error: ld returned 1 exit status > ``` > But according to https://commitfest.postgresql.org/16/1390/ it should > be marked with PGDLLIMPORT. That last bit never actually got pushed, it seems. Done now. Thanks Tom. Really appreciate that! regards, tom lane
ReplicationSlotCtl: undefined reference
Greetings. Trying to build pg extension I've got error: ``` pglogical_monitoring.o:pglogical_monitoring.c:(.rdata$.refptr.ReplicationSlotCtl[.refptr.ReplicationSlotCtl]+0x0): undefined reference to `ReplicationSlotCtl' collect2: error: ld returned 1 exit status ``` But according to https://commitfest.postgresql.org/16/1390/ it should be marked with PGDLLIMPORT. However checking sources there is no this spec (https://github.com/postgres/postgres/blob/fff2a7d7bd09db38e1bafc1303c29b10a9805dc0/src/include/replication/slot.h#L172): ``` extern ReplicationSlotCtlData *ReplicationSlotCtl; ``` Am I correct or missing smth? Craig, it supposed to be your proposal about ReplicationSlotCtl and patch. Am I right? -- Kind regards, Pavlo mailto:pavlo.go...@cybertec.at
Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3
Greetings, Antonin. You wrote 2019-06-05, 15:32: > Robert Haas wrote: >> On Fri, May 31, 2019 at 2:59 AM Antonin Houska wrote: >> > > Sounds good. I'm not quite sure how this is going to work. Ideally >> > > you'd like the encryption key command to fetch the key from something >> > > like ssh-agent, or maybe pop up a window on the user's terminal with a >> > > key prompt. Just reading from stdin and writing to stdout is not >> > > going to be very convenient... >> > >> > When I mentioned writing to stdout in my previous email, I viewed it from >> > the >> > perspective of postmaster: whichever way the command gets the password from >> > the DBA, it'll always write it to stdout and postmaster will read it from >> > there. This was to address your objection that the executables do not >> > actually >> > "return" strings. >> >> So the part about returning strings is really just a wording issue: >> the documentation needs to talk about data sent to stdout or wherever, >> because that's what really happens, and somebody writing such a >> command from scratch needs to know what it must do. >> >> What I'm talking about here is that it also has to be reasonably >> possible to write an encryption key command that does something >> useful. I don't have a really clear vision for how that's going to >> work. Nobody wants the server, which is probably being launched by >> pg_ctl or systemd or both, to prompt using its own stdin/stderr, but >> the we need to think about how the prompting is actually going to >> work. > Since you mentioned ssh-agent above, I think that postmaster can, instead of > running a command, create an unix socket and read the key from there. (I refer > only to the socket as a communication channel, not to the protocol - ssh-agent > does not seem to actually send key over the socket.) Unlike the socket for > backend connections, this one would only be readable by the user that runs > postmaster, and would only exist during the encryption initialization. > The simplest approach from the perspective of the DBA is that pg_ctl can write > the key to the socket. Besides that we can also implement a separate utility > to send the key, to be used in other special cases such as starting postgres > via systemd. > (If the unix socket is a problem on windows, we might need to use named pipe > instead.) Yes, that definitely a problem on Windows. Pipes seems reasonable. Are mapped files are appropriate from the security point of view? >> > The header comment in pg_upgrade.c indicates that this is because of >> > TOAST. So >> > I think that dbnode and relfilenode are not preserved just because there >> > was >> > no strong reason to do so by now. >> >> Maybe you want to propose an independent patch making that change? > I think of a separate diff in the encryption patch series. As the encryption > is the only reason for this enhancement, I'm not sure if it deserves a > separate CF entry. (Although it might be considered refactoring because > eventually pg_upgrade won't need to handle the different relnodes, and thus it > might become a little bit simpler.) -- Kind regards, Pavlo mailto:pavlo.go...@cybertec.at
Re: Porting PG Extension from UNIX to Windows
Greetings, Alexander. You wrote 08.05.2018, 9:42: > 25.04.2018 11:45, insaf.k wrote: > > I've done some research regarding compiling in Windows. I > am not sure in what way I should compile the extension. > AFAIK, Visual Studio is not POSIX compliant and so I'll have > to rewrite all those POSIX calls using Windows API. So it's > better to compile the extension in Cygwin. > > > I have some questions regarding compiling the extension in > Cygwin. Do I have to build PG in Cygwin, if I want to compilethe > extension in Cygwin? > > I think it might depend on the extension, but we have managed > to use mingw-compiled extension with VS-compiled PG. Please look at the > demo script: > https://pastebin.com/3jQahYNe > If you have any questions, please don't hesitate to ask. Cool idea. - Why are you using x86 version of MSYS2? - And why don't you use just msys2-x86_64-latest.tar.xz instead of exactly named one? > > Best regards, > > -- >Alexander Lakhin >Postgres Professional: http://www.postgrespro.com >The Russian Postgres Company > -- Kind regards, Pavlo mailto:pavlo.go...@cybertec.at
Re: Porting PG Extension from UNIX to Windows
Greetings, insaf.k. You wrote 25.04.2018, 11:45: > Hello, > I have developed a postgres extension in Linux. I want to compile it in MS > Windows as well. You should try MSYS2. It's far better than VS and MSYS right now. I may try to build your extension if you want. > The extension extensively make use of POSIX threads and mutexes. > I've done some research regarding compiling in Windows. I am not > sure in what way I should compile the extension. AFAIK, Visual > Studio is not POSIX compliant and so I'll have to rewrite all those > POSIX calls using Windows API. So it's better to compile the extension in > Cygwin. > I have some questions regarding compiling the extension in Cygwin. > Do I have to build PG in Cygwin, if I want to compile the extension in Cygwin? > Our deployment pattern is like this, build everything in one > machine and copy the DLLs into the production machine. So, if I > compile in Cygwin, will the generated DLLs work in other Windows > machines? Would the target machine be required to install any > dependencies related to Cygwin in order to use the DLLs? > Also, one more question, not related to PG. Cygwin vs native > Windows API calls, will there be much difference in the > performance?(We are not using fork() calls, btw). > Thanks, > Insaf -- Kind regards, Pavlo mailto:pavlo.go...@cybertec.at
Re: Issues while building PG in MS Windows, using MSYS2 and MinGW-w64
Hello, insaf.k. You wrote: ik> Hello, ik> I am trying to build PG from source, in MS Windows using MSYS2 ik> and MinGW-w64. I've tried to build PG 10.0 as wells as 10.3. Just checked. All compiled in a sane way. I suppose you have some environmental problems. This is my step-by-step guide: 1. Download MSYS2 installer, 64-bit. 2. Run, choose simple install folder, e.g. C:\msys64 3. Run MSYS2 after installation and execute: pacman -Syu 4. Maybe you'll need this several times. Close console 5. Open appropriate console with correct environment: a) C:\msys64\msys2_shell.cmd -mingw64 or b) just click on the Start menu “MSYS2 MinGW 64-bit” shortcut 6. In it update packages: pacman -Syu 7. Install needed packages: pacman --needed -S git mingw-w64-x86_64-gcc base-devel 8. Execute: git clone git://git.postgresql.org/git/postgresql.git cd postgresql ./configure --host=x86_64-w64-mingw32 --prefix=/c/pgsql/ && make && make install Here we tell our target machine will be 64-bit and we want our binaries to be copied to C:\pgsql\. ik> I've done configuring like this ik> ./configure --prefix="/d/pg10/" ik> And when I do "make" or "make world", I'm getting compilation ik> error. I've attached complete error report at the end of the mail. ik> Basically, one error is pre-processor #error must have a working 64-bit integer datatype. ik> Another error is "redifinition of fseeko". ik> Another error is "FLEXIBLE_ARRAY_MEMBER" is undefined. ik> I don't know why the error is coming, I tried reinstalling MSYS2 ik> and but still no luck. Could you please help? ik> My $PATH var is ik> $ echo $PATH ik> /mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl ik> $ make ik> make -C src all ik> make[1]: Entering directory '/d/Insaf/pgSource/postgresql-10.0/src' ik> make -C common all ik> make[2]: Entering directory ik> '/d/Insaf/pgSource/postgresql-10.0/src/common' ik> make -C ../backend submake-errcodes ik> make[3]: Entering directory ik> '/d/Insaf/pgSource/postgresql-10.0/src/backend' ik> make[3]: Nothing to be done for 'submake-errcodes'. ik> make[3]: Leaving directory ik> '/d/Insaf/pgSource/postgresql-10.0/src/backend' ik> gcc -Wall -Wmissing-prototypes -Wpointer-arith ik> -Wdeclaration-after-statement -Wendif-labels ik> -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing ik> -fwrapv -fexce ss-precision=standard -O2 ik> -DFRONTEND -I../../src/include -I./src/include/port/win32 ik> -DEXEC_BACKEND "-I../../src/include/port/win32" -DBUILDING_DLL ik> -DVAL_CONFIGURE="\"'--p refix=/d/Insaf/pgGcc' ik> 'PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig'\"" ik> -DVAL_CC="\"gcc\"" -DVAL_CPPFLAGS="\"-DFRONTEND ik> -I./src/include/port/win32 -DEXEC _BACKEND ik> "-I../../src/include/port/win32" -DBUILDING_DLL\"" ik> -DVAL_CFLAGS="\"-Wall -Wmissing-prototypes -Wpointer-arith ik> -Wdeclaration-after-statement -Wendif-labels -Wmissin ik> g-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv ik> -fexcess-precision=standard -O2\"" -DVAL_CFLAGS_SL="\"\"" ik> -DVAL_LDFLAGS="\"-L../../src/common -Wl,--allow- ik> multiple-definition -Wl,--disable-auto-import -Wl,--as-needed\"" ik> -DVAL_LDFLAGS_EX="\"\"" -DVAL_LDFLAGS_SL="\"\"" ik> -DVAL_LIBS="\"-lpgcommon -lpgport -lz -lws2_32 -lm -lws2_32 \"" -c -o base64.o base64.c ik> In file included from ../../src/include/c.h:48:0, ik> from ../../src/include/postgres_fe.h:25, ik> from base64.c:18: ik> ../../src/include/postgres_ext.h:47:9: error: unknown type name 'PG_INT64_TYPE' ik> typedef PG_INT64_TYPE pg_int64; ik> ^ ik> In file included from ../../src/include/postgres_fe.h:25:0, ik> from base64.c:18: ik> ../../src/include/c.h:306:2: error: #error must have a working 64-bit integer datatype ik> #error must have a working 64-bit integer datatype ik> ^ ik> ../../src/include/c.h:446:15: error: 'FLEXIBLE_ARRAY_MEMBER' ik> undeclared here (not in a function) ik> char vl_dat[FLEXIBLE_ARRAY_MEMBER]; /* Data content is here */ ik>^ ik> In file included from ../../src/include/postgres_fe.h:25:0, ik> from base64.c:18: ik> ../../src/include/c.h:1054:1: warning: 'PG_PRINTF_ATTRIBUTE' is ik> an unrecognized format function type [-Wformat=] ik> extern int snprintf(char *str, size_t count, const char ik> *fmt,...) pg_attribute_printf(3, 4); ik> ^~ ik> In file included from ../../src/include/c.h:1129:0, ik> from ../../src/include/postgres_fe.h:25, ik> from base64.c:18: ik> ../../src/include/port.h:375:0: warning: "fseeko" redefined ik> #define fseeko(a, b, c) fseek(a, b, c) ik> In file included from
