date:20190626

Re: mcvstats serialization code is still shy of a load

2019-06-26 Thread Tomas Vondra


On Tue, Jun 25, 2019 at 11:52:28PM -0400, Tom Lane wrote:

I'm seeing a reproducible bus error here:

#0  0x00417420 in statext_mcv_serialize (mcvlist=0x62223450, stats=Variable 
"stats" is not available.
)
   at mcv.c:785
785 memcpy(ITEM_BASE_FREQUENCY(item, ndims), 
&mcvitem->base_frequency, sizeof(double));

What appears to be happening is that since ITEM_BASE_FREQUENCY is defined as

#define ITEM_BASE_FREQUENCY(item,ndims) ((double *) (ITEM_FREQUENCY(item, 
ndims) + 1))

the compiler is assuming that the first argument to memcpy is
double-aligned, and it is generating code that depends on that being
true, and of course it isn't true and kaboom.

You can *not* cast something to an aligned pointer type if it's not
actually certain to be aligned suitably for that type.  In this example,
even if you wrote "(char *)" in front of this, it wouldn't save you;
the compiler would still be entitled to believe that the intermediate
cast value meant something.  The casts in the underlying macros
ITEM_FREQUENCY and so on are equally unsafe.



OK. So the solution is to ditch the casts altogether, and then do plain
pointer arithmetics like this:

#define ITEM_INDEXES(item)  (item)
#define ITEM_NULLS(item,ndims)  (ITEM_INDEXES(item) + (ndims))
#define ITEM_FREQUENCY(item,ndims)  (ITEM_NULLS(item, ndims) + (ndims))
#define ITEM_BASE_FREQUENCY(item,ndims) (ITEM_FREQUENCY(item, ndims) + 
sizeof(double))

Or is that still relying on alignment, somehow?


regards

--
Tomas Vondra  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

inheritance of connection paramters when using \c

2019-06-26 Thread nagaura.ryo...@fujitsu.com

Hello!

\c is followed by [-reuse-previous=on/off] positional syntax | conninfo
Using \c -reuse-previous=on positional syntax or \c positional syntax without 
-reuse-previous option, some parameters which were omitted or notated as "-" 
will be reused in the new connection.
The target is only "dbname", "user", "host", "port" in the current 
implementation.
# details in [1]
When we discussed in [2], this topic came out.
Although I'm not heavy psql user, I want it to inherit connection parameters 
and Fabien-san does too.

My new specification:
\c inherits all the unspecified connection parameters in PQconninfoOptions in 
cases below.
a) \c -reuse-previous=on positional syntax
b) \c positional syntax
This is just an expansion of the target of inheritance of parameters from the 
current specification.

I have an item to talk about.
It is whether the message which indicates connection information to users has 
to have more information such as
You are now connected to database "TomANDJelly" as user "nyannyan" with some 
parameters [reused | defaults].
# after "nyannyan"

Do you have any thoughts?

[1] https://www.postgresql.org/docs/12/app-psql.html
[2] 
https://www.postgresql.org/message-id/flat/EDA4195584F5064680D8130B1CA91C45367328@G01JPEXMBYT04
Best regards,
-
Ryohei Nagaura

[patch]socket_timeout in interfaces/libpq

2019-06-26 Thread nagaura.ryo...@fujitsu.com

Hello all.

First, I'd like to appreciate with all your reviewing and discussion in the
last CommitFest[1].

I don't think that the rest one of my proposals has been rejected completely,
so I want to restart discussion.

It is a timeout parameter in interfaces/libpq.

Consider some situations where some happening occurred a server and it became
significant busy. e.g., what I and Tsunakawa-san have illustrated[2][3].
These server's bad condition(i.e., non-functional server) could cause clients'
infinite waiting because it is not always possible for current timeout
parameters in backend side to fire.
Under such server's bad condition, control should be passed to the client after
a certain period of time, and just a timeout disconnection corresponds to it.
Also, in such situations the backend parameters may not work, so we need to
implement the timeout parameters on the client side.

It is preferable to implement this parameter in PQwait() where clients can wait
endlessly.
However this can do unintended timeout when setting socket_timeout <
statement_timeout(etc. some other timeout parameters).
Thus documentation warns this.

FYI, a similarly parameter socketTimeout is in pgJDBC[4].
Do you have any thoughts?

P.S.
Fabien-san,
I'll build another thread and let's discussion there about \c's taking care of
connection parameters you have pointed out!

[1]
https://www.postgresql.org/message-id/flat/EDA4195584F5064680D8130B1CA91C45367328@G01JPEXMBYT04
[2]
https://www.postgresql.org/message-id/EDA4195584F5064680D8130B1CA91C45367328%40G01JPEXMBYT04
[3]
https://www.postgresql.org/message-id/0A3221C70F24FB45833433255569204D1FBC7561%40G01JPEXMBYT05
[4]
https://jdbc.postgresql.org/documentation/head/connect.html#connection-parameters

47 matches

Mail list logo