On Thu, May 2, 2019 at 4:12 PM Alvaro Herrera
wrote:
> On 2019-May-02, Ray Cote wrote:
>
> > Does anyone have a hint on how I'd go about debugging why PostgreSQL 11
> is
> > not starting on CentOS 7?
> > Was running fine for several weeks then fails to come up after a reboot.
>
> How are you
On 2019-May-02, Ray Cote wrote:
> Does anyone have a hint on how I'd go about debugging why PostgreSQL 11 is
> not starting on CentOS 7?
> Was running fine for several weeks then fails to come up after a reboot.
How are you getting it started after the reboot? If you're not using
systemd
On 5/2/19 12:20 PM, Ray Cote wrote:
Spoke too soon, Not coming back after a boot. Seems I can install, run,
but not reboot!
What happens if change the server name back?
Might want to take a look at what is in postgresql-11.service also.
On Thu, May 2, 2019 at 3:18 PM Ray Cote
--
Adrian
Spoke too soon, Not coming back after a boot. Seems I can install, run, but
not reboot!
On Thu, May 2, 2019 at 3:18 PM Ray Cote
wrote:
>
>
> On Thu, May 2, 2019 at 2:57 PM Adrian Klaver
> wrote:
>
>> On 5/2/19 11:22 AM, Ray Cote wrote:
>> > Does anyone have a hint on how I'd go about debugging
On Thu, May 2, 2019 at 2:57 PM Adrian Klaver
wrote:
> On 5/2/19 11:22 AM, Ray Cote wrote:
> > Does anyone have a hint on how I'd go about debugging why PostgreSQL 11
> > is not starting on CentOS 7?
> > Was running fine for several weeks then fails to come up after a reboot.
> >
> > I did change
On 5/2/19 11:22 AM, Ray Cote wrote:
Does anyone have a hint on how I'd go about debugging why PostgreSQL 11
is not starting on CentOS 7?
Was running fine for several weeks then fails to come up after a reboot.
I did change the name of the CentOS7 server, but I don't expect that to
have any
Does anyone have a hint on how I'd go about debugging why PostgreSQL 11 is
not starting on CentOS 7?
Was running fine for several weeks then fails to come up after a reboot.
I did change the name of the CentOS7 server, but I don't expect that to
have any effect on the database.
I'm running
I have a query that is being ran on PGSQL, and when queried at a fast rate
for large data sets, it is taking a long time to run because it isn't
making use of the available indexes. I found that changing the filter from
multiple OR's to an IN clause causes the right index to be used. Is there a
On 05/02/2019 05:36 PM, Daniel Verite wrote:
rihad wrote:
Thanks for the reply. Do you know what would a "decent" ICU collation be
to bind to a field's schema definition so it would mimic a UTF-8
encoding for a multilingual column? Maybe und-x-icu? We aren't as much
concerned about
Laurenz,
I thought I needed the prototype table to be able to define functions and
procedures that refer to the temporary table but do not create it.
Perhaps my assumption that I need the table to exist (whether as a temporary
table or as a permanent table) in order to define the
Have you tried adding
ESCAPE '*\*' to the PostgreSQL COPY command?
https://www.postgresql.org/docs/10/sql-copy.html
On Thu, May 2, 2019 at 12:54 PM Rob Sargent wrote:
>
> On 5/2/19 9:19 AM, Guntry Vinod wrote:
> > Hi Adrian\Kiran,
> >
> > Below is the issue.
> >
> > We are migrating from Db2
On 5/2/19 9:19 AM, Guntry Vinod wrote:
Hi Adrian\Kiran,
Below is the issue.
We are migrating from Db2 to Postgre.
The Db2 dump consists of back Slash \ with in the data [dump] , but postgre is
not escaping the Slash.
For example if name consist of Vinod\G after the inserting the dump the
Hi Adrian\Kiran,
Below is the issue.
We are migrating from Db2 to Postgre.
The Db2 dump consists of back Slash \ with in the data [dump] , but postgre is
not escaping the Slash.
For example if name consist of Vinod\G after the inserting the dump the value
in postgre is VinodG where as I
On 5/2/19 8:19 AM, Guntry Vinod wrote:
Hi Adrian\Kiran,
Below is the issue.
We are migrating from Db2 to Postgre.
The Db2 dump consists of back Slash \ with in the data [dump] , but postgre is
not escaping the Slash.
For example if name consist of Vinod\G after the inserting the dump the
On 5/2/19 12:57 AM, Francisco Olarte wrote:
Adrian:
On Wed, May 1, 2019 at 8:14 PM Adrian Klaver wrote:
.
select '2019-05-02'::timestamp <= '2019-05-01 24:00'::timestamp;
And you'll see and out of range date selected.
Technically it is correct as:
test_(postgres)# select
On 5/2/19 7:34 AM, Adrian Klaver wrote:
On 5/2/19 7:30 AM, ravikris...@mail.com wrote:
> We have dump from DB2 and trying to upload it Postgre.
DB2 export command has an option to export it as CSV which quotes data
so that any embedded
lines or special characters inside the data is treated
On 5/2/19 7:30 AM, ravikris...@mail.com wrote:
> We have dump from DB2 and trying to upload it Postgre.
DB2 export command has an option to export it as CSV which quotes data
so that any embedded
lines or special characters inside the data is treated fine. Does the
csv format has quotes
> We have dump from DB2 and trying to upload it Postgre.
DB2 export command has an option to export it as CSV which quotes data so that any embedded
lines or special characters inside the data is treated fine. Does the csv format has quotes enclosing it ?
On 5/2/19 5:20 AM, Guntry Vinod wrote:
Hi Team,
We have dump from DB2 and trying to upload it Postgre.
What program did you use to take the dump?
How are you importing the data into Postgres(note the 's')?
What is the exact error message?
The records which has \(back ward) are failing to
Hi Team,
We have dump from DB2 and trying to upload it Postgre.
The records which has \(back ward) are failing to import.
Can anyone in the team help us to resolve the issue.
Can you also let us know if we are posting the question to the right team.
Regards,
Vinod
select * from (select id, my_age, ur_age as urage from datatable where
agegp != 'S') m where m.myage <> m.urage
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
rihad wrote:
> Thanks for the reply. Do you know what would a "decent" ICU collation be
> to bind to a field's schema definition so it would mimic a UTF-8
> encoding for a multilingual column? Maybe und-x-icu? We aren't as much
> concerned about their sortability in most cases, we just
Mark Zellers wrote:
> One of the issues I have run into in migrating from Oracle to PostgreSQL is
> the difference in temporary table behavior.
> I've come up with what I think is a cunning plan, but I wonder if anyone with
> more PostgreSQL understanding can shoot holes in it.
>
> Oracle
Adrian:
On Wed, May 1, 2019 at 8:14 PM Adrian Klaver wrote:
.
> > select '2019-05-02'::timestamp <= '2019-05-01 24:00'::timestamp;
> > And you'll see and out of range date selected.
>
> Technically it is correct as:
> test_(postgres)# select '2019-05-02'::timestamp;
>timestamp
>
One of the issues I have run into in migrating from Oracle to PostgreSQL is the
difference in temporary table behavior. I've come up with what I think is a
cunning plan, but I wonder if anyone with more PostgreSQL understanding can
shoot holes in it.
Oracle defines their temporary tables
On 05/02/2019 12:26 AM, Peter Geoghegan wrote:
On Mon, Apr 29, 2019 at 7:45 AM rihad wrote:
Hi. Today we run pg_ctl promote on a slave server (10.7) and started
using it as a master. The OS also got upgraded FreeBSD 10.4 -> FreeBSD
11.2. And you guessed it, most varchar indexes got corrupted
Assuming you get the database back online, I would suggest you put a
procedure in place to monitor disk space and alert you when it starts to
get low.
--
Mike Nolan
27 matches
Mail list logo
