Not in Europe, but have worked a bit with medical records systems in the
USA, including sharing across providers.
The primary key of the user is _should_ be system generated, and this is
meaningless from a user identity standpoint. If you encrypt user name and
other significant personal data on t
David,
> Tradeoffs? As I mentioned. Surely the offset per tuple actually must
> be stored somewhere, and that storage is not free.
What offset do you mean?
Consider an example. Let's define a table as follows:
create table test(
name1 varchar(255),
name2 varchar(255)
);
And add one tuple
in
On Wed, 27 Mar 2019 at 04:16, Павлухин Иван wrote:
> It seems that an innodb layout is better at least for reading. So, it
> is still unclear for me why postgresql does not employ similar layout
> if it can give significant benefits.
Tradeoffs? As I mentioned. Surely the offset per tuple actually
Nope I tried that's command and getting above error control file missing.
On Tue, Mar 26, 2019, 22:53 Adrian Klaver wrote:
> On 3/26/19 8:56 AM, Prakash Ramakrishnan wrote:
> > Hi Team,
> >
> > We are getting below error in production server please do the needful.
> >
> > ==> psql
> > psql (11.2
I did postgres 11.2 version using yum option this file only Missing and
using rhel 7.5 version.
On Tue, Mar 26, 2019, 23:07 Adrian Klaver wrote:
> On 3/26/19 10:32 AM, Prakash Ramakrishnan wrote:
> > Nope I tried that's command and getting above error control file missing.
>
> Well it should be
Hello again Brad, and hello Tom. Thanks for writing, and Tom I'll add some
extra thanks for the many google searches over the years which have been
answered by your posts. :)
It seems there's been some confusion on the data flow so I'll try to explain.
The original "source" I referred to was our
On 3/26/19 10:43 AM, Prakash Ramakrishnan wrote:
I did postgres 11.2 version using yum option this file only Missing and
using rhel 7.5 version.
If you are using the PGDG repos then it looks like you need:
https://yum.postgresql.org/testing/11/redhat/rhel-7-x86_64/repoview/letter_p.group.htm
On 3/26/19 10:43 AM, Prakash Ramakrishnan wrote:
I did postgres 11.2 version using yum option this file only Missing and
using rhel 7.5 version.
Please respond to all questions below:
YUM using what repo's?
From command line what does pg_config show?
Have you looked in:
/usr/pgsql-11/share/
On 3/26/19 10:32 AM, Prakash Ramakrishnan wrote:
Nope I tried that's command and getting above error control file missing.
Well it should be a different message something like:
/usr/pgsql-11/share/extension/pltctl.control": No such file or directory
correct?
If the above is the case then:
1
On 3/26/19 8:56 AM, Prakash Ramakrishnan wrote:
Hi Team,
We are getting below error in production server please do the needful.
==> psql
psql (11.2)
Type "help" for help.
> AIBE01PR=# create extension plctl;
> ERROR: could not open extension control file
> "/usr/pgsql-11/share/extension/plc
Hi Team,
We are getting below error in production server please do the needful.
==> psql
psql (11.2)
Type "help" for help.
> AIBE01PR=# create extension plctl;
> ERROR: could not open extension control file
> "/usr/pgsql-11/share/extension/plctl.control": No such file or directory
RHEL-7.5
--
On 3/26/19 9:08 AM, Moreno Andreo wrote:
Il 26/03/2019 15:24, Adrian Klaver ha scritto:
On 3/26/19 7:19 AM, Moreno Andreo wrote:
Hello folks :-)
Is there any workaround to implement key encryption without breaking
relational integrity?
This is going to need more information.
OK, I'll try
On Tue, Mar 26, 2019 at 9:39 AM Kevin Brannen wrote:
> -Original Message-
> From: Moreno Andreo
> Sent: Tuesday, March 26, 2019 11:09 AM
> To: Adrian Klaver ; PostgreSQL mailing lists <
> pgsql-gene...@postgresql.org>
> Subject: Re: Key encryption and relational integrity
>
> In a master
-Original Message-
From: Moreno Andreo
Sent: Tuesday, March 26, 2019 11:09 AM
To: Adrian Klaver ; PostgreSQL mailing lists
Subject: Re: Key encryption and relational integrity
In a master-detail relation, I need to encrypt one of master table PK or detail
table FK, in order to achieve
Il 26/03/2019 15:24, Adrian Klaver ha scritto:
On 3/26/19 7:19 AM, Moreno Andreo wrote:
Hello folks :-)
Is there any workaround to implement key encryption without breaking
relational integrity?
This is going to need more information.
OK, I'll try to be as clearer as I can
For starters 'ke
> On Mar 26, 2019, at 8:08 AM, Adrian Klaver wrote:
>
> On 3/25/19 5:10 PM, Rob Sargent wrote:
>> PG10.7, Centos7
>> On Mar15 we filled our default tablespace/WAL partition. Cleaned up some
>> old dumps and restarted. pg_wal had apparently exploded but cleaned itself
>> up by the next day. O
Hi David,
Thank you for your response. I understand that postgresql behaves good
for fixed-length NOT NULL columns stored in the beginning of a tuple.
But let's imagine a use case when we just have many NOT NULL
variable-length columns. With current storage format accessing a first
column is faste
On 2019-03-25 5:44 PM, Frank wrote:
On reflection, I have not been consistent with my use of indexes, and I
think that will affect the query plan.
There are at least two issues -
1. The first table defined in the VIEW is ccc.ar_tran_inv. It has the
following index -
"arinv_cust_date
On 3/26/19 7:19 AM, Moreno Andreo wrote:
Hello folks :-)
Is there any workaround to implement key encryption without breaking
relational integrity?
This is going to need more information. For starters 'key' has separate
meanings for encryption and RI. I could make some guesses about what you
Hello folks :-)
Is there any workaround to implement key encryption without breaking
relational integrity?
Thanks
Moreno.-
"Brad Nicholson" writes:
> Thomas Tignor wrote on 03/25/2019 08:25:49 PM:
>> Thanks for writing. As I mentioned to Vijay, the "source" is a JVM
>> using the postgres v42.0.0 JDBC driver. I do not believe we have any
>> explicit encoding set, and so I expect the client encoding is
>> SQL_ASCII. Th
On 3/25/19 5:10 PM, Rob Sargent wrote:
PG10.7, Centos7
On Mar15 we filled our default tablespace/WAL partition. Cleaned up
some old dumps and restarted. pg_wal had apparently exploded but
cleaned itself up by the next day. On Mar16 I ran CHECKPOINT in all
databases on that server (except te
Thomas Tignor wrote on 03/25/2019 08:25:49 PM:
>
> Hi Brad,
> Thanks for writing. As I mentioned to Vijay, the "source" is a JVM
> using the postgres v42.0.0 JDBC driver. I do not believe we have any
> explicit encoding set, and so I expect the client encoding is
> SQL_ASCII. The DB is most defi
Hi Laurenz. Thanks for writing. I can tell you that while the error message
usually identifies just one byte (though sometimes up to three), inspection of
the data has frequently shown several bytes impacted. It often seems that the
corruption begins at one point in the row and continues to the
Re: Jeff Janes 2019-03-23
> On Fri, Mar 22, 2019 at 8:04 AM Steve Atkins wrote:
> > > On Mar 22, 2019, at 10:56 AM, Christian Henz
> > There's the BigSQL fork, which had at least some minimal support
> > for 10. I've no idea whether it's had / needs anything for 11
>
> I just installed BigSQL'
Thomas Tignor wrote:
> We are experiencing intermittent DB corruption in postgres 9.5.14. We are
> trying to
> identify and eliminate all sources. We are using two independent services for
> data
> replication, Slony-I v2.2.6 and a custom service developed in-house. Both are
> based
> on COPY op
Dave Cramer schrieb am 25.03.2019 um 22:33:
> Thomas,
>
> Any chance it would run under graalvm getting rid of the need for the JVM ?
>
> Dave Cramer
It's hard to tell, but I'd say about 70-80% of my users use Windows, so GraalVM
is not an option.
I also can't bundle it for non-Windows users a
27 matches
Mail list logo
