Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10
On 11/22/24 10:00, Matthias Apitz wrote: El día viernes, noviembre 22, 2024 a las 05:52:34 +0100, Laurenz Albe escribió: On Fri, 2024-11-22 at 10:01 +0530, Subhash Udata wrote: Currently, my environment is running PostgreSQL 15.0. I understand that version 15.9 contains the fix for CVE-2024-10979, as mentioned in the release notes. Given that I am not using the PL/Perl extension in my environment, I wanted to ask: * Is it still mandatory to upgrade specifically to version 15.9, or would remaining on version 15.0 suffice in this case? I appreciate your guidance on whether this upgrade is necessary, considering the specifics of my setup. If you don't use PL/Perl, you are not affected by that security vulnerability. I wonder what you mean by "mandatory". We won't fine or punish you if you don't update PostgreSQL, but perhaps it would make your employer unhappy. If you stay on 15.0, you will be subject to thirteen other security vulnerabilities (if I counted right), and you may end up with corrupted GIN and BRIN indexes. Additionally, you will be subject to countless known bugs that have been fixed since. You should *always* update to the latest minor release shortly after it is released. Everything else is negligent. Laurenz, et all, The company I'm working for is producer of a Library Management System with C/C++ written servers on Linux, using ESQL/C and DBI interfaces of PostgreSQL (and older version Sybase too) and the software is deployed to 100++ customer installations, sometimes with limited own IT know how. "You should *always* update ..." is nice to say, but in the described land not easy to do. For the two released versions of our software (V7.2 and V7.3) and the current version in development (V7.3-SP1) we plan the following migrations of the server and client side of PostgreSQL: under development: V7.3-SP1 (we will not support 15.9 as cluster in SP1) used ESQL/C 15.9 (i.e. PostgreSQL client side) migrate the used cluster/database 'from' --> 'to' 15.1 --> 16.5 16.2 --> 16.5 released: V7.3 (we will not support 15.9 as cluster in V7.3) used ESQL/C 15.1 (i.e. PostgreSQL client side) migrate the used cluster/database 'from' --> 'to' 15.1 --> 16.5 16.2 --> 16.5 released: V7.2 (we will not support 15.9 as cluster in V7.2) used ESQL/C 11.4 (i.e. PostgreSQL client side) migrate the used cluster/database 'from' --> 'to' 13.1 --> 16.5 16.2 --> 16.5 Why not decouple client libs from the server ? i.e. psql works great with many versions greater than its own. And certainly with same major versions. You could retain the same client libs and just upgrade the PgSQL server to the highest minor version of the major version that you support. Granted, I am coming from JDBC/psql land but still those restrictions above just seem too much. Of course SQL correctness from version to version (such as "trailing junk", standard_conforming_strings, etc ..) and performance are tasks that has to be done, you can't skip those. But IMHO the server version in the general case is independent or should be independent from the app. We recently migrated from 10.23 -> 16.4 with slight bruises (almost 6+ months preparation by me and 3-4 months preparation from the dept team). Just my 5 cents. Especially the version V7.2 (released in 2021) can't be updated on the client side, the cluster will be migrated to 16.5. I assume that CVE-2024-10979 affects the server side, and not the client side. Any further comments on this? Thanks matthias
Re: PostgreSQL Log Info
Isn't "I need the query returned values" the purpose of the client application? On Fri, Nov 22, 2024 at 2:32 AM Jethish Jethish wrote: > Hi David, > > If an select query is fired I need the query returned values needs to be > logged in my PostgreSQL log file. > > > For example if a select query returns 5 rows I need the same in the log > file > > On Fri, Nov 22, 2024, 10:49 AM David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> On Thursday, November 21, 2024, Jethish Jethish >> wrote: >>> >>> Is it possible to log the rows returned by a query in the PostgreSQL >>> logs? >>> >> >> As a practical matter, no. That said, given one can get row contents >> into the server log in various ways, what is the use case for why this >> capability is thought to be needed? >> >> David J. >> > -- Death to , and butter sauce. Don't boil me, I'm still alive. lobster!
Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10
El día viernes, noviembre 22, 2024 a las 11:01:29 +0200, Achilleas Mantzios - cloud escribió: > > under development: V7.3-SP1 (we will not support 15.9 as cluster in SP1) > > used ESQL/C 15.9 (i.e. PostgreSQL client side) > > migrate the used cluster/database 'from' --> 'to' > > 15.1 --> 16.5 > > 16.2 --> 16.5 > > > > released: V7.3 (we will not support 15.9 as cluster in V7.3) > > used ESQL/C 15.1 (i.e. PostgreSQL client side) > > migrate the used cluster/database 'from' --> 'to' > > 15.1 --> 16.5 > > 16.2 --> 16.5 > > > > released: V7.2 (we will not support 15.9 as cluster in V7.2) > > used ESQL/C 11.4 (i.e. PostgreSQL client side) > > migrate the used cluster/database 'from' --> 'to' > > 13.1 --> 16.5 > > 16.2 --> 16.5 > > Why not decouple client libs from the server ? i.e. psql works great with > many versions greater than its own. And certainly with same major versions. > You could retain the same client libs and just upgrade the PgSQL server to > the highest minor version of the major version that you support. > ... This is exactly the plan. For all the three versions the cluster will be migrated to 16.5 and the client side will stay for the released version with what they currently use (11.4 or 15.1). And for the version under development 15.9 matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Annalena Baerbock: "We are fighting a war against Russia ..." (25.1.2023) I, Matthias, I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.
Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10
El día viernes, noviembre 22, 2024 a las 05:52:34 +0100, Laurenz Albe escribió: > On Fri, 2024-11-22 at 10:01 +0530, Subhash Udata wrote: > > Currently, my environment is running PostgreSQL 15.0. I understand that > > version > > 15.9 contains the fix for CVE-2024-10979, as mentioned in the release notes. > > Given that I am not using the PL/Perl extension in my environment, I wanted > > to ask: > > * Is it still mandatory to upgrade specifically to version 15.9, or would > >remaining on version 15.0 suffice in this case? > > I appreciate your guidance on whether this upgrade is necessary, > > considering the > > specifics of my setup. > > If you don't use PL/Perl, you are not affected by that security vulnerability. > > I wonder what you mean by "mandatory". > > We won't fine or punish you if you don't update PostgreSQL, but perhaps it > would make your employer unhappy. If you stay on 15.0, you will be subject to > thirteen other security vulnerabilities (if I counted right), and you may end > up with corrupted GIN and BRIN indexes. Additionally, you will be subject to > countless known bugs that have been fixed since. > > You should *always* update to the latest minor release shortly after it is > released. Everything else is negligent. Laurenz, et all, The company I'm working for is producer of a Library Management System with C/C++ written servers on Linux, using ESQL/C and DBI interfaces of PostgreSQL (and older version Sybase too) and the software is deployed to 100++ customer installations, sometimes with limited own IT know how. "You should *always* update ..." is nice to say, but in the described land not easy to do. For the two released versions of our software (V7.2 and V7.3) and the current version in development (V7.3-SP1) we plan the following migrations of the server and client side of PostgreSQL: under development: V7.3-SP1 (we will not support 15.9 as cluster in SP1) used ESQL/C 15.9 (i.e. PostgreSQL client side) migrate the used cluster/database 'from' --> 'to' 15.1 --> 16.5 16.2 --> 16.5 released: V7.3 (we will not support 15.9 as cluster in V7.3) used ESQL/C 15.1 (i.e. PostgreSQL client side) migrate the used cluster/database 'from' --> 'to' 15.1 --> 16.5 16.2 --> 16.5 released: V7.2 (we will not support 15.9 as cluster in V7.2) used ESQL/C 11.4 (i.e. PostgreSQL client side) migrate the used cluster/database 'from' --> 'to' 13.1 --> 16.5 16.2 --> 16.5 Especially the version V7.2 (released in 2021) can't be updated on the client side, the cluster will be migrated to 16.5. I assume that CVE-2024-10979 affects the server side, and not the client side. Any further comments on this? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: PostgreSQL Log Info
Am Fri, Nov 22, 2024 at 01:02:27PM +0530 schrieb Jethish Jethish: > If an select query is fired I need the query returned values needs to be > logged in my PostgreSQL log file. What do you expect your log file to be in size after, say, a day of activity ? Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Re: PostgreSQL Log Info
On Fri, Nov 22, 2024 at 01:02:27PM +0530, Jethish Jethish wrote: > Hi David, > > If an select query is fired I need the query returned values needs to be > logged in my PostgreSQL log file. > > > For example if a select query returns 5 rows I need the same in the log > file Please note that you wrote what you want to do. And David asked about use case. Which is different. Basically the question can be summed into: *why* you think you want that. I don't think anything even remotely similar to this exists. You could, of course, add it to Pg by changing sources (it is open source after all), but given that such feature would be downright dangerous for huge majority of situations, I don't expect it to become reality in mainline Pg. Best regards, depesz
Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10
On Fri, Nov 22, 2024 at 4:01 AM Achilleas Mantzios - cloud < a.mantz...@cloud.gatewaynet.com> wrote: > > On 11/22/24 10:00, Matthias Apitz wrote: > [snip] > > Why not decouple client libs from the server ? i.e. psql works great > with many versions greater than its own. And certainly with same major > versions. You could retain the same client libs and just upgrade the > PgSQL server to the highest minor version of the major version that you > support. > Small VARs that sell turnkey solutions would rather bundle everything together. One application version, one database version, one OS version, one set of hardware, all bundled up and sold to a tech-illiterate customer that doesn't employ a DBA or SysAdmin. That way, when something stops working, you aren't guessing if it's this patch, that patch, etc etc. Not saying that Matthias works for such a VAR, but such companies definitely exist. -- Death to , and butter sauce. Don't boil me, I'm still alive. lobster!
Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10
On Friday, November 22, 2024, Matthias Apitz wrote: > > Especially the version V7.2 (released in 2021) can't be updated on the > client side, the cluster will be migrated to 16.5. I assume that > CVE-2024-10979 affects the server side, and not the client side. > Yes, it is the server that executes procedural language code like plperl. David J.
Re: Fwd: A million users
On Wed, Nov 13, 2024 at 12:02 PM wrote:
> I don't have any benchmarks, but the following data point:
>
> We use PostgREST [1] which connects to the database with one
> "authenticator" role. For each request it handles, it does a SET ROLE to
> a role defined in the Authorization Header (JWT).
>
> Some numbers we are running with currently:
> - 1 authenticator role
> - ~ 127.000 user roles granted to "authenticator"
> - ~ 14.000 "scope" roles granted to the user roles (tenants, groups, ..)
> - ~ 15 "context" roles granted to user roles ("admin", "user", ...)
> - ~ 50 "access" roles granted to context roles ("view_x", "do_y", ...)
>
> Only the access roles have any direct privileges granted.
>
> We currently have ~ 700 RLS policies defined. Those are created TO the
> context roles. The policies check the current role's scope roles to
> select "allowed" rows.
>
> In total, we have ~370.000 roles granted to each other (pg_auth_members).
>
> Except for one thing, we have never had any real problems with this. We
> didn't observe anything getting massively worse with many roles, even
> though we use them extensively. RLS policies need to be carefully
> written to get any performance, though.
>
> The one problem we found is:
>
> The first time the authenticator role does a SET ROLE in a session it's
> **terribly** slow. With fewer users back then it took 6-7 minutes to do
> it. Any SET ROLE afterwards in the same session would be fast. Even more
> annoying - killing the session with SET ROLE running would not work
> properly and leave zombie processes. Giving the authenticator role the
> SUPERUSER privilege avoids the problem and makes it instant. However..
> that's not very desirable.
>
> There were some improvements, IIRC in the 17 cycle (?), in that area,
> but I had not have the time to test it with that. We are still on v15
> and the last time I tested this was ~ two years ago. I still wasn't able
> to put together a simple reproducer either.
>
> You should *probably* be better off with your different LOGIN roles, I
> assume the role cache builds up much quicker in that case.
>
I'm really interested in how this works. Role-per-user or even the ability
to have many roles (370k??) seems like a dream come true. But I always was
wary of it because:
a) A connection-per-role hits the ceiling pretty quickly because
connections can't be pooled and shared between users and take up a lot of
memory etc.
b) One could try to get around this with an authenticator role as you
describe, but isn't it then possible to do a RESET ROLE and then another
SET ROLE to get access to another user? This of course would have to be
through SQL injection or some such, but it seems like that defeats at least
some of the purpose of RLS.
Did you find some way to prevent RESET ROLE? I once advocated for a NO
RESET option on SET ROLE [1] so that RESET ROLE would be impossible for the
rest of the session. Still think it would be helpful.
Thanks,
Eric
[1]
https://www.postgresql.org/message-id/flat/CACA6kxgdzt-oForijaxfXHHhnZ1WBoVGMXVwFrJqUu-Hg3C-jA%40mail.gmail.com
Wired behaviour from SELECT
Two different SELECT sql statement don't behave the same way. The below sql statement produces the right output SELECT nickname, password FROM password WHERE id='0938105618107N1'; nickname | password -+-- Piccard@@21 | Arbol (1 row) However, if this sql statement produces the wrong output SELECT nickname, password FROM password WHERE nickname='Arbol'; nickname | password --+-- (0 rows) What am I doing wrong?
Re: Wired behaviour from SELECT
On Fri, Nov 22, 2024 at 1:07 PM Arbol One wrote: > The below sql statement produces the right output > SELECT nickname, password FROM password WHERE id='0938105618107N1'; > nickname | password > -+-- > Piccard@@21 | Arbol > (1 row) > However, if this sql statement produces the wrong output > > > > *SELECT nickname, password FROM password WHERE nickname='Arbol'; nickname > | password --+-- (0 rows)* > What am I doing wrong? > Naming a column in your table the same name as the table is problematic generally. As for the query, if they are both intended to return the same row the value Arbol is in the password column, not the nickname column. You seem to have reversed the data for the two columns. David J.
Re: Memory settings when running postgres in a docker container
Ah, see, I didn't know that. On Wed, Nov 20, 2024 at 11:10 PM David Mullineux wrote: > i dont get why you think all memroy will be used. > When you say > shared_buffers = 16GB > effective_cache_size = 48GB > > ...then this is using only 16GB for shared buffers. > > The effective _cache_size doesn't cause any memory to.be allocated. It's > just a hint to optomizer > > On Wed, 20 Nov 2024, 11:16 Koen De Groote, wrote: > >> Assuming a machine with: >> >> * 16 CPU cores >> * 64GB RAM >> >> Set to 500 max connections >> >> A tool like this: https://pgtune.leopard.in.ua/ >> >> Will output recommended settings: >> >> max_connections = 500 >> shared_buffers = 16GB >> effective_cache_size = 48GB >> maintenance_work_mem = 2GB >> checkpoint_completion_target = 0.9 >> wal_buffers = 16MB >> default_statistics_target = 100 >> random_page_cost = 1.1 >> effective_io_concurrency = 200 >> work_mem = 8388kB >> huge_pages = try >> min_wal_size = 1GB >> max_wal_size = 4GB >> max_worker_processes = 16 >> max_parallel_workers_per_gather = 4 >> max_parallel_workers = 16 >> max_parallel_maintenance_workers = 4 >> >> And they basically use up all the memory of the machine. >> >> 16GB shared buffers, 48GB effective cache size, 8MB of work_mem for some >> reason... >> >> This seems rather extreme. I feel there should be free memory for >> emergencies and monitoring solutions. >> >> And then there's the fact that postgres on this machine will be run in a >> docker container. Which, on Linux, receives 64MB of /dev/shm shared memory >> by default, but can be increased. >> >> I feel like I should probably actually lower my upper limit for memory, >> regardless of what the machine actually has, so I can have free memory, and >> also not bring the container process itself into danger. >> >> Is it as straightforward as putting my limit on, say 20GB, and then >> giving more /dev/shm to the container? Or is there more to consider? >> >> Regards, >> Koen De Groote >> >> >> >> >> >> >>
Re: PostgreSQL Log Info
Sorry guys, what I meant was to log the tuple returned count not the values to get printed in logs. On Fri, Nov 22, 2024, 9:46 PM David G. Johnston wrote: > On Fri, Nov 22, 2024 at 12:32 AM Jethish Jethish > wrote: > >> If an select query is fired I need the query returned values needs to be >> logged in my PostgreSQL log file. >> > Then the answer is no, and unlikely to become a feature anyone would > develop or that we'd accept. > > A more innovative solution is going to need to be thought up to > satisfy the security people that want to know what data was acquired from > their system by either their users or semi-privileged hackers (privileged > exploits would likely just disable such logging anyway). The space of > setting up a proxy server in between clients and the PostgreSQL server is > under-explored as a means by which to incorporate such functionality > externally to the core server. > > David J. >
Re: PostgreSQL Log Info
On 11/21/24 21:02, Jethish Jethish wrote: Hi Everyone, Is it possible to log the rows returned by a query in the PostgreSQL logs? https://github.com/pgaudit/pgaudit/blob/main/README.md "pgaudit.log_rows Specifies that audit logging should include the number of rows retrieved or affected by a statement. When enabled the rows field will be included after the parameter field. The default is off." -- Adrian Klaver adrian.kla...@aklaver.com
Re: PostgreSQL Log Info
On Fri, Nov 22, 2024 at 9:26 AM Jethish Jethish wrote: > Sorry guys, what I meant was to log the tuple returned count not the > values to get printed in logs. > That too is a no. Though more because is just doesn't seem useful enough to expend effort on designing and implementing something. There is a work-around in that you could enable auto-explain with analyze and read the actuals from that. David J.
Re: Wired behaviour from SELECT
On Fri, Nov 22, 2024 at 3:07 PM Arbol One wrote: > > Two different SELECT sql statement don't behave the same way. > The below sql statement produces the right output > SELECT nickname, password FROM password WHERE id='0938105618107N1'; > nickname | password > -+-- > Piccard@@21 | Arbol > (1 row) > Storing passwords in plain text is the Worst Possible Security Practice Ever Conceived. -- Death to , and butter sauce. Don't boil me, I'm still alive. lobster!
Re: Wired behaviour from SELECT
Instead of nickname you probably want tontet where password=`Arbol' .. or am.i.missong something ?. On Fri, 22 Nov 2024, 20:13 David G. Johnston, wrote: > On Fri, Nov 22, 2024 at 1:07 PM Arbol One wrote: > >> The below sql statement produces the right output >> SELECT nickname, password FROM password WHERE id='0938105618107N1'; >> nickname | password >> -+-- >> Piccard@@21 | Arbol >> (1 row) >> However, if this sql statement produces the wrong output >> >> >> >> *SELECT nickname, password FROM password WHERE nickname='Arbol'; >> nickname | password --+-- (0 rows)* >> What am I doing wrong? >> > Naming a column in your table the same name as the table is problematic > generally. As for the query, if they are both intended to return the same > row the value Arbol is in the password column, not the nickname column. > You seem to have reversed the data for the two columns. > > David J. > >
Re: Fwd: A million users
On Fri, Nov 22, 2024 at 6:57 AM wrote: > Yeah, this is still on my list of things to research more about > eventually - currently still unsolved. > > For my use-case the NO RESET would need to apply until the end of the > transaction, not end of the session. > > I imagine something like an extension, that would: > - block any SET SESSION ROLE > - block any RESET ROLE > - only allow SET LOCAL ROLE when CURRENT_USER has the right to do so > > Then the effect of SET LOCAL ROLE would still be reversed at the end of > the transaction, but you could never "escape" a SET LOCAL ROLE that was > set earlier. As things are now, would someone be able to do a RESET ROLE if *any* code/function had a SQL injection vulnerability, or only if there was one in the pooler? Or (ideally) neither. That's what a NO RESET option (or some similar functionality) would provide with certainty. I found this extension: https://github.com/pgaudit/set_user but haven't used it. Seems to address this though, they introduce a set_session_auth(token) function and then reset_role requires the token if session_auth has been set. Thanks, Eric
Re: Fwd: A million users
Eric Hanson: Did you find some way to prevent RESET ROLE? I once advocated for a NO RESET option on SET ROLE [1] so that RESET ROLE would be impossible for the rest of the session. Still think it would be helpful. Yeah, this is still on my list of things to research more about eventually - currently still unsolved. For my use-case the NO RESET would need to apply until the end of the transaction, not end of the session. I imagine something like an extension, that would: - block any SET SESSION ROLE - block any RESET ROLE - only allow SET LOCAL ROLE when CURRENT_USER has the right to do so Then the effect of SET LOCAL ROLE would still be reversed at the end of the transaction, but you could never "escape" a SET LOCAL ROLE that was set earlier. Best, Wolfgang
Re: Database stats ( pg_stat_database.stats_reset ) get reset on daily basis - why?
On 11/21/24 15:50, Steeve Boulanger wrote: > 1) Do the 77 share some trait the other 80 don't. No pattern found yet .. but still verifying a few things > 2) Do the OS system logs reveal anything? Nothing found in syslog > 3) What was happening in the databases just prior to the time the stats reset? Here's an example (log extracts) for a stats reset occurrence: select datname, stats_reset, now()-stats_reset as since_reset from pg_stat_database where ( now()-stats_reset ) < interval '1 day' order by 3 limit 1; datname | stats_reset | since_reset +---+- MyDB | *2024-11-21 13:48:34.332*785+00 | 00:00:22.266304 <--LOGS--> 2024-11-21 13:48:34.324 UTC pid=[322035][2] db=[MyDB] usr=[user1] client=[host1] app=[[unknown]]LOG: connection authorized: user=user1 database=MyDB applicatio n_name=app1 <..> What is the [2] referring to? <.. no calls at "2024-11-21 13:48:34.332" - WHY?? ..> My guess is the difference in time it takes to log the action and set the log timestamp. Whereas the stats_reset value is the timestamp when the stats system actually did the reset. 2024-11-21 13:48:34.336 UTC pid=[322035][3] db=[MyDB] usr=[user1] client=[host1] app=[app1]LOG: duration: 1.071 ms parse : SELECT <..> The above is some garden variety select? -- Adrian Klaver adrian.kla...@aklaver.com
Re: PostgreSQL Log Info
On Fri, Nov 22, 2024 at 12:32 AM Jethish Jethish wrote: > If an select query is fired I need the query returned values needs to be > logged in my PostgreSQL log file. > Then the answer is no, and unlikely to become a feature anyone would develop or that we'd accept. A more innovative solution is going to need to be thought up to satisfy the security people that want to know what data was acquired from their system by either their users or semi-privileged hackers (privileged exploits would likely just disable such logging anyway). The space of setting up a proxy server in between clients and the PostgreSQL server is under-explored as a means by which to incorporate such functionality externally to the core server. David J.
Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10
On Fri, 2024-11-22 at 09:00 +0100, Matthias Apitz wrote: > > > Given that I am not using the PL/Perl extension in my environment, I > > > wanted to ask: > > > * Is it still mandatory to upgrade specifically to version 15.9, or would > > > remaining on version 15.0 suffice in this case? > > > I appreciate your guidance on whether this upgrade is necessary, > > > considering the > > > specifics of my setup. > > > > If you don't use PL/Perl, you are not affected by that security > > vulnerability. > > > > I wonder what you mean by "mandatory". > > > > We won't fine or punish you if you don't update PostgreSQL, but perhaps it > > would make your employer unhappy. If you stay on 15.0, you will be subject > > to > > thirteen other security vulnerabilities (if I counted right), and you may > > end > > up with corrupted GIN and BRIN indexes. Additionally, you will be subject > > to > > countless known bugs that have been fixed since. > > > > You should *always* update to the latest minor release shortly after it is > > released. Everything else is negligent. > > The company I'm working for is producer of a Library Management System > with C/C++ written servers on Linux, using ESQL/C and DBI interfaces of > PostgreSQL (and older version Sybase too) and the software is deployed > to 100++ customer installations, sometimes with limited own IT know how. And you didn't plan how you intend to ship software updates to these customers? > "You should *always* update ..." is nice to say, but in the described land > not easy to do. If you say so. Still, that is a problem that will come to bite you some day, as soon as your customers hit some PostgreSQL bug. > I assume that > CVE-2024-10979 affects the server side, and not the client side. Right. I wonder why you are so keen on that vulnerability and ignore all the others discovered since 15.0. > Any further comments on this? No. I told you that you should update, and you explained in great detail why you cannot. There is nothing more to say. Good luck. Yours, Laurenz Albe
Re: PostgreSQL Log Info
On 11/21/24 23:32, Jethish Jethish wrote: Hi David, If an select query is fired I need the query returned values needs to be logged in my PostgreSQL log file. For example if a select query returns 5 rows I need the same in the log file What if the query returns 500,000 rows? What is the purpose of retaining this information? On Fri, Nov 22, 2024, 10:49 AM David G. Johnston mailto:david.g.johns...@gmail.com>> wrote: On Thursday, November 21, 2024, Jethish Jethish mailto:jethish...@gmail.com>> wrote: Is it possible to log the rows returned by a query in the PostgreSQL logs? As a practical matter, no. That said, given one can get row contents into the server log in various ways, what is the use case for why this capability is thought to be needed? David J. -- Adrian Klaver adrian.kla...@aklaver.com
