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
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
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:
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:
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
>
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
-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
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
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 -
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
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.
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
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
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
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
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
22 matches
Mail list logo
