Re: terminating walsender process due to replication timeout

[Kyotaro HORIGUCHI]

Hello.

At Wed, 15 May 2019 10:04:12 +0300, ayaho...@ibagroup.eu wrote in 

> Hello,
> Thank You for the response.
> 
> Yes that's possible to monitor replication delay. But my questions were 
> not about monitoring network issues. 
> 
> I use exactly wal_sender_timeout=1s because it allows to detect 
> replication problems quickly.

Though I don't have an exact idea of your configuration, it seems
to me that your standby is simply getting behind more than one
second from the master. If you regard the fact as a problem of
replication, the configuration can be said to be finding the
problem correctly.

Since the keep-alive packet is sent in-band, it doesn't get to
the standby before already-sent-but-not-processed packets.

> So, I need clarification to the following  questions:
> Is  it possible to use exactly this configuration and be sure that it will 
> be work properly.
> What did I do wrong? Should I correct my configuration somehow?
> Is this the same issue  as mentioned here: 
> https://www.postgresql.org/message-id/e082a56a-fd95-a250-3bae-0fff93832...@2ndquadrant.com
>  
> ? If it is so, why I do I face this problem again?

It is not the same "problem". What was mentioned there is fast
network making the sender-side loop busy, which prevents
keepalive packet from sending.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Returning empty on insert

[Winanjaya Amijoyo]

Hi all,

when running query below, pid returns empty when inserting new record

WITH s AS (
   SELECT pid FROM test WHERE area = 'test5'
), i AS (
   INSERT INTO test (area)
   SELECT 'test5'
   WHERE NOT EXISTS (SELECT 1 FROM s)
   RETURNING pid
)
UPDATE area
SET last_update = CURRENT_TIMESTAMP
WHERE pid = (SELECT pid FROM s)
RETURNING pid;

what I missed?

please help

many thanks in advance

Regards

Win

Re: Returning empty on insert

[David Rowley]

On Thu, 16 May 2019 at 19:56, Winanjaya Amijoyo
 wrote:
> when running query below, pid returns empty when inserting new record
>
> WITH s AS (
>SELECT pid FROM test WHERE area = 'test5'
> ), i AS (
>INSERT INTO test (area)
>SELECT 'test5'
>WHERE NOT EXISTS (SELECT 1 FROM s)
>RETURNING pid
> )
> UPDATE area
> SET last_update = CURRENT_TIMESTAMP
> WHERE pid = (SELECT pid FROM s)
> RETURNING pid;

Isn't that because you're only inserting a value for the "area"
column. "pid" will end up either NULL or be set to the value of the
column's DEFAULT clause, if it has one.

You might also want to look at INSERT ON CONFLICT DO NOTHING if you
want that INSERT to work in concurrent environments. Docs in
https://www.postgresql.org/docs/current/sql-insert.html

-- 
 David Rowley   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: Returning empty on insert

[Winanjaya Amijoyo]

column pid is bigserial that I expect to return on both insert and update
I don't want to use ON CONFLICT since it would increasing the sequence
although it updating the data

On Thu, May 16, 2019 at 3:26 PM David Rowley 
wrote:

> On Thu, 16 May 2019 at 19:56, Winanjaya Amijoyo
>  wrote:
> > when running query below, pid returns empty when inserting new record
> >
> > WITH s AS (
> >SELECT pid FROM test WHERE area = 'test5'
> > ), i AS (
> >INSERT INTO test (area)
> >SELECT 'test5'
> >WHERE NOT EXISTS (SELECT 1 FROM s)
> >RETURNING pid
> > )
> > UPDATE area
> > SET last_update = CURRENT_TIMESTAMP
> > WHERE pid = (SELECT pid FROM s)
> > RETURNING pid;
>
> Isn't that because you're only inserting a value for the "area"
> column. "pid" will end up either NULL or be set to the value of the
> column's DEFAULT clause, if it has one.
>
> You might also want to look at INSERT ON CONFLICT DO NOTHING if you
> want that INSERT to work in concurrent environments. Docs in
> https://www.postgresql.org/docs/current/sql-insert.html
>
> --
>  David Rowley   http://www.2ndQuadrant.com/
>  PostgreSQL Development, 24x7 Support, Training & Services
>

Re: Returning empty on insert

[David Rowley]

On Thu, 16 May 2019 at 20:28, Winanjaya Amijoyo
 wrote:
> column pid is bigserial that I expect to return on both insert and update
> I don't want to use ON CONFLICT since it would increasing the sequence 
> although it updating the data

It's not very clear what you're trying to do here.

So, by "pid returns empty", you mean that the UPDATE updates 0 rows,
and you always expect it to update 1 row?   The UPDATE is going to
update 0 rows if either "s" is an empty relation, or there's no row in
"area" with the "pid" that's in "s".  "s" will be an empty relation if
"test" does not have any row matching WHERE area = 'test5'.

-- 
 David Rowley   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: Returning empty on insert

[Winanjaya Amijoyo]

Hi

What I want to archive here is:

When record not found then insert and return pid value or if not found then
update based on pid and again return its pid.

Please help.

Many thanks in advance.

Regards
Win

On Thu, 16 May 2019 at 15.47 David Rowley 
wrote:

> On Thu, 16 May 2019 at 20:28, Winanjaya Amijoyo
>  wrote:
> > column pid is bigserial that I expect to return on both insert and update
> > I don't want to use ON CONFLICT since it would increasing the sequence
> although it updating the data
>
> It's not very clear what you're trying to do here.
>
> So, by "pid returns empty", you mean that the UPDATE updates 0 rows,
> and you always expect it to update 1 row?   The UPDATE is going to
> update 0 rows if either "s" is an empty relation, or there's no row in
> "area" with the "pid" that's in "s".  "s" will be an empty relation if
> "test" does not have any row matching WHERE area = 'test5'.
>
> --
>  David Rowley   http://www.2ndQuadrant.com/
>  PostgreSQL Development, 24x7 Support, Training & Services
>
-- 
Kind regards,
Winanjaya
———-
Sent from my iPhone - Gmail MobIle.
My apologize for the typos & brevity.
———-

Re: Returning empty on insert

[David Rowley]

On Thu, 16 May 2019 at 21:13, Winanjaya Amijoyo
 wrote:
> When record not found then insert and return pid value or if not found then 
> update based on pid and again return its pid.

You could do something like:

WITH s AS (
   SELECT pid FROM test WHERE area = 'test5'
), i AS (
   INSERT INTO test (area)
   SELECT 'test5'
   WHERE NOT EXISTS (SELECT 1 FROM s)
   RETURNING pid
)
UPDATE area
SET last_update = CURRENT_TIMESTAMP
WHERE pid = (SELECT pid FROM s UNION SELECT pid FROM i)
RETURNING pid;

but be warned, it's could all fall over as soon as you have concurrent
sessions running this at the same time.  You could protect against
that by doing some advisory locking (
https://www.postgresql.org/docs/11/explicit-locking.html#ADVISORY-LOCKS
), or taking an access exclusive lock on "test".

-- 
 David Rowley   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

How to search using daterange (using gist)

[Winanjaya Amijoyo]

Hi All,

I have records as below that I inserted using exclusion gist constraint

user_idstart_date  end_date pid
001  2019-01-012019-02-101
001  2019-02-012019-03-122
001  2019-03-052019-06-153

I need to find records based on date range, so for example:

if I search using parameters 001, 2019-01-10, 2019-02-11 .. it will found
as pid 1
if I search using parameters 001, 2019-03-10, 2019-07-13 .. it will found
as pid 3
but if I search out of the date range, for example:
if I search using parameters 001, 2019-07-10, 2019-09-13 .. it will not
found as pid 0

how to search with the above scenario in postgresql?

please help

thanks
win

Re: How to search using daterange (using gist)

[Andreas Kretschmer]

Am 16.05.19 um 11:57 schrieb Winanjaya Amijoyo:

Hi All,

I have records as below that I inserted using exclusion gist constraint

user_id    start_date      end_date         pid
001          2019-01-01    2019-02-10        1
001          2019-02-01    2019-03-12        2
001          2019-03-05    2019-06-15        3

I need to find records based on date range, so for example:

if I search using parameters 001, 2019-01-10, 2019-02-11 .. it will 
found as pid 1
if I search using parameters 001, 2019-03-10, 2019-07-13 .. it will 
found as pid 3

but if I search out of the date range, for example:
if I search using parameters 001, 2019-07-10, 2019-09-13 .. it will 
not found as pid 0


how to search with the above scenario in postgresql?




can you please show us the table-definition? Are you sure there is an 
exclusion constraint?


with your data:

test=*# select * from demo;
 user_id | start_date |  end_date  | pid
-+++-
   1 | 2019-01-01 | 2019-02-10 |   1
   1 | 2019-02-01 | 2019-03-12 |   2
   1 | 2019-03-05 | 2019-06-15 |   3
(3 rows)

test=*# select * from demo where daterange(start_date, end_date,'[)') && 
daterange('2019-01-10','2019-02-11');

 user_id | start_date |  end_date  | pid
-+++-
   1 | 2019-01-01 | 2019-02-10 |   1
   1 | 2019-02-01 | 2019-03-12 |   2
(2 rows)

test=*# select * from demo where daterange(start_date, end_date,'[)') && 
daterange('2019-03-10','2019-07-13');

 user_id | start_date |  end_date  | pid
-+++-
   1 | 2019-02-01 | 2019-03-12 |   2
   1 | 2019-03-05 | 2019-06-15 |   3
(2 rows)

test=*# select * from demo where daterange(start_date, end_date,'[)') && 
daterange('2019-07-10','2019-09-13');

 user_id | start_date | end_date | pid
-++--+-
(0 rows)

test=*#

test=*# \d demo
  Table "public.demo"
   Column   |  Type   | Collation | Nullable | Default
+-+---+--+-
 user_id    | integer |   |  |
 start_date | date    |   |  |
 end_date   | date    |   |  |
 pid    | integer |   |  |

test=*#


Regards, Andreas



--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com

Re: Returning empty on insert

[Winanjaya Amijoyo]

Hi David,

thanks for your advise, as I am new with postgresql..
I try to use LOCK as below, but it does not returning pid?
what I missed?

BEGIN TRANSACTION;
LOCK TABLE test IN ACCESS EXCLUSIVE MODE;
WITH s AS (
   SELECT pid FROM test WHERE area = 'test4'
), i AS (
   INSERT INTO test (area)
   SELECT 'test4'
   WHERE NOT EXISTS (SELECT 1 FROM s)
   RETURNING pid
)
UPDATE area
SET last_update = CURRENT_TIMESTAMP
WHERE pid = (SELECT pid FROM s UNION SELECT pid FROM i)
RETURNING pid;
COMMIT TRANSACTION;


On Thu, May 16, 2019 at 4:25 PM David Rowley 
wrote:

> On Thu, 16 May 2019 at 21:13, Winanjaya Amijoyo
>  wrote:
> > When record not found then insert and return pid value or if not found
> then update based on pid and again return its pid.
>
> You could do something like:
>
> WITH s AS (
>SELECT pid FROM test WHERE area = 'test5'
> ), i AS (
>INSERT INTO test (area)
>SELECT 'test5'
>WHERE NOT EXISTS (SELECT 1 FROM s)
>RETURNING pid
> )
> UPDATE area
> SET last_update = CURRENT_TIMESTAMP
> WHERE pid = (SELECT pid FROM s UNION SELECT pid FROM i)
> RETURNING pid;
>
> but be warned, it's could all fall over as soon as you have concurrent
> sessions running this at the same time.  You could protect against
> that by doing some advisory locking (
> https://www.postgresql.org/docs/11/explicit-locking.html#ADVISORY-LOCKS
> ), or taking an access exclusive lock on "test".
>
> --
>  David Rowley   http://www.2ndQuadrant.com/
>  PostgreSQL Development, 24x7 Support, Training & Services
>

Re: Returning empty on insert

[Adrian Klaver]

On 5/16/19 7:10 AM, Winanjaya Amijoyo wrote:

Hi David,

thanks for your advise, as I am new with postgresql..
I try to use LOCK as below, but it does not returning pid?
what I missed?


I'm not sure which pid you are referring to, the INSERT or UPDATE or both?

Can you show the output of the query?


BEGIN TRANSACTION;
LOCK TABLE test IN ACCESS EXCLUSIVE MODE;
WITH s AS (
    SELECT pid FROM test WHERE area = 'test4'
), i AS (
    INSERT INTO test (area)
    SELECT 'test4'
    WHERE NOT EXISTS (SELECT 1 FROM s)
    RETURNING pid
)
UPDATE area
SET last_update = CURRENT_TIMESTAMP
WHERE pid = (SELECT pid FROM s UNION SELECT pid FROM i)
RETURNING pid;
COMMIT TRANSACTION;





--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Returning empty on insert

[Winanjaya Amijoyo]

see enclosed screenshot..

I thought, the record still locked that's why it returns empty..

On Thu, May 16, 2019 at 9:21 PM Adrian Klaver 
wrote:

> On 5/16/19 7:10 AM, Winanjaya Amijoyo wrote:
> > Hi David,
> >
> > thanks for your advise, as I am new with postgresql..
> > I try to use LOCK as below, but it does not returning pid?
> > what I missed?
>
> I'm not sure which pid you are referring to, the INSERT or UPDATE or both?
>
> Can you show the output of the query?
> >
> > BEGIN TRANSACTION;
> > LOCK TABLE test IN ACCESS EXCLUSIVE MODE;
> > WITH s AS (
> > SELECT pid FROM test WHERE area = 'test4'
> > ), i AS (
> > INSERT INTO test (area)
> > SELECT 'test4'
> > WHERE NOT EXISTS (SELECT 1 FROM s)
> > RETURNING pid
> > )
> > UPDATE area
> > SET last_update = CURRENT_TIMESTAMP
> > WHERE pid = (SELECT pid FROM s UNION SELECT pid FROM i)
> > RETURNING pid;
> > COMMIT TRANSACTION;
> >
> >
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>

Re: Returning empty on insert

[Winanjaya Amijoyo]

and yes .. I need both inserted pid and updated pid

On Thu, May 16, 2019 at 9:25 PM Winanjaya Amijoyo <
winanjaya.amij...@gmail.com> wrote:

> see enclosed screenshot..
>
> I thought, the record still locked that's why it returns empty..
>
> On Thu, May 16, 2019 at 9:21 PM Adrian Klaver 
> wrote:
>
>> On 5/16/19 7:10 AM, Winanjaya Amijoyo wrote:
>> > Hi David,
>> >
>> > thanks for your advise, as I am new with postgresql..
>> > I try to use LOCK as below, but it does not returning pid?
>> > what I missed?
>>
>> I'm not sure which pid you are referring to, the INSERT or UPDATE or both?
>>
>> Can you show the output of the query?
>> >
>> > BEGIN TRANSACTION;
>> > LOCK TABLE test IN ACCESS EXCLUSIVE MODE;
>> > WITH s AS (
>> > SELECT pid FROM test WHERE area = 'test4'
>> > ), i AS (
>> > INSERT INTO test (area)
>> > SELECT 'test4'
>> > WHERE NOT EXISTS (SELECT 1 FROM s)
>> > RETURNING pid
>> > )
>> > UPDATE area
>> > SET last_update = CURRENT_TIMESTAMP
>> > WHERE pid = (SELECT pid FROM s UNION SELECT pid FROM i)
>> > RETURNING pid;
>> > COMMIT TRANSACTION;
>> >
>> >
>>
>>
>> --
>> Adrian Klaver
>> adrian.kla...@aklaver.com
>>
>

Re: Returning empty on insert

[Adrian Klaver]

On 5/16/19 7:26 AM, Winanjaya Amijoyo wrote:

and yes .. I need both inserted pid and updated pid


The INSERT pid is going to be 'swallowed' by the CTE that is why the:

SELECT pid FROM s UNION SELECT pid FROM i

Which also means the UPDATE RETURNING pid will be equal to it.





On Thu, May 16, 2019 at 9:25 PM Winanjaya Amijoyo 
mailto:winanjaya.amij...@gmail.com>> wrote:


see enclosed screenshot..

I thought, the record still locked that's why it returns empty..

On Thu, May 16, 2019 at 9:21 PM Adrian Klaver
mailto:adrian.kla...@aklaver.com>> wrote:

On 5/16/19 7:10 AM, Winanjaya Amijoyo wrote:
 > Hi David,
 >
 > thanks for your advise, as I am new with postgresql..
 > I try to use LOCK as below, but it does not returning pid?
 > what I missed?

I'm not sure which pid you are referring to, the INSERT or
UPDATE or both?

Can you show the output of the query?
 >
 > BEGIN TRANSACTION;
 > LOCK TABLE test IN ACCESS EXCLUSIVE MODE;
 > WITH s AS (
 >     SELECT pid FROM test WHERE area = 'test4'
 > ), i AS (
 >     INSERT INTO test (area)
 >     SELECT 'test4'
 >     WHERE NOT EXISTS (SELECT 1 FROM s)
 >     RETURNING pid
 > )
 > UPDATE area
 > SET last_update = CURRENT_TIMESTAMP
 > WHERE pid = (SELECT pid FROM s UNION SELECT pid FROM i)
 > RETURNING pid;
 > COMMIT TRANSACTION;
 >
 >


-- 
Adrian Klaver

adrian.kla...@aklaver.com 




--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Returning empty on insert

[Winanjaya Amijoyo]

I changed the query to:

LOCK TABLE test IN EXCLUSIVE MODE;
WITH s AS (
   SELECT pid,area FROM test WHERE area = 'test123'
), i AS (
   INSERT INTO test (area)
   SELECT ' test123 '
   WHERE NOT EXISTS (SELECT 1 FROM s)
   RETURNING pid
)
UPDATE area
SET last_update = CURRENT_TIMESTAMP
WHERE pid =  (SELECT pid FROM s UNION SELECT pid FROM i) Or pid = (SELECT
pid FROM s Where area = ' test123')
RETURNING pid;

now it returns for both insert and update ..
but if I use BEGIN WORK; and COMMIT WORK; before and end of it .. it
returns empty


On Thu, May 16, 2019 at 9:47 PM Adrian Klaver 
wrote:

> On 5/16/19 7:26 AM, Winanjaya Amijoyo wrote:
> > and yes .. I need both inserted pid and updated pid
>
> The INSERT pid is going to be 'swallowed' by the CTE that is why the:
>
> SELECT pid FROM s UNION SELECT pid FROM i
>
> Which also means the UPDATE RETURNING pid will be equal to it.
>
>
>
> >
> > On Thu, May 16, 2019 at 9:25 PM Winanjaya Amijoyo
> > mailto:winanjaya.amij...@gmail.com>>
> wrote:
> >
> > see enclosed screenshot..
> >
> > I thought, the record still locked that's why it returns empty..
> >
> > On Thu, May 16, 2019 at 9:21 PM Adrian Klaver
> > mailto:adrian.kla...@aklaver.com>>
> wrote:
> >
> > On 5/16/19 7:10 AM, Winanjaya Amijoyo wrote:
> >  > Hi David,
> >  >
> >  > thanks for your advise, as I am new with postgresql..
> >  > I try to use LOCK as below, but it does not returning pid?
> >  > what I missed?
> >
> > I'm not sure which pid you are referring to, the INSERT or
> > UPDATE or both?
> >
> > Can you show the output of the query?
> >  >
> >  > BEGIN TRANSACTION;
> >  > LOCK TABLE test IN ACCESS EXCLUSIVE MODE;
> >  > WITH s AS (
> >  > SELECT pid FROM test WHERE area = 'test4'
> >  > ), i AS (
> >  > INSERT INTO test (area)
> >  > SELECT 'test4'
> >  > WHERE NOT EXISTS (SELECT 1 FROM s)
> >  > RETURNING pid
> >  > )
> >  > UPDATE area
> >  > SET last_update = CURRENT_TIMESTAMP
> >  > WHERE pid = (SELECT pid FROM s UNION SELECT pid FROM i)
> >  > RETURNING pid;
> >  > COMMIT TRANSACTION;
> >  >
> >  >
> >
> >
> > --
> > Adrian Klaver
> > adrian.kla...@aklaver.com 
> >
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>

Re: Returning empty on insert

[Winanjaya Amijoyo]

yes you are right!.. the insert was swallowed

I tried below:

WITH s AS (
   SELECT pid,area FROM test WHERE area = '11'
), i AS (
   INSERT INTO test (area)
   SELECT '11'
   WHERE NOT EXISTS (SELECT 1 FROM s)
   RETURNING pid
)
UPDATE test
SET last_update = CURRENT_TIMESTAMP
WHERE pid =  (SELECT pid FROM s UNION SELECT pid FROM i) Or pid = (SELECT
pid FROM s Where area = '11')
RETURNING pid;

insert does not returning pid


On Thu, May 16, 2019 at 9:51 PM Adrian Klaver 
wrote:

> On 5/16/19 7:25 AM, Winanjaya Amijoyo wrote:
> > see enclosed screenshot..
> >
> > I thought, the record still locked that's why it returns empty..
>
> I'm not sure I believe that screenshot. For one I don't know why it
> showing the area and last_update as they are not being returned?
>
> Try the query in psql and see what happens. As an example:
>
> update check_test set fld_1 = '67' where id =1 returning id;
>   id
> 
>1
> (1 row)
>
> UPDATE 1
>
>
> >
> > On Thu, May 16, 2019 at 9:21 PM Adrian Klaver  > > wrote:
> >
> > On 5/16/19 7:10 AM, Winanjaya Amijoyo wrote:
> >  > Hi David,
> >  >
> >  > thanks for your advise, as I am new with postgresql..
> >  > I try to use LOCK as below, but it does not returning pid?
> >  > what I missed?
> >
> > I'm not sure which pid you are referring to, the INSERT or UPDATE or
> > both?
> >
> > Can you show the output of the query?
> >  >
> >  > BEGIN TRANSACTION;
> >  > LOCK TABLE test IN ACCESS EXCLUSIVE MODE;
> >  > WITH s AS (
> >  > SELECT pid FROM test WHERE area = 'test4'
> >  > ), i AS (
> >  > INSERT INTO test (area)
> >  > SELECT 'test4'
> >  > WHERE NOT EXISTS (SELECT 1 FROM s)
> >  > RETURNING pid
> >  > )
> >  > UPDATE area
> >  > SET last_update = CURRENT_TIMESTAMP
> >  > WHERE pid = (SELECT pid FROM s UNION SELECT pid FROM i)
> >  > RETURNING pid;
> >  > COMMIT TRANSACTION;
> >  >
> >  >
> >
> >
> > --
> > Adrian Klaver
> > adrian.kla...@aklaver.com 
> >
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>

Re: Returning empty on insert

[Adrian Klaver]

On 5/16/19 7:25 AM, Winanjaya Amijoyo wrote:

see enclosed screenshot..

I thought, the record still locked that's why it returns empty..


I'm not sure I believe that screenshot. For one I don't know why it 
showing the area and last_update as they are not being returned?


Try the query in psql and see what happens. As an example:

update check_test set fld_1 = '67' where id =1 returning id;
 id

  1
(1 row)

UPDATE 1




On Thu, May 16, 2019 at 9:21 PM Adrian Klaver > wrote:


On 5/16/19 7:10 AM, Winanjaya Amijoyo wrote:
 > Hi David,
 >
 > thanks for your advise, as I am new with postgresql..
 > I try to use LOCK as below, but it does not returning pid?
 > what I missed?

I'm not sure which pid you are referring to, the INSERT or UPDATE or
both?

Can you show the output of the query?
 >
 > BEGIN TRANSACTION;
 > LOCK TABLE test IN ACCESS EXCLUSIVE MODE;
 > WITH s AS (
 >     SELECT pid FROM test WHERE area = 'test4'
 > ), i AS (
 >     INSERT INTO test (area)
 >     SELECT 'test4'
 >     WHERE NOT EXISTS (SELECT 1 FROM s)
 >     RETURNING pid
 > )
 > UPDATE area
 > SET last_update = CURRENT_TIMESTAMP
 > WHERE pid = (SELECT pid FROM s UNION SELECT pid FROM i)
 > RETURNING pid;
 > COMMIT TRANSACTION;
 >
 >


-- 
Adrian Klaver

adrian.kla...@aklaver.com 




--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Returning empty on insert

[Adrian Klaver]

On 5/16/19 7:52 AM, Winanjaya Amijoyo wrote:

yes you are right!.. the insert was swallowed

I tried below:

WITH s AS (
    SELECT pid,area FROM test WHERE area = '11'
), i AS (
    INSERT INTO test (area)
    SELECT '11'
    WHERE NOT EXISTS (SELECT 1 FROM s)
    RETURNING pid
)
UPDATE test
SET last_update = CURRENT_TIMESTAMP
WHERE pid =  (SELECT pid FROM s UNION SELECT pid FROM i) Or pid = 
(SELECT pid FROM s Where area = '11')

RETURNING pid;

insert does not returning pid



This is good starting point for finding out more:

https://www.postgresql.org/docs/11/queries-with.html#QUERIES-WITH-MODIFYING


--
Adrian Klaver
adrian.kla...@aklaver.com

bigint out of range

[Daulat Ram]

Hello team ,
We  are getting ERROR:  bigint out of range. Please help on this.



ERROR:  bigint out of range
kbdb=# INSERT INTO kb_dar_ran_url_check 
(url_hash,stat_date,topic_id,site_id,url,status,user_comments,review_comments) 
VALUES 
(72894677781133866997924561390146294513,E'19-04-2019',32793,1035,E'https://bikez.com/search/index.php',1,NULL,NULL);

ERROR:  bigint out of range


Table structure is :

Table "kb_test.kb_dar_ran_url_check"
 Column  |  Type   | Collation | Nullable | Default
-+-+---+--+-
status  | bigint  |   |  |
url_hash| bigint  |   | not null |
url | character varying(4000) |   | not null |
review_comments | character varying(4000) |   |  |
user_comments   | character varying(4000) |   |  |
stat_date   | character varying(128)  |   | not null |
topic_id| numeric(38,0)   |   | not null |
site_id | numeric(38,0)   |   | not null |
Partition key: LIST (stat_date)


Thanks,
Daulat

Re: bigint out of range

[Geoff Winkless]

On Thu, 16 May 2019 at 16:31, Daulat Ram  wrote:

> Hello team ,
>
> We  are getting ERROR:  bigint out of range. Please help on this.
>
>
>
Bigint is -9223372036854775808 to 9223372036854775807.

https://www.postgresql.org/docs/current/datatype-numeric.html

Re: bigint out of range

[David G. Johnston]

On Thu, May 16, 2019 at 8:31 AM Daulat Ram 
wrote:

> url_hash| bigint  |   | not null |
>

Change the type of url_hash; make it text instead of bigint.

As a bonus:

Use text instead of arbitrary varchar(4000) fields and add, e.g., check
(length(url) < 4000) or something better.

Needing 38 digit integers for "id" fields seems odd.

Not sure what kind of date would need 128 characters to represent; ideally
you'd just make that a  "date" typed field and normalize on input.

David J.

Upgrading 9.1.17 to which version?

[nigel . andersen]

Hi,

 

I've just inherited an ancient install of 9.1.17 after our tech guy left, on what turns out to be a rapidly dying server and being a total newb to PostgreSQL (and not much more advanced on Linux) I'm a little stuck on the way ahead.

 

I've managed to secure a decent new server for a new install of PostgreSQL which runs CentOS 7.6 (Minimal). CentOS 7.6's standard PostgreSQL package seems to be 9.2.24 which is obviously no longer supported so probably doesn't get us much further ahead in the short term. As part of this upgrade we'd also like to implement support for pg_trgm which apparently needs >=9.6.

 

I spent most of yesterday trying to get 9.6.13 installed from the PostgreSQL Yum repository and finally got it working with the initdb stuff stored on a non-default dedicated partition (RAID10 array) only to find that psql didn't work and was complaining about a missing libpq.so.5. Not sure if that's a common problem?

 

My (admittedly loose) logic tells me that upgrading from 9.1.x to 9.6.x is probably a safer option than making the leap up to 10.x or 11.x but I wonder whether that might be an easier/more reliable option from an install and point of view and certainly preferable in the long term. Any advice on where to go?

 

Thanks

 

Nigel

 

 

schema change tracking

[Benedict Holland]

Hi All,

I am fairly this question has many answers but here it goes:

I need a tool that can track schema changes in a postgesql database, write
scripts to alter the tables, and store those changes in git. Are there
tools that exist that can do this?

BTW, I know if I use a framework with some form of model tracking (laravel
and Django), those can do it. The application I am writing does not track
model files and I really cannot compare sql schema dumps across versions.
It would be far too time-consuming.

Thanks,
~Ben

Re: schema change tracking

[Steve Atkins]

> On May 16, 2019, at 5:41 PM, Benedict Holland  
> wrote:
> 
> Hi All,
> 
> I am fairly this question has many answers but here it goes:
> 
> I need a tool that can track schema changes in a postgesql database, write 
> scripts to alter the tables, and store those changes in git. Are there tools 
> that exist that can do this?

If you're looking for something that'll reverse engineer schema change scripts 
from a database someone has made ad-hoc changes to ... try and avoid doing that 
if at all possible. Use the change scripts in git as the source of truth.

If you do that there are many answers, starting at "it's fairly easy to do 
yourself, with a simple schema version and upgrade / downgrade scripts". 
Depending on what language you're writing your app in there may be libraries 
that can help.

But if you're looking for something standalone, look at https://sqitch.org

Cheers,
  Steve

Permissions for information_schema

[Susan Hurst]

What are the correct permissions to give to a role so that all objects 
in the information_schema (and pg_catalog) are visible to a user?  
Permissions seem to make a difference but I don't know which adjustments 
to make without causing unintended consequences. We revoked select on 
all tables and functions from public, if that makes a difference.  We 
don't use the public schema but it appears that postgres does.


Should I be looking at something other than permissions to make 
information_schema more visible?  We are particularly interested in 
using the comments on everything to create views of our database 
structures that we can use for our team's training documentation.  Of 
course, the comments/descriptions can't be selected in isolation so we 
need full visibility.


Below are samples of select statements with outputs that disagree based 
upon the database and presumably, the permissions.


Thanks for your help!

Sue


Production db logged in as admin:

CREATE ROLE admin LOGIN
  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT read TO admin;
GRANT write TO admin;

select * from information_schema.table_constraints; -- 206 rows
select * from information_schema.constraint_column_usage;   -- 0 rows



sandbox db logged in as postgres:

CREATE ROLE postgres LOGIN
  ENCRYPTED PASSWORD ''
  SUPERUSER INHERIT CREATEDB CREATEROLE REPLICATION;
select * from information_schema.table_constraints;-- 621 rows
select * from information_schema.constraint_column_usage;  -- 127 rows


--

Susan E Hurst
Principal Consultant
Brookhurst Data LLC
Email: susan.hu...@brookhurstdata.com
Mobile: 314-486-3261

Re: bigint out of range

[Tony Shelver]

Adding to what David said,  I don't see much point of having a bigint
status. Usually status attributes are a fixed set of values that can be
checked programmatically.

>

Re: schema change tracking

[Paul Jungwirth]

On 5/16/19 9:41 AM, Benedict Holland wrote:
I need a tool that can track schema changes in a postgesql database, 
write scripts to alter the tables, and store those changes in git. Are 
there tools that exist that can do this?


BTW, I know if I use a framework with some form of model tracking 
(laravel and Django), those can do it. The application I am writing does 
not track model files and I really cannot compare sql schema dumps 
across versions. It would be far too time-consuming.


For Python database migrations when I'm not using Django or SQLAlchemy 
I've enjoyed yoyo migrations:


https://ollycope.com/software/yoyo/latest/

If you are using SQLAlchemy then I'd go with Alembic:

https://pypi.org/project/alembic/

Btw I don't *think* this is what you're looking for, but on the Postgres 
side you can also set `log_statement='ddl'` to audit the changes:


https://blog.hagander.net/why-are-you-not-logging-your-ddl-142/

Or for something more elaborate you could use Event Triggers. The docs 
have an example you could start from:


https://www.postgresql.org/docs/current/event-trigger-example.html

--
Paul  ~{:-)
p...@illuminatedcomputing.com

Re: Upgrading 9.1.17 to which version?

[David G. Johnston]

On Thu, May 16, 2019 at 9:36 AM  wrote:

> Hi,
>
> I've just inherited an ancient install of 9.1.17 after our tech guy left,
> on what turns out to be a rapidly dying server and being a total newb to
> PostgreSQL (and not much more advanced on Linux) I'm a little stuck on the
> way ahead.
>
> I've managed to secure a decent new server for a new install of PostgreSQL
> which runs CentOS 7.6 (Minimal). CentOS 7.6's standard PostgreSQL package
> seems to be 9.2.24 which is obviously no longer supported so probably
> doesn't get us much further ahead in the short term.
>


>
>
Any advice on where to go?
>

Get a second machine, set it up to be as identical to the existing machine
as you can - aside from it not being near death - and migrate "production"
to it.

Then on the machine described above install v10 and whatever else you need
for staging/testing and then once everything checks out migrate the
production database to the new machine and point production resources to it.

Lastly, but first, consider finding an experienced professional to evaluate
you exact current circumstances and execute the above - or whatever they
recommend.  The first item warrants doing that at the least.  You can delay
deciding on how to approach the second option until after your production
environment is stable.

David J.

Re: Permissions for information_schema

[David G. Johnston]

On Thu, May 16, 2019 at 9:50 AM Susan Hurst 
wrote:

> What are the correct permissions to give to a role so that all objects
> in the information_schema (and pg_catalog) are visible to a user?
>

Have you determined that using the underlying pg_catalog schema is not
viable.

David J.

Re: schema change tracking

[Mark Fletcher]

On Thu, May 16, 2019 at 9:41 AM Benedict Holland <
benedict.m.holl...@gmail.com> wrote:

>
> I need a tool that can track schema changes in a postgesql database, write
> scripts to alter the tables, and store those changes in git. Are there
> tools that exist that can do this?
>
> We ended up rolling our own. We do schema dumps and then use
https://www.apgdiff.com/ to diff them. For our relatively simple schemas,
it's worked fine. One thing to note, apgdiff doesn't support `ALTER TABLE
ONLY [a-z\.]+ REPLICA IDENTITY FULL;` lines, which we just remove before
diffing.

Cheers,
Mark

Re: Upgrading 9.1.17 to which version?

[Ron]

On 5/16/19 4:36 AM, nigel.ander...@gmx.com wrote:

Hi,
I've just inherited an ancient install of 9.1.17 after our tech guy left, 
on what turns out to be a rapidly dying server and being a total newb to 
PostgreSQL (and not much more advanced on Linux) I'm a little stuck on the 
way ahead.
I've managed to secure a decent new server for a new install of PostgreSQL 
which runs CentOS 7.6 (Minimal). CentOS 7.6's standard PostgreSQL package 
seems to be 9.2.24 which is obviously no longer supported so probably 
doesn't get us much further ahead in the short term. As part of this 
upgrade we'd also like to implement support for pg_trgm which apparently 
needs >=9.6.
I spent most of yesterday trying to get 9.6.13 installed from the 
PostgreSQL Yum repository and finally got it working with the initdb stuff 
stored on a non-default dedicated partition (RAID10 array) only to find 
that psql didn't work and was complaining about a missing libpq.so.5. Not 
sure if that's a common problem?


What packages did you install?

My (admittedly loose) logic tells me that upgrading from 9.1.x to 9.6.x is 
probably a safer option than making the leap up to 10.x or 11.x


No, not really.

but I wonder whether that might be an easier/more reliable option from an 
install and point of view and certainly preferable in the long term. Any 
advice on where to go?


11.x would be best, since it's EOL is furthest in the future.
9.6 would be best, because it's had more bug-fix releases.

:)

--
Angular momentum makes the world go 'round.

Re: Permissions for information_schema

[Susan Hurst]

 

The objects are granted SELECT to PUBLIC. 

---

Susan E Hurst
Principal Consultant
Brookhurst Data LLC
Email: susan.hu...@brookhurstdata.com
Mobile: 314-486-3261

On 2019-05-16 11:53, David G. Johnston wrote: 

> On Thu, May 16, 2019 at 9:50 AM Susan Hurst  
> wrote: 
> 
>> What are the correct permissions to give to a role so that all objects 
>> in the information_schema (and pg_catalog) are visible to a user?
> 
> Have you determined that using the underlying pg_catalog schema is not 
> viable. 
> 
> David J.
 

Re: Upgrading 9.1.17 to which version?

[Fabio Ugo Venchiarutti]

On 16/05/2019 18:20, Ron wrote:

On 5/16/19 4:36 AM, nigel.ander...@gmx.com wrote:

Hi,
I've just inherited an ancient install of 9.1.17 after our tech guy 
left, on what turns out to be a rapidly dying server and being a total 
newb to PostgreSQL (and not much more advanced on Linux) I'm a little 
stuck on the way ahead.
I've managed to secure a decent new server for a new install of 
PostgreSQL which runs CentOS 7.6 (Minimal). CentOS 7.6's standard 
PostgreSQL package seems to be 9.2.24 which is obviously no longer 
supported so probably doesn't get us much further ahead in the short 
term. As part of this upgrade we'd also like to implement support for 
pg_trgm which apparently needs >=9.6.
I spent most of yesterday trying to get 9.6.13 installed from the 
PostgreSQL Yum repository and finally got it working with the initdb 
stuff stored on a non-default dedicated partition (RAID10 array) only 
to find that psql didn't work and was complaining about a missing 
libpq.so.5. Not sure if that's a common problem?


What packages did you install?

My (admittedly loose) logic tells me that upgrading from 9.1.x to 
9.6.x is probably a safer option than making the leap up to 10.x or 11.x


No, not really.

but I wonder whether that might be an easier/more reliable option from 
an install and point of view and certainly preferable in the long 
term. Any advice on where to go?


11.x would be best, since it's EOL is furthest in the future.
9.6 would be best, because it's had more bug-fix releases.



Aren't all important bugfixes backported to every non-EOL affected 
majors at once?



Correct me if I'm wrong but I thought that's the reason minors are 
released at unison for all majors.





:)

--
Angular momentum makes the world go 'round.


--
Regards

Fabio Ugo Venchiarutti
OSPCFC Network Engineering Dpt.
Ocado Technology

--


Notice:  This email is confidential and may contain copyright material of 
members of the Ocado Group. Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the members of the 
Ocado Group. 


 

If you are not the intended recipient, please notify us 
immediately and delete all copies of this message. Please note that it is 
your responsibility to scan this message for viruses. 


 

Fetch and Sizzle 
are trading names of Speciality Stores Limited and Fabled is a trading name 
of Marie Claire Beauty Limited, both members of the Ocado Group.


 


References to the “Ocado Group” are to Ocado Group plc (registered in 
England and Wales with number 7098618) and its subsidiary undertakings (as 
that expression is defined in the Companies Act 2006) from time to time.  
The registered office of Ocado Group plc is Buildings One & Two, Trident 
Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.

Re: Permissions for information_schema

[Adrian Klaver]

On 5/16/19 9:50 AM, Susan Hurst wrote:
What are the correct permissions to give to a role so that all objects 
in the information_schema (and pg_catalog) are visible to a user? 


As example:
https://www.postgresql.org/docs/11/infoschema-tables.html

"... Only those tables and views are shown that the current user has 
access to (by way of being the owner or having some privilege)."


If you do:

\d+ information_schema.tables

at the end of the view definition you will see:

... AND (pg_has_role(c.relowner, 'USAGE'::text) OR 
has_table_privilege(c.oid, 'SELECT, INSERT, UPDATE, DELETE, TRUNCATE, 
REFERENCES, TRIGGER'::text) OR has_any_column_privilege(c.oid, 'SELECT, 
INSERT, UPDATE, REFERENCES'::text));


So the permissions check is baked into the view definition. That means 
the role doing the query has to meet the above criteria. Either you have 
to create a role that creates all objects and then let that role use the 
information_schema(or grant it to other roles) or you need to use a 
superuser role.




Permissions seem to make a difference but I don't know which adjustments 
to make without causing unintended consequences. We revoked select on 
all tables and functions from public, if that makes a difference.  We 
don't use the public schema but it appears that postgres does.


Should I be looking at something other than permissions to make 
information_schema more visible?  We are particularly interested in 
using the comments on everything to create views of our database 
structures that we can use for our team's training documentation.  Of 
course, the comments/descriptions can't be selected in isolation so we 
need full visibility.


Below are samples of select statements with outputs that disagree based 
upon the database and presumably, the permissions.


Thanks for your help!

Sue


Production db logged in as admin:

CREATE ROLE admin LOGIN
   NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT read TO admin;
GRANT write TO admin;

select * from information_schema.table_constraints; -- 206 rows
select * from information_schema.constraint_column_usage;   -- 0 rows



sandbox db logged in as postgres:

CREATE ROLE postgres LOGIN
   ENCRYPTED PASSWORD ''
   SUPERUSER INHERIT CREATEDB CREATEROLE REPLICATION;
select * from information_schema.table_constraints;    -- 621 rows
select * from information_schema.constraint_column_usage;  -- 127 rows





--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Upgrading 9.1.17 to which version?

[David G. Johnston]

On Thu, May 16, 2019 at 10:38 AM Fabio Ugo Venchiarutti <
f.venchiaru...@ocado.com> wrote:

> On 16/05/2019 18:20, Ron wrote:
> > On 5/16/19 4:36 AM, nigel.ander...@gmx.com wrote:
> >> but I wonder whether that might be an easier/more reliable option from
> >> an install and point of view and certainly preferable in the long
> >> term. Any advice on where to go?
> >
> > 11.x would be best, since it's EOL is furthest in the future.
> > 9.6 would be best, because it's had more bug-fix releases.
> >
>
> Aren't all important bugfixes backported to every non-EOL affected
> majors at once?


More bug-fix-only releases means that more time has gone by to find and fix
the bugs in older versions without a corresponding increase in undiscovered
bugs that results from moving to the next major release.

David J.

Re: Upgrading 9.1.17 to which version?

[Adrian Klaver]

On 5/16/19 10:38 AM, Fabio Ugo Venchiarutti wrote:







11.x would be best, since it's EOL is furthest in the future.
9.6 would be best, because it's had more bug-fix releases.



Aren't all important bugfixes backported to every non-EOL affected 
majors at once?



Correct me if I'm wrong but I thought that's the reason minors are 
released at unison for all majors.


True. The possible issue is that the newest version has been out for the 
shortest period of time and contains new code that may not have been 
exercised enough yet to catch all as yet hidden bugs. Older versions 
have been run longer and under more scenarios so the expectation is more 
of the bugs have been flushed out.







:)

--
Angular momentum makes the world go 'round.





--
Adrian Klaver
adrian.kla...@aklaver.com

Re: schema change tracking

[Benedict Holland]

Hi All!

Thanks for the replies. I am looking for a solution, possibly 3rd party,
where I write changes to the schema and it keeps track of the changes I
made. I am used to doing stuff in pgadmin4 but I don't mind something else.

This isn't really ad-hoc. This is more like, I have a v1.0 release coming
out soon and I have made dozens or hundreds of changes to the schema from
the alpha. Right now, I can destroy the databases and recreate them without
data loss because it is in active development. When this gets released, we
need some way to make sure that we can easily migrate between release
versions and that means schema change tracking. Basically, to Steve's
concern, I don't have to go back and figure out changes (thankfully, I have
done that and it sucks) but we need something from an initial release
moving forward.

I don't have time to write my own and this problem is complex enough to
either buy a solution or go with a 3rd party application.

So far, SQITCH is looking like a winner. Yoyo can work as I have access to
python. We are not using SQLAlchemy but I don't see a reason why we can't.

Thanks all for the suggestions. This is great.
~Ben


On Thu, May 16, 2019 at 1:06 PM Mark Fletcher  wrote:

> On Thu, May 16, 2019 at 9:41 AM Benedict Holland <
> benedict.m.holl...@gmail.com> wrote:
>
>>
>> I need a tool that can track schema changes in a postgesql database,
>> write scripts to alter the tables, and store those changes in git. Are
>> there tools that exist that can do this?
>>
>> We ended up rolling our own. We do schema dumps and then use
> https://www.apgdiff.com/ to diff them. For our relatively simple schemas,
> it's worked fine. One thing to note, apgdiff doesn't support `ALTER TABLE
> ONLY [a-z\.]+ REPLICA IDENTITY FULL;` lines, which we just remove before
> diffing.
>
> Cheers,
> Mark
>

Re: schema change tracking

[Adrian Klaver]

On 5/16/19 10:55 AM, Benedict Holland wrote:

Hi All!

Thanks for the replies. I am looking for a solution, possibly 3rd party, 
where I write changes to the schema and it keeps track of the changes I 
made. I am used to doing stuff in pgadmin4 but I don't mind something else.


This isn't really ad-hoc. This is more like, I have a v1.0 release 
coming out soon and I have made dozens or hundreds of changes to the 
schema from the alpha. Right now, I can destroy the databases and 
recreate them without data loss because it is in active development. 
When this gets released, we need some way to make sure that we can 
easily migrate between release versions and that means schema change 
tracking. Basically, to Steve's concern, I don't have to go back and 
figure out changes (thankfully, I have done that and it sucks) but we 
need something from an initial release moving forward.


I don't have time to write my own and this problem is complex enough to 
either buy a solution or go with a 3rd party application.


So far, SQITCH is looking like a winner. Yoyo can work as I have access 
to python. We are not using SQLAlchemy but I don't see a reason why we 
can't.


I will second the motion on Sqitch. It has met all my needs and is 
framework agnostic.




Thanks all for the suggestions. This is great.
~Ben








--
Adrian Klaver
adrian.kla...@aklaver.com

Re: schema change tracking

[bricklen]

On Thu, May 16, 2019 at 9:41 AM Benedict Holland <
benedict.m.holl...@gmail.com> wrote:

> I need a tool that can track schema changes in a postgesql database, write
> scripts to alter the tables, and store those changes in git. Are there
> tools that exist that can do this?
>

For dev and QA, my company is using Migra (
https://github.com/djrobstep/migra) as part of the developer workflow to
track DDL changes. The generated changes are then put into git as patches.
Migra itself is just used for the diff'ing capabilities it provides, and
will require some glue code if you want to use it for any CI/CD work.

FATAL: SMgrRelation hashtable corrupted

[Daulat Ram]

Hello team

I need your help on this issue.

My Postgres 11.2 container is not started due to the below error message. It is 
in streaming replication environment.

2019-05-17 06:41:08.989 UTC [1] LOG:  listening on Unix socket 
"/var/run/postgresql/.s.PGSQL.5432"
2019-05-17 06:41:09.093 UTC [11] LOG:  database system was interrupted while in 
recovery at 2019-05-17 06:40:24 UTC
2019-05-17 06:41:09.093 UTC [11] HINT:  This probably means that some data is 
corrupted and you will have to use the last backup for recovery.
2019-05-17 06:41:11.260 UTC [12] FATAL:  the database system is starting up
2019-05-17 06:41:11.673 UTC [13] FATAL:  the database system is starting up
2019-05-17 06:41:12.209 UTC [14] FATAL:  the database system is starting up
2019-05-17 06:41:12.427 UTC [15] FATAL:  the database system is starting up
2019-05-17 06:41:15.425 UTC [16] FATAL:  the database system is starting up
2019-05-17 06:41:15.680 UTC [17] FATAL:  the database system is starting up
2019-05-17 06:41:16.059 UTC [18] FATAL:  the database system is starting up
2019-05-17 06:41:16.263 UTC [19] FATAL:  the database system is starting up
2019-05-17 06:41:16.624 UTC [20] FATAL:  the database system is starting up
2019-05-17 06:41:17.471 UTC [21] FATAL:  the database system is starting up
2019-05-17 06:41:18.739 UTC [22] FATAL:  the database system is starting up
2019-05-17 06:41:19.877 UTC [11] LOG:  database system was not properly shut 
down; automatic recovery in progress
2019-05-17 06:41:19.887 UTC [11] LOG:  redo starts at 5E/170349E8
2019-05-17 06:41:19.954 UTC [11] FATAL:  SMgrRelation hashtable corrupted
2019-05-17 06:41:19.954 UTC [11] CONTEXT:  WAL redo at 5E/17061648 for 
Transaction/COMMIT: 2019-05-17 06:39:46.902988+00; rels: base/59265/105367 
base/59265/105349 base/59265/105365 base/59265/105362 base/59265/105360 
base/59265/105349 base/59265/105358 base/59265/105355; inval msgs: catcache 50 
catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 
catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 
catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 
catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 relcache 105365 
relcache 105367 relcache 105367 relcache 105293 relcache 105411 relcache 105411 
relcache 105365 relcache 105293 relcache 105358 relcache 105360 relcache 105360 
relcache 105285 relcache 105413 relcache 105413 relcache 105358 relcache 105285
2019-05-17 06:41:19.955 UTC [1] LOG:  startup process (PID 11) exited with exit 
code 1
2019-05-17 06:41:19.955 UTC [1] LOG:  aborting startup due to startup process 
failure
2019-05-17 06:41:19.961 UTC [1] LOG:  database system is shut down

Regards,
Daulat