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
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 extens
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 doe
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
> -+--
> Picc
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 produc
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 produce
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 st
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.
The
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
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
>>
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
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
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?
> > >
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 execut
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 -
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).
>
>
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
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
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 ma
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
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
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-
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 relea
23 matches
Mail list logo
