Error dydl : image not found when trying to install pg on Catalina

[cecile rougnaux]

I upgraded my system to Catalina 10.15.7 and now I get an  error with dyld : 
image not found when trying to install postgresql :


➜  ~ brew install postgresql

Running `brew update --preinstall`...

==> Auto-updated Homebrew!

Updated 1 tap (homebrew/core).

==> Updated Formulae

Updated 6 formulae.


==> Downloading https://ghcr.io/v2/homebrew/core/krb5/manifests/1.19.3

Already downloaded: 
/Users/rougnaux/Library/Caches/Homebrew/downloads/99d453969cccecf3b539a32dfa27cbdc85c12d0017c92bec5729bea7cf6328a2--krb5-1.19.3.bottle_manifest.json

==> Downloading 
https://ghcr.io/v2/homebrew/core/krb5/blobs/sha256:e269d5d0c19c6da2521b8ab8a51f5ac1229387b

Already downloaded: 
/Users/rougnaux/Library/Caches/Homebrew/downloads/0a454bc3adeb2c958c03807c84ff279323ff741e3b8a64aa78603f558e7b4c94--krb5--1.19.3.catalina.bottle.tar.gz

==> Downloading https://ghcr.io/v2/homebrew/core/postgresql/manifests/14.2_1

Already downloaded: 
/Users/rougnaux/Library/Caches/Homebrew/downloads/6a491ab32f22a1325da9bceba1f59875f5c43478aa890de97644fb7c1b196e18--postgresql-14.2_1.bottle_manifest.json

==> Downloading 
https://ghcr.io/v2/homebrew/core/postgresql/blobs/sha256:bb6bf761a60c6aec73f31595e167c2c78

Already downloaded: 
/Users/rougnaux/Library/Caches/Homebrew/downloads/e3f7b538f0e6cf2f8a966ce5d9de5e4aca2d2da9d0b1905217f5930200ac552f--postgresql--14.2_1.catalina.bottle.tar.gz

==> Installing dependencies for postgresql: krb5

==> Installing postgresql dependency: krb5

==> Pouring krb5--1.19.3.catalina.bottle.tar.gz

🍺  /usr/local/Cellar/krb5/1.19.3: 162 files, 5.2MB

==> Installing postgresql

==> Pouring postgresql--14.2_1.catalina.bottle.tar.gz

==> /usr/local/Cellar/postgresql/14.2_1/bin/initdb --locale=C -E UTF-8 
/usr/local/var/postgres

Last 15 lines from 
/Users/rougnaux/Library/Logs/Homebrew/postgresql/post_install.01.initdb:

2022-04-17 13:10:48 +0200


/usr/local/Cellar/postgresql/14.2_1/bin/initdb

--locale=C

-E

UTF-8

/usr/local/var/postgres


dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.70.dylib

  Referenced from: /usr/local/Cellar/postgresql/14.2_1/bin/postgres

  Reason: image not found

no data was returned by command 
""/usr/local/Cellar/postgresql/14.2_1/bin/postgres" -V"

initdb: error: The program "postgres" is needed by initdb but was not found in 
the

same directory as "/usr/local/Cellar/postgresql/14.2_1/bin/initdb".

Check your installation.

Warning: The post-install step did not complete successfully

You can try again using:

  brew postinstall postgresq


How can I fix this ?
Thanks for help!
Cécile

Re: Help with large delete

[Perry Smith]

I’m sending this again.  I don’t see that it made it to the list but there is 
also new info here.

> On Apr 16, 2022, at 10:33, Tom Lane  > wrote:
> 
> Perry Smith mailto:p...@easesoftware.com>> writes:
>> Currently I have one table that mimics a file system.  Each entry has a 
>> parent_id and a base name where parent_id is an id in the table that must 
>> exist in the table or be null with cascade on delete.
>> I’ve started a delete of a root entry with about 300,000 descendants.  The 
>> table currently has about 22M entries and I’m adding about 1600 entries per 
>> minute still.  Eventually there will not be massive amounts of entries being 
>> added and the table will be mostly static.
> 
> The most obvious question is do you have an index on the referencing
> column.  PG doesn't require one to exist to create an FK; but if you
> don't, deletes of referenced rows had better be uninteresting to you
> performance-wise, because each one will cause a seqscan.

To try to reply to Peter’s question, I jstarted:

psql -c "explain analyze delete from dateien where basename = 
'/mnt/pedz/Visual_Media'” find_dups

I did this last night at 10 p.m. and killed it just now at 6:30 without any 
response.

This is inside a BSD “jail” on a NAS.  I don’t know how much CPU the jail is 
given.

For Tom’s question, here is the description of the table:

psql -c '\d dateien' find_dups
  Table "public.dateien"
   Column   |  Type  | Collation | Nullable |   
Default
++---+--+-
 id | bigint |   | not null | 
nextval('dateien_id_seq'::regclass)
 basename   | character varying  |   | not null |
 parent_id  | bigint |   |  |
 dev| bigint |   | not null |
 ftype  | character varying  |   | not null |
 uid| bigint |   | not null |
 gid| bigint |   | not null |
 ino| bigint |   | not null |
 mode   | bigint |   | not null |
 mtime  | timestamp without time zone|   | not null |
 nlink  | bigint |   | not null |
 size   | bigint |   | not null |
 sha1   | character varying  |   |  |
 created_at | timestamp(6) without time zone |   | not null |
 updated_at | timestamp(6) without time zone |   | not null |
Indexes:
"dateien_pkey" PRIMARY KEY, btree (id)
"unique_dev_ino_for_dirs" UNIQUE, btree (dev, ino) WHERE ftype::text = 
'directory'::text
"unique_parent_basename" UNIQUE, btree (COALESCE(parent_id, 
'-1'::integer::bigint), basename)
Foreign-key constraints:
"fk_rails_c01ebbd0bf" FOREIGN KEY (parent_id) REFERENCES dateien(id) ON 
DELETE CASCADE
Referenced by:
TABLE "dateien" CONSTRAINT "fk_rails_c01ebbd0bf" FOREIGN KEY (parent_id) 
REFERENCES dateien(id) ON DELETE CASCADE

To do a simple delete of a node that has no children takes about 11 seconds:

time psql -c "delete from dateien where id = 13498939;" find_dups
DELETE 1
psql -c "delete from dateien where id = 13498939;" find_dups  0.00s user 0.01s 
system 0% cpu 11.282 total

I’m implementing the suggestion that I do the recession myself but at this rate 
it will take about 38 days to delete 300K entries.  I must be doing something 
horribly wrong.  I hope you guys can enlighten me.

Thank you for your time,
Perry

















signature.asc
Description: Message signed with OpenPGP

Re: Help with large delete

[Perry Smith]

Thank you TOM!!!

So… I did:

create index parent_id_index on dateien(parent_id);

And now things are going much faster.  As you can see, I had an index kinda 
sorta on the parent id but I guess the way I did it prevented Postgres from 
using it.

> On Apr 17, 2022, at 06:58, Perry Smith  wrote:
> 
> I’m sending this again.  I don’t see that it made it to the list but there is 
> also new info here.
> 
>> On Apr 16, 2022, at 10:33, Tom Lane > > wrote:
>> 
>> Perry Smith mailto:p...@easesoftware.com>> writes:
>>> Currently I have one table that mimics a file system.  Each entry has a 
>>> parent_id and a base name where parent_id is an id in the table that must 
>>> exist in the table or be null with cascade on delete.
>>> I’ve started a delete of a root entry with about 300,000 descendants.  The 
>>> table currently has about 22M entries and I’m adding about 1600 entries per 
>>> minute still.  Eventually there will not be massive amounts of entries 
>>> being added and the table will be mostly static.
>> 
>> The most obvious question is do you have an index on the referencing
>> column.  PG doesn't require one to exist to create an FK; but if you
>> don't, deletes of referenced rows had better be uninteresting to you
>> performance-wise, because each one will cause a seqscan.
> 
> To try to reply to Peter’s question, I jstarted:
> 
> psql -c "explain analyze delete from dateien where basename = 
> '/mnt/pedz/Visual_Media'” find_dups
> 
> I did this last night at 10 p.m. and killed it just now at 6:30 without any 
> response.
> 
> This is inside a BSD “jail” on a NAS.  I don’t know how much CPU the jail is 
> given.
> 
> For Tom’s question, here is the description of the table:
> 
> psql -c '\d dateien' find_dups
>   Table "public.dateien"
>Column   |  Type  | Collation | Nullable | 
>   Default
> ++---+--+-
>  id | bigint |   | not null | 
> nextval('dateien_id_seq'::regclass)
>  basename   | character varying  |   | not null |
>  parent_id  | bigint |   |  |
>  dev| bigint |   | not null |
>  ftype  | character varying  |   | not null |
>  uid| bigint |   | not null |
>  gid| bigint |   | not null |
>  ino| bigint |   | not null |
>  mode   | bigint |   | not null |
>  mtime  | timestamp without time zone|   | not null |
>  nlink  | bigint |   | not null |
>  size   | bigint |   | not null |
>  sha1   | character varying  |   |  |
>  created_at | timestamp(6) without time zone |   | not null |
>  updated_at | timestamp(6) without time zone |   | not null |
> Indexes:
> "dateien_pkey" PRIMARY KEY, btree (id)
> "unique_dev_ino_for_dirs" UNIQUE, btree (dev, ino) WHERE ftype::text = 
> 'directory'::text
> "unique_parent_basename" UNIQUE, btree (COALESCE(parent_id, 
> '-1'::integer::bigint), basename)
> Foreign-key constraints:
> "fk_rails_c01ebbd0bf" FOREIGN KEY (parent_id) REFERENCES dateien(id) ON 
> DELETE CASCADE
> Referenced by:
> TABLE "dateien" CONSTRAINT "fk_rails_c01ebbd0bf" FOREIGN KEY (parent_id) 
> REFERENCES dateien(id) ON DELETE CASCADE
> 
> To do a simple delete of a node that has no children takes about 11 seconds:
> 
> time psql -c "delete from dateien where id = 13498939;" find_dups
> DELETE 1
> psql -c "delete from dateien where id = 13498939;" find_dups  0.00s user 
> 0.01s system 0% cpu 11.282 total
> 
> I’m implementing the suggestion that I do the recession myself but at this 
> rate it will take about 38 days to delete 300K entries.  I must be doing 
> something horribly wrong.  I hope you guys can enlighten me.
> 
> Thank you for your time,
> Perry
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: Error dydl : image not found when trying to install pg on Catalina

[Tom Lane]

cecile rougnaux  writes:
> I upgraded my system to Catalina 10.15.7 and now I get an  error with dyld : 
> image not found when trying to install postgresql :

> dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.70.dylib

This seems like a bug in the Homebrew formula for postgresql, which
you should report to wherever they designate for formula problems
(hint: not here).  It's made postgres dependent on a version of
libicu that it hasn't requested to be installed.

It's possible that you could work around this by manually installing
that libicu version first.  But there could be other version-skew
problems lurking behind this one, so prodding the formula maintainer
seems to be the easiest path.

regards, tom lane

Re: Require details that can we see the password history to a User account in PostgreSQL Database.

[Sonai muthu raja M]

Dear Adrian,

Yes, exactly. My query regarding an application user that when passwords were 
changed and what the previous values were?

Kindly let us know the above information since this detail require for an 
internal auditing purpose.

Thanks.

Warm regards,

M Sonai Muthu Raja
Managed Delivery Services - DBA Support
M: +919003132734
II Floor, TIDEL Park, 4 Rajiv Gandhi Salai,
Taramani, Chennai – 600 113

[cid:d300bf1a-9c00-4fca-989d-0ee3816b4112]

www.sifytechnologies.com



From: Adrian Klaver 
Sent: Friday, April 15, 2022 9:29 PM
To: Sonai muthu raja M ; 
pgsql-general@lists.postgresql.org 
Cc: dba_support 
Subject: Re: Require details that can we see the password history to a User 
account in PostgreSQL Database.

WARNING: This email originated from outside of Sify domain. DO NOT click the 
links or open the attachments unless you recognize the sender and know the 
content is safe.



On 4/15/22 02:11, Sonai muthu raja M wrote:
> Dear Team,
>
> Kindly help us to know that can we see the password history to a User
> account in PostgreSQL Database. in PostgreSQL Database.

Do you mean when passwords where changed and what the previous values where?

Also by User account do you mean a Postgres role or an application user?

>
> Please do the needful since the information require for auditing purpose.
>
> */Warm regards,/**/
>
> M Sonai Muthu Raja
> Managed Delivery Services - DBA Support

--
Adrian Klaver
adrian.kla...@aklaver.com
DISCLAIMER: The information contained in this electronic message and any 
attachments to this message are intended for the exclusive use of the 
addressee(s) and may contain proprietary, confidential or privileged 
information. If you are not the intended recipient, you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately and 
destroy all copies of this message and any attachments. Please note that 
intercepting or any unauthorized use of this message or any attachment can be 
treated as infringement of person’s right of privacy under the Human Rights Act 
1993 and also is a Criminal Offence under the Information and Technology Act, 
2008.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email. Thank you for your cooperation.

Re: Require details that can we see the password history to a User account in PostgreSQL Database.

[Sonai muthu raja M]

Dear Adrian,

Thank you so much for the provided information.

Warm regards,

M Sonai Muthu Raja
Managed Delivery Services - DBA Support
M: +919003132734
II Floor, TIDEL Park, 4 Rajiv Gandhi Salai,
Taramani, Chennai – 600 113

[cid:81f6183b-b8da-49ea-9fd6-fea0ef9db0ff]

www.sifytechnologies.com



From: Adrian Klaver 
Sent: Saturday, April 16, 2022 9:24 PM
To: Sonai muthu raja M ; 
pgsql-general@lists.postgresql.org 
Cc: dba_support 
Subject: Re: Require details that can we see the password history to a User 
account in PostgreSQL Database.

WARNING: This email originated from outside of Sify domain. DO NOT click the 
links or open the attachments unless you recognize the sender and know the 
content is safe.



On 4/16/22 00:31, Sonai muthu raja M wrote:
> Dear Adrian,
>
> Yes, exactly. My query regardingan application user that when passwords
> were changed and what the previous values were?

1) Postgres has not built in process to audit changes to it's own roles.

2) That also means it does not audit whatever you are doing in the
application above it.

3) Assuming the application user information is stored in a Postgres
table you could create a trigger on the table that stores the changes in
a separate audit table.

>
> Kindly let us know the above information since this detail require for
> an internal auditing purpose.
>
> Thanks.
>
> */Warm regards,/**/
>
> M Sonai Muthu Raja


--
Adrian Klaver
adrian.kla...@aklaver.com
DISCLAIMER: The information contained in this electronic message and any 
attachments to this message are intended for the exclusive use of the 
addressee(s) and may contain proprietary, confidential or privileged 
information. If you are not the intended recipient, you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately and 
destroy all copies of this message and any attachments. Please note that 
intercepting or any unauthorized use of this message or any attachment can be 
treated as infringement of person’s right of privacy under the Human Rights Act 
1993 and also is a Criminal Offence under the Information and Technology Act, 
2008.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email. Thank you for your cooperation.

Facing issues with pgsql upgrade.

[Ajay Kajla]

Hello All,


I'm facing the following issue while upgrading pgsql 9.6 to pgsql 13.

It's saying database "template0" "template1" does not exist on source 9.6,
please advise.


[image: image.png]


[postgres@htf:/var/lib/pgsql]$ psql

psql (9.2.24, server 9.6.24)

WARNING: psql version 9.2, server version 9.6.

 Some psql features might not work.

Type "help" for help.



postgres=# \c template0

FATAL:  database "template0" does not exist

DETAIL:  The database subdirectory "base/13268" is missing.

Previous connection kept

postgres=# \c template1

FATAL:  database "template1" does not exist

DETAIL:  The database subdirectory "base/1" is missing.

Previous connection kept

postgres=#



With Regards,

Ajay Kajla

Re: Facing issues with pgsql upgrade.

[Adrian Klaver]

On 4/16/22 22:30, Ajay Kajla wrote:

Hello All,


I'm facing the following issue while upgrading pgsql 9.6 to pgsql 13.

It's saying database "template0" "template1" does not exist on source 
9.6, please advise.



image.png



From the below it looks like something/someone deleted the template0 
and template1 directories in the data directory. Is there a file backup 
of the data directory?




[postgres@htf:/var/lib/pgsql]$ psql

psql (9.2.24, server 9.6.24)

WARNING: psql version 9.2, server version 9.6.

          Some psql features might not work.

Type "help" for help.

postgres=# \c template0

FATAL:  database "template0" does not exist

DETAIL:  The database subdirectory "base/13268" is missing.

Previous connection kept

postgres=# \c template1

FATAL:  database "template1" does not exist

DETAIL:  The database subdirectory "base/1" is missing.

Previous connection kept

postgres=#



With Regards,

Ajay Kajla




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

Re: Facing issues with pgsql upgrade.

[David G. Johnston]

On Sun, Apr 17, 2022 at 8:53 AM Ajay Kajla  wrote:

>
> I'm facing the following issue while upgrading pgsql 9.6 to pgsql 13.
>
> It's saying database "template0" "template1" does not exist on source
> 9.6, please advise.
>
>
>
You might want to just forget doing a pg_upgrade migration and do a
pg_dumpall one instead.  The missing template databases on the existing
cluster shouldn't be noticed.

You can decide how important missing the directories are to you, since that
shouldn't happen outside someone going in and "rm'ing" them.

David J.

Re: Facing issues with pgsql upgrade.

[Adrian Klaver]

On 4/17/22 19:11, Ajay Kajla wrote:

Thanks Adrian,

1. What if we re-create template0 and template1?


First I would determine what else might be missing?

In psql what happens if you do:

\l

to get a list of databases?

And can you connect to the databases other then postgres?



2. how to restore them if we have a folder backup of the data directory?


When was the backup done and how?

Are you sure it is a complete backup?

Do you have tablespaces,other then the default, in use?




Regards,
Ajay




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