On Tue, Sep 11, 2018 at 12:02:50PM +0900, Michael Paquier wrote:
> Hence, intrinsically, we are in contradiction with the upstream docs. I
> have worked on the problem with the patch, which works down to OpenSSL
> 0.9.8, and should fix your issue. This is based on what you sent
> previously, exce
On Mon, Sep 10, 2018 at 02:52:00PM +, Alessandro Gherardi wrote:
> I changed the implementation of the other SHA digests to use EVP
> also. I verified that, with these changes, scram-sha-256 works when
> FIPS is enabled.
Hm... I have spent a couple of hours setting up a CentOS 7 VM with FIPS
I changed the implementation of the other SHA digests to use EVP also.
I verified that, with these changes, scram-sha-256 works when FIPS is enabled.
sha2.h.diff
Description: Binary data
sha2_openssl.c.diff
Description: Binary data
Hi Ron
On 9/8/18 4:26 PM, Ron wrote:
Googled "postgresql disk partitioning" and "postgresql volume
partitioning" without much success.
Is the best practice volume partitioning:
/Database/9.6/data
/Database/9.6/data/pg_log
/Database/9.6/data/pg_xlog
where /var/lib/pgsql/9.6 (on RHEL6) is a s
On 9/10/18 6:43 AM, Csaba Ragasits wrote:
I think I found the solution.
When I set this parameter on the pg10 client connection, the pg10 REAL
value format same as the pg83 value:
SET extra_float_digits = 0;
Interesting, because the default value is 0 in the postgresql.conf:
#extra_float_dig
On 9/10/18 6:43 AM, Csaba Ragasits wrote:
I think I found the solution.
When I set this parameter on the pg10 client connection, the pg10 REAL
value format same as the pg83 value:
In your previous post you mentioned both 9.3 and 8.3.
Is 8.3 the actual version you are migrating from?
SET e
"Peter J. Holzer" writes:
> On 2018-09-10 11:57:42 +0300, Achilleas Mantzios wrote:
>> On 10/09/2018 11:22, Csaba Ragasits wrote:
>>> Field type: REAL
>>> pg93: 2.2
>>> pg10: 2.2005
>> Those have to do with rounding. Precision for real is 6 decimal
>> digits. Your difference is on the 8-th di
I think I found the solution.
When I set this parameter on the pg10 client connection, the pg10 REAL
value format same as the pg83 value:
SET extra_float_digits = 0;
Interesting, because the default value is 0 in the postgresql.conf:
#extra_float_digits = 0 # min -15, max 3
Do y
Arup Rakshit wrote:
> I am learning at this point how index works in DBMS. So I am looking for a
> very broad explanation to clear my basics.
>
> I have an index defined "inspector_tool_idx4_1" UNIQUE, btree (company_id,
> item_code, deleted_at).
> Now I am using the *company_id* column in the w
Greetings,
* Arup Rakshit (a...@zeit.io) wrote:
> I would like to ask one more question related to this topic. When I take a
> dump from production, and restore it to development DB, what are the commands
> I generally need to run to dev deb quack close to production?
The best way to get a prod
Hello Stephen,
I would like to ask one more question related to this topic. When I take a dump
from production, and restore it to development DB, what are the commands I
generally need to run to dev deb quack close to production?
Thanks,
Arup Rakshit
a...@zeit.io
> On 10-Sep-2018, at 4:58 P
Thanks Stephen. After running the vacuum on the table it worked.
inspection_development=# explain analyze select item_code from
inspector_tool_components where company_id =
'7881ff2e-0557-4734-9da8-2d33072ff1ef';
QUERY
PLA
Greetings,
* Arup Rakshit (a...@zeit.io) wrote:
> I have an index defined "inspector_tool_idx4_1" UNIQUE, btree (company_id,
> item_code, deleted_at). Now I am using the *company_id* column in the where
> clause, and the selecting just the *item_code* field for all matching rows. I
> expected h
Hello All,
I am learning at this point how index works in DBMS. So I am looking for a very
broad explanation to clear my basics.
I have an index defined "inspector_tool_idx4_1" UNIQUE, btree (company_id,
item_code, deleted_at). Now I am using the *company_id* column in the where
clause, and th
On 2018-09-10 11:57:42 +0300, Achilleas Mantzios wrote:
> On 10/09/2018 11:22, Csaba Ragasits wrote:
> Hello,
>
> We would like to migrate our old databases to new postgres server,
> with the simple backup-restore process. The process run fine
> without errors but when we're check
On 10/09/2018 11:22, Csaba Ragasits wrote:
Hello,
We would like to migrate our old databases to new postgres server, with the simple backup-restore process. The process run fine without errors but when we're checking the source and the migrated
datas as field level, we found the following diff
Hello,
We would like to migrate our old databases to new postgres server, with the
simple backup-restore process. The process run fine without errors but when
we're checking the source and the migrated datas as field level, we found
the following differences:
For example:
Field type: TIMESTAMP
17 matches
Mail list logo
