Re: 回复：回复：A question about leakproof

[Laurenz Albe]

On Mon, 2022-10-17 at 13:17 +0800, qiumingcheng wrote:
> > you seem to be imagining that changes in a query's plan on the basis of 
> > changes
> > in collected statistics have something to do with this.  They do not.
>
> Sorry, I may not fully understand what you mean. I mean that after my tests,
> the execution results of this SQL (explain select * from tb_a_date_v1) 
> execution plan
> are different under different users, which is really related to the parameter 
> proleakproof.

That's the idea behind leakproof: if a function is not leakproof, the optimizer
will not move it "inside" the view definition.  Then the function is evaluated 
only
after the view definition.  That may very well lead to a slower execution plan,
because it cannot use certain indexes on the underlying tables.

It is the price you have to pay for good security.

Yours,
Laurenz Albe

About foreign data wrapper

[Rama Krishnan]

Hi all,

What Is the difference between dblink and foreign data wrapper?


Thanks
Ramakrishnan

回复：回复：回复：A question about leakproof

[qiumingcheng]

> "you seem to be imagining that changes in a query's plan on the basis of 
> changes
> in collected statistics have something to do with this. They do not."
1. My understanding of the above paragraph is that for the same view and 
different users, the proleakproof=false attribute of the function will not lead 
to inconsistent plans, but my actual test result is that proleakproof=false 
will lead to inconsistent plans。
2. What's the reason about the function timestamp_gt_timestampz may cause data 
leakage? Can you explain how it causes data leakage?
--
发件人：Laurenz Albe 
发送时间：2022年10月17日(星期一) 15:20
收件人：qiumingcheng ; Tom Lane 
抄　送：Julien Rouhaud ; pgsql-general 

主　题：Re: 回复：回复：A question about leakproof
On Mon, 2022-10-17 at 13:17 +0800, qiumingcheng wrote:
> > you seem to be imagining that changes in a query's plan on the basis of 
> > changes
> > in collected statistics have something to do with this. They do not.
>
> Sorry, I may not fully understand what you mean. I mean that after my tests,
> the execution results of this SQL (explain select * from tb_a_date_v1) 
> execution plan
> are different under different users, which is really related to the parameter 
> proleakproof.
That's the idea behind leakproof: if a function is not leakproof, the optimizer
will not move it "inside" the view definition. Then the function is evaluated 
only
after the view definition. That may very well lead to a slower execution plan,
because it cannot use certain indexes on the underlying tables.
It is the price you have to pay for good security.
Yours,
Laurenz Albe

Fedora 37

[Kieran McCusker]

Hi

Is there any timeline for a Fedora 37 repository as it should be released
tomorrow?

Many thanks

Kieran

Re: About foreign data wrapper

[Ian Lawrence Barwick]

2022年10月17日(月) 16:36 Rama Krishnan :
>
> Hi all,
>
> What Is the difference between dblink and foreign data wrapper?

Basically, dblink enables you to execute individual queries on a remote
PostgreSQL server via a function and use the results in a local query e.g.:

  SELECT *
  FROM dblink('myconn', 'SELECT aid, bid, abalance FROM
pgbench_accounts ORDER BY 1')

whereas a foreign data wrapper enables you to query relations on a remote
server (which can also be a data source other than PostgreSQL) directly
within the local query.

Regards

Ian Barwick

could not find shared library for Python

[jacktby]

I use CentOS7 and upgrade python2.7 to python3.7, but it gives me an error "could not find shared library for Python",I use the newest code from github repo, how should I do?

 


jacktbyjack...@gmail.com


 

Re: 回复：回复：回复：A question about leakproof

[Tom Lane]

"qiumingcheng"  writes:
> 2. What's the reason about the function timestamp_gt_timestampz may cause 
> data leakage? Can you explain how it causes data leakage?

It's capable of throwing an error (see
timestamp2timestamptz_opt_overflow).  Now, maybe that's unreachable, or
maybe we could rerrange things to remove it.  But there's still enough
code underneath the timezone conversion requirement that I'd be very
hesitant to apply a leakproof marking.  In short: it might be leakproof
in practice, but we don't wish to offer a guarantee.

regards, tom lane

Re: 回复：回复：回复：A question about leakproof

[Laurenz Albe]

On Mon, 2022-10-17 at 16:24 +0800, qiumingcheng wrote:
> > "you seem to be imagining that changes in a query's plan on the basis of 
> > changes
> > in collected statistics have something to do with this.  They do not."
>
> 1. My understanding of the above paragraph is that for the same view and 
> different users,
>the proleakproof=false attribute of the function will not lead to 
> inconsistent plans,
>but my actual test result is that proleakproof=false will lead to 
> inconsistent plans.

The above says "on the basis of changes in collected statistics".  The 
different execution
you see is not because the statistics are different, but because the 
permissions of the
users are different.

> 2. What's the reason about the function timestamp_gt_timestampz  may  cause 
> data leakage?
>Can you explain how it causes data leakage?

I don't know the reason in this case.  You could look at the source code, 
perhaps it is
possible to cause error messages that can give you some clue as to the value 
that you
compare with.  But perhaps, as Tome said, it is just that nobody scrutinized 
the function
hard enough to exclude that something like that can happen.

Yours,
Laurenz Albe

Re: could not find shared library for Python

[Rob Sargent]

> On Oct 17, 2022, at 8:07 AM, jacktby  wrote:
> 
>  
>  
> I use CentOS7 and upgrade python2.7 to python3.7, but it gives me an error 
> "could not find shared library for Python",I use the newest code from github 
> repo, how should I do?
>   
> jacktby
> jack...@gmail.com
>  
> Where
>  exactly is your shared lib for python3?  You may have to reconfigure the 
> build giving it that information.

Re: could not find shared library for Python

[Adrian Klaver]

On 10/17/22 07:07, jacktby wrote:



I use CentOS7 and upgrade python2.7 to python3.7, but it gives me an


How did you upgrade from Python 2.7 to 3.7?

If you run python at the command line do you get the Python 3.7 
interpreter?



error "could not find shared library for Python",I use the newest
code from github repo, how should I do?


jacktby
jack...@gmail.com




--
Adrian Klaver
adrian.kla...@aklaver.com

Re: could not find shared library for Python

[jacktby]

 


jacktbyjack...@gmail.com


 

  
 Replied Message 
  
  

  

 From 


Adrian Klaver


  
  

 Date 


10/17/2022 22:54

  
  

 To 


 
  
jacktby
,
  
  
pgsql-general@lists.postgresql.org

  

  
  

 Subject 


  Re: could not find shared library for Python

  

  
  On 10/17/22 07:07, jacktby wrote:   I use CentOS7 and upgrade python2.7 to python3.7, but it gives me anHow did you upgrade from Python 2.7 to 3.7?If you run python at the command line do you get the Python 3.7 interpreter? error "could not find shared library for Python",I use the newest code from github repo, how should I do?  	 jacktby jack...@gmail.com  -- Adrian Klaveradrian.kla...@aklaver.com

Re: could not find shared library for Python

[Adrian Klaver]

On 10/17/22 07:56, jacktby wrote:






Please:

1) Do not top post. Do inline or bottom posting.

2) Do not use images, copy and paste text.

3) Answer from previous post:

How did you upgrade from Python 2.7 to 3.7?

and

If you run python at the command line do you get the Python 3.7
interpreter?

So type python and hit enter.



--
Adrian Klaver
adrian.kla...@aklaver.com

回复：回复：回复：回复：A question about leakproof

[qiumingcheng]

> It's capable of throwing an error (see timestamp2timestamptz_opt_overflow).
Yes, It's capable of throwing an error(timestamp out of range) , but the 
message "timestamp out of range" is not sensitive information. Only from this 
function(timestamp_gt_timestamptz), can it be marked as leakproof?
--
发件人：Tom Lane 
发送时间：2022年10月17日(星期一) 22:07
收件人：qiumingcheng 
抄　送：Laurenz Albe ; Julien Rouhaud 
; pgsql-general ; 
yuexingzhi 
主　题：Re: 回复：回复：回复：A question about leakproof
"qiumingcheng"  writes:
> 2. What's the reason about the function timestamp_gt_timestampz may cause 
> data leakage? Can you explain how it causes data leakage?
It's capable of throwing an error (see
timestamp2timestamptz_opt_overflow). Now, maybe that's unreachable, or
maybe we could rerrange things to remove it. But there's still enough
code underneath the timezone conversion requirement that I'd be very
hesitant to apply a leakproof marking. In short: it might be leakproof
in practice, but we don't wish to offer a guarantee.
 regards, tom lane

Re: 回复：回复：回复：回复：A question about leakproof

[Tom Lane]

"qiumingcheng"  writes:
> Yes, It's capable of throwing an error(timestamp out of range) , but the
> message "timestamp out of range" is not sensitive information.

Really?  Whether that's true at all is a matter of opinion.  There's
also the prospect that somebody could determine the value of a
supposedly-unreadable timestamp by seeing how big an interval could
be added to it without overflow.  Maybe that's infeasible because of
timestamp_pl_interval not being marked leakproof, but then we're
getting into precisely the sort of conditional-on-other-assumptions
reasoning that we don't want to indulge in.

> Only from this function(timestamp_gt_timestamptz), can it be marked as 
> leakproof?

Project policy is that we will not mark a function as leakproof unless
it's evident from the text of the function that it can't throw errors.
I don't see a good argument for making a exception for this one.

regards, tom lane

回复：回复：回复：回复：回复：A question about leakproof

[qiumingcheng]

OK, got it. Thank you very much.
--
发件人：Tom Lane 
发送时间：2022年10月18日(星期二) 00:27
收件人：qiumingcheng 
抄　送：Laurenz Albe ; Julien Rouhaud 
; pgsql-general ; 
yuexingzhi 
主　题：Re: 回复：回复：回复：回复：A question about leakproof
"qiumingcheng"  writes:
> Yes, It's capable of throwing an error(timestamp out of range) , but the
> message "timestamp out of range" is not sensitive information.
Really? Whether that's true at all is a matter of opinion. There's
also the prospect that somebody could determine the value of a
supposedly-unreadable timestamp by seeing how big an interval could
be added to it without overflow. Maybe that's infeasible because of
timestamp_pl_interval not being marked leakproof, but then we're
getting into precisely the sort of conditional-on-other-assumptions
reasoning that we don't want to indulge in.
> Only from this function(timestamp_gt_timestamptz), can it be marked as 
> leakproof?
Project policy is that we will not mark a function as leakproof unless
it's evident from the text of the function that it can't throw errors.
I don't see a good argument for making a exception for this one.
 regards, tom lane