Looking for someone to help the Warsaw Expo Refugee Center. They need someone with Django and React experience. They have an existing app which needs modification & data loaded in from a spreadsheet.

If interested, please contact me directly & I will put you in touch. Please boost.

RIP Bill Jolitz, great grandfather to all the current *BSD systems still alive. He created #386BSD from Net/2 and started all this grand adventure, of which I've been a tiny part thanks to him.

Fare Thee Well Bill.

------
Today on the Unix Heritage Society mailing list, Clem Cole reports that Bill Jolitz, the eccentric programmer who forklifted BSD to the 386, passed away recently. No other information yet. RIP.

minnie.tuhs.org/pipermail/tuhs

Today I realized I don't need to manually do a pkg upgrade after a upgrade between FreeBSD versions.

dan.langille.org/2022/03/27/ma

Yeah, I know I don't HAVE to do such an upgrade, because things will still run, but that's now how things are done around here.

Last weekend, I found rotten wood in the workbench. Today I removed it, found lots more rotten wood, and some dead animals.

flickr.com/photos/dlangille/al

The BSDCan 2022 Call For Papers has went out in Dec. The CFP closes on 19 Jan 2022 or so.

Not not applied? Try today? I've been busy so I've not had time to close it out.

* bsdcan.org/2022/papers.php
* lists.bsdcan.org/pipermail/bsd

Today: update the Bacula regression testing scripts. Sometime between Bacula 9 and Bacula 11, Linuxisms have crept in. I've been given patches which I'll include in what I have at home.

Fixes will be sent upstream.

email: sourceforge.net/p/bacula/mailm

tests: regress.bacula.org/index.php?p

Today: update the Bacula regression testing scripts. Sometime between Bacula 9 and Bacula 11, Linuxisms have crept in. I've been given patches which I'll include in what I have at home.

Fixes will be sent upstream.

email: sourceforge.net/p/bacula/mailm

tests: regress.bacula.org/index.php?p

I think this is a duplicate function issue. The same function is declared twice.

One of the functions works, the other does not.

This is not a bug with PostgreSQL.

It's a bug in my file of stored procedures.

Show thread

Guess what?

Works on PostgreSQL 14.

I'm going to do another test on PostgreSQL 13, using the same approach as for PostgreSQL 13 - I wonder if I've overlooked something in the process.

Show thread

CONTEXT: SQL statement "INSERT INTO element_pathname (element_id, pathname) VALUES (NEW.id, l_pathname)"
PL/pgSQL function element_pathname_insert() line 7 at SQL statement
SQL statement "insert into element(id, parent_id, directory_file_flag, name, status)
values(element_id, element_parent_id, 'D', element_name, 'A')"
PL/pgSQL function element_add(text,character) line 89 at SQL statement
freshports.org=#

Show thread

With source db PostgreSQL 12 and all other tools being PostgreSQL 13, same source database:

pgdump (13) pg_restore (13), the PostgreSQL 13 db gives:

freshports.org=# select element_add('/src/things/dan', 'F');
NOTICE: for NEW.id = "1181875", I am inserting "" into element_pathname
ERROR: duplicate key value violates unique constraint "element_pathname_pathname"
DETAIL: Key (pathname)=() already exists.

Show thread

With all PostgreSQL 12 tools:

pg_dump and pg_restore:

freshports.org=# select element_add('/src/things/dan', 'F');
element_add
-------------
1181966
(1 row)

freshports.org=#

Show thread

HEADS UP: even using the correct procedure, this does not work on a PG13 database.

Next test: load this db up on PostgreSQL 12 and verify that restore performs as expected.

Show thread

For my next trick I'll try restoring the PostgreSQL 12 dump again and see if I can replicate the problem a second time. Tune in next time.

Show thread

The anomaly: a trigger upon insert on table A will insert a row into table B - there is a one-to-one relationship between the two tables. In the newly-restored PostgreSQL 13 database, that insert always resulted in a duplicate key violation in table B.

Dumping with a PostgreSQL 13 client and loading into a fresh PostgreSQL 13 instance does not replicate the original problem.

Show thread

I encountered a PostgreSQL trigger anomaly which seems to be related to my incorrect dumping of the database.

The issue: I did a pg_dump with a PostgreSQL 12 client and loaded into a PostgreSQL 13 database.

The correct procedure is to dump with a PostgreSQL 13 client. I failed.

The first steps to avoid this warning:

poudriere: Warning: Using ‘-‘ in a SETNAME is not recommended as it causes ambiguities with parsing the build name of 122amd64-default-master-list

dan.langille.org/2021/08/28/po

Today I've been using 'mkjail update -a' to update all my jails with respect to recent published known vulns on .

Why update the jail and the host? Because I can.

Patch everything when a patch is available. One vuln might have unknown leverage. I can't tell. So I patch.

Is this a new device or not?

gpart shows a partition.

smarctl says 4 power on hours, 56 power cycles, 104GB written.

Could that just be initial testing at the factory?

dan.langille.org/2021/08/09/i-

Show older
Mastodon

The original server operated by the Mastodon gGmbH non-profit