Hello.
At Tue, 18 Feb 2020 12:43:21 -0800, Adrian Klaver
wrote in
> test=> UPDATE t_update SET F1 = '02/23/2020'::unknown;
> UPDATE 1
>
> test=> UPDATE t_update SET F1 = (CASE WHEN ('02/18/2020' IS NULL )
> THEN ('02/18/2020' ) ELSE ('02/19/2020') END)::unknown;
> ERROR: failed to find convers
On Tue, 2020-02-18 at 15:06 -0500, Stephen Frost wrote:
>
> Policies, also being part of the overall privilege system, could
> certainly be looked at in a similar light as being different from
> triggers and indexes...
While I think I agree with Stephen here, I don't have a vested interest
in an
On 2/18/20 2:07 PM, Bellrose, Brian wrote:
I found a repository that offered it and added the repo.
https://download.opensuse.org/repositories/home:vjt:ifad/openSUSE_Leap_42.1/home:vjt:ifad.repo
Only time will tell if that was a wise decision. I only need to it to get me
through my upgrade. Mov
I found a repository that offered it and added the repo.
https://download.opensuse.org/repositories/home:vjt:ifad/openSUSE_Leap_42.1/home:vjt:ifad.repo
Only time will tell if that was a wise decision. I only need to it to get me
through my upgrade. Moving all these to RHEL 8.1 and Postgres 11.7.
On 2/18/20 1:56 PM, Bellrose, Brian wrote:
Yes,
S | Name | Summary
| Type
--+---+-+
i | postgresql94 | Ba
Yes,
S | Name | Summary
| Type
--+---+-+
i | postgresql94 | Basic Clients and Utilities for PostgreSQL
On 2/18/20 1:22 PM, Bellrose, Brian wrote:
I used zypper to install postgres. Postgres is fine... Running 9.4.25 that I
updated today. So you have krb5-devel... Ok, good to know. Seems like that may
be the missing link. At least I hope it is the only one.
Was postgresql94-devel also installed
I used zypper to install postgres. Postgres is fine... Running 9.4.25 that I
updated today. So you have krb5-devel... Ok, good to know. Seems like that may
be the missing link. At least I hope it is the only one.
Brian
-Original Message-
From: Adrian Klaver
Sent: Tuesday, February 18,
On 2/18/20 12:54 PM, Bellrose, Brian wrote:
Yes, I understand that this OS is very old. I can't help that. I was handed
this. The reason I am trying to install pglogical is so that I can upgrade and
get off this OS. Our requirements are for limited downtime so pglocical is best
bet. At least I
Yes, I understand that this OS is very old. I can't help that. I was handed
this. The reason I am trying to install pglogical is so that I can upgrade and
get off this OS. Our requirements are for limited downtime so pglocical is best
bet. At least I thought it was.
Yes, I followed the source i
On 2/18/20 11:39 AM, Bellrose, Brian wrote:
In the process of trying to use pglogical to upgrade from 9.4 to 11.7.
Current OS is openSUSE Leap 42.1. Downloaded pglogical-2.2.0.tar from
FYI 42.1 is coming up on 3 years past EOL so you might have general
issues with out of date libraries.
2ns
On 2/18/20 10:51 AM, John W Higgins wrote:
Good Morning,
NOTE: From my research online, I found that typecasting works and
also the error from the database suggests typecasting.
This statement works:
UPDATE t_update SET F1 = (CASE WHEN (?::timestamp(6) IS NULL ) THEN
(?::
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Marc Munro writes:
> > On Mon, 2020-02-17 at 22:48 -0500, Tom Lane wrote:
> >> An RLS policy is a table "subsidiary object" so it only depends indirectly
> >> on the extension that owns the table.
>
> > Yep, I get that, and I see the dependency
In the process of trying to use pglogical to upgrade from 9.4 to 11.7. Current
OS is openSUSE Leap 42.1. Downloaded pglogical-2.2.0.tar from 2nsQuadrant site.
I am getting the following error during make clean all command:
o pglogical_worker.c
In file included from pglogical_worker.c:17:0:
/usr/
On 23/12/2016 13:41, Peter J. Holzer wrote:
> On 2016-12-09 16:52:05 +0800, Qiu Xiafei wrote:
>> I'm new to PG and want to implement my domain-specific system based on PG. I
>> wish to arrange my data as several tables in database and translate my DSL
>> into
>> SQL statements for query. Since one
Good Morning,
>
> NOTE: From my research online, I found that typecasting works and also
> the error from the database suggests typecasting.
>
> This statement works:
>
> UPDATE t_update SET F1 = (CASE WHEN (?::timestamp(6) IS NULL ) THEN
> (?::timestamp(6) ) ELSE (?::timestamp(6) ) END)
>
>
The
On Mon, 2020-02-17 at 22:48 -0500, Tom Lane wrote:
> Marc Munro writes:
> >
> An RLS policy is a table "subsidiary object" so it only depends
> indirectly
> on the extension that owns the table.
Yep, I get that, and I see the dependency chain in the catalog.
However an extension can create the
Hello,
Trying to find a way to perform a CASE statement without needing to
typecast. Research so far suggests that this is not possible, but I wanted
to check with the PSQL community to be sure.
Steps:
1. CREATE TABLE t_update (F1 timestamp(6) NULL )
2. Run statement UPDATE t_update SET F1 =
On Tue, Feb 18, 2020 at 12:10 PM Nagaraj Raj wrote:
>
> Below are the same configurations ins .conf file before and after updagrade
>
> show max_connections; = 1743
> show shared_buffers = "4057840kB"
> show effective_cache_size = "8115688kB"
> show maintenance_work_mem = "259MB"
> show checkpoin
Below are the same configurations ins .conf file before and after updagrade
show max_connections; = 1743show shared_buffers = "4057840kB"show
effective_cache_size = "8115688kB"show maintenance_work_mem = "259MB"show
checkpoint_completion_target = "0.9"show wal_buffers = "16MB"show
default_stat
On Tue, Feb 18, 2020 at 05:46:28PM +, Nagaraj Raj wrote:
after upgrade Postgres to v9.6.11 from v9.6.9 DB running out of memory issues
no world load has changed before and after upgrade.
spec: RAM 16gb,4vCore
Any bug reported like this or suggestions on how to fix this issue? I
appreciate
Marc Munro writes:
> On Mon, 2020-02-17 at 22:48 -0500, Tom Lane wrote:
>> An RLS policy is a table "subsidiary object" so it only depends indirectly
>> on the extension that owns the table.
> Yep, I get that, and I see the dependency chain in the catalog.
> However an extension can create the
Hello Folks,
We are having the issue with Logical Replication in Postgres 10.11
production environment that unable to get around.
Following is the production environment configuration
*PostgreSQL Version: 10.11OS: Ubuntu 16.04.3 LTS (Xenial Xerus)*
The error message frequently occurring in the
23 matches
Mail list logo