Default postgresql version

Default postgresql version

[Andreas Enge]

Hello,

I have just pushed this commit
   https://issues.guix.gnu.org/74006
that changes the default postgresql version from 10 (which has a CVE) to
just the postgresql variable (now at 15).

Since as I understood changing postgresql versions requires a (manual?)
update of the database format, I am wondering whether we should
- instead again choose a default value of a specific version?
  or maybe #f and force the user to choose one themselves?
- add a news item to be displayed during "guix pull"?

Andreas

Re: Default postgresql version

[Nicolas Graves]

On 2024-10-28 10:49, Andreas Enge wrote:

> Hello,
>
> I have just pushed this commit
>    https://issues.guix.gnu.org/74006
> that changes the default postgresql version from 10 (which has a CVE) to
> just the postgresql variable (now at 15).
>
> Since as I understood changing postgresql versions requires a
> (manual?)

Indeed, in https://www.postgresql.org/support/versioning/: 

Upgrading

Major versions make complex changes, so the contents of the data
directory cannot be maintained in a backward compatible way. A
dump/reload of the database or use of the pg_upgrade application is
required for major upgrades. We also recommend reading the upgrading
section of the major version you are planning to upgrade to. You can
upgrade from one major version to another without upgrading to
intervening versions, but we recommend reading the release notes of all
intervening major versions prior to doing so.

> update of the database format, I am wondering whether we should
> - instead again choose a default value of a specific version?
>   or maybe #f and force the user to choose one themselves?

#f seems a good option since it forces users to update manually when
they require it, no magic updates involved. Maybe we should add a
comment about why the default is #f, and point to the url of the
documentation about upgrades.

> - add a news item to be displayed during "guix pull"?

I think a news item is necessary.

Sorry I should have thought about it with the patch, let me know if
you'd wish I write this patch + news item.

> Andreas
>

-- 
Best regards,
Nicolas Graves

Re: Default postgresql version

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2311 bytes --]

On Mon, Oct 28, 2024 at 10:59:29AM +0100, Nicolas Graves wrote:
> On 2024-10-28 10:49, Andreas Enge wrote:
> 
> > Hello,
> >
> > I have just pushed this commit
> >    https://issues.guix.gnu.org/74006
> > that changes the default postgresql version from 10 (which has a CVE) to
> > just the postgresql variable (now at 15).
> >
> > Since as I understood changing postgresql versions requires a
> > (manual?)
> 
> Indeed, in https://www.postgresql.org/support/versioning/: 
> 
> Upgrading
> 
> Major versions make complex changes, so the contents of the data
> directory cannot be maintained in a backward compatible way. A
> dump/reload of the database or use of the pg_upgrade application is
> required for major upgrades. We also recommend reading the upgrading
> section of the major version you are planning to upgrade to. You can
> upgrade from one major version to another without upgrading to
> intervening versions, but we recommend reading the release notes of all
> intervening major versions prior to doing so.
> 
> > update of the database format, I am wondering whether we should
> > - instead again choose a default value of a specific version?
> >   or maybe #f and force the user to choose one themselves?
> 
> #f seems a good option since it forces users to update manually when
> they require it, no magic updates involved. Maybe we should add a
> comment about why the default is #f, and point to the url of the
> documentation about upgrades.
> 
> > - add a news item to be displayed during "guix pull"?
> 
> I think a news item is necessary.
> 
> Sorry I should have thought about it with the patch, let me know if
> you'd wish I write this patch + news item.
> 
> > Andreas
> >
> 

I feel like there is room for an 'upgrade action for postgresql, to dump
a database (also useful for a 'backup action!) and then re-import it,
but I didn't want to come anywhere near touching that.

Also, thank you for updating it! I was recently feeling like it was on
the 10 branch for too long and could use a bump. And some CVE handling.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Default postgresql version

[Andreas Enge]

Am Mon, Oct 28, 2024 at 10:59:29AM +0100 schrieb Nicolas Graves:
> Sorry I should have thought about it with the patch, let me know if
> you'd wish I write this patch + news item.

Well, I wondered whether or not to apply the patch, but since it had a
CVE, I thought solving it would be the more urgent action.

A patch and news item would be welcome, and I hope that someone using
postgresql (maybe that is you? or Efraim who already replied?) can then
chime in and provide a more substantial opinion than I could give.

Andreas

Re: Default postgresql version

[Nicolas Graves]

On 2024-10-28 12:02, Andreas Enge wrote:

> Am Mon, Oct 28, 2024 at 10:59:29AM +0100 schrieb Nicolas Graves:
>> Sorry I should have thought about it with the patch, let me know if
>> you'd wish I write this patch + news item.
>
> Well, I wondered whether or not to apply the patch, but since it had a
> CVE, I thought solving it would be the more urgent action.
>
> A patch and news item would be welcome, and I hope that someone using
> postgresql (maybe that is you? or Efraim who already replied?) can then
> chime in and provide a more substantial opinion than I could give.

Done now in 74058.  Indeed Efraim probably would have a more substantial
opinion, please go ahead and change the patches if you find a more
relevant approach!  I added a comment about doing the migration
automatically with Guix, but I won't be able to handle that quickly
either.

>
> Andreas
>

-- 
Best regards,
Nicolas Graves

Re: Default postgresql version

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

On Mon, Oct 28, 2024 at 12:17:50PM +0100, Nicolas Graves wrote:
> On 2024-10-28 12:02, Andreas Enge wrote:
> 
> > Am Mon, Oct 28, 2024 at 10:59:29AM +0100 schrieb Nicolas Graves:
> >> Sorry I should have thought about it with the patch, let me know if
> >> you'd wish I write this patch + news item.
> >
> > Well, I wondered whether or not to apply the patch, but since it had a
> > CVE, I thought solving it would be the more urgent action.
> >
> > A patch and news item would be welcome, and I hope that someone using
> > postgresql (maybe that is you? or Efraim who already replied?) can then
> > chime in and provide a more substantial opinion than I could give.
> 
> Done now in 74058.  Indeed Efraim probably would have a more substantial
> opinion, please go ahead and change the patches if you find a more
> relevant approach!  I added a comment about doing the migration
> automatically with Guix, but I won't be able to handle that quickly
> either.

No, I try to stay away from needing a database, I don't want to have to
administer it.  I just like being able to apply CVE patches.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Default postgresql version

[Nicolas Graves]

ci like bordeaux both seem down, maybe it has something to do with this
commit ? Hopefully not.

-- 
Best regards,
Nicolas Graves

Re: Default postgresql version

[Andreas Enge]

Am Tue, Oct 29, 2024 at 12:13:30PM +0100 schrieb Nicolas Graves:
> ci like bordeaux both seem down, maybe it has something to do with this
> commit ? Hopefully not.

Bordeaux is up, I think. https://qa.guix.gnu.org/ is visible, but complains
about "No route to host" in the "Branches" box; this may be due to the
berlin server being down. I do not think it is related to postgresql.

Hm, the *server* behind bordeaux.guix.gnu.org is up; when I do a
"guix build hello", it successfully serves substitute info. But then
when trying to download a substitute, I get a 504 Gateway Time-out or
a 502 Bad Gateway. Maybe it is just overwhelmed with ci being down?
I have restarted nginx and nar-herder (just an educated guess), but
to no avail.

Andreas

Re: Default postgresql version

[Andreas Enge]

Am Tue, Oct 29, 2024 at 12:42:32PM +0100 schrieb Andreas Enge:
> I have restarted nginx and nar-herder (just an educated guess), but
> to no avail.

I think the problem is further upstream, in the place where the nars are
actually stored (hatysa). When I download a file that is in the cache,
such as
   wget https://bordeaux.guix.gnu.org/nar/zstd/000z8mclk0p7jmrijj6l54bpnam29bqj-r-minfi-1.48.0
it works.

As far as I know, only Chris has access to this machine.

Andreas

Re: Default postgresql version

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 5400 bytes --]

Andreas Enge <andreas@enge.fr> writes:

> Am Tue, Oct 29, 2024 at 12:42:32PM +0100 schrieb Andreas Enge:
>> I have restarted nginx and nar-herder (just an educated guess), but
>> to no avail.
>
> I think the problem is further upstream, in the place where the nars are
> actually stored (hatysa). When I download a file that is in the cache,
> such as
>    wget https://bordeaux.guix.gnu.org/nar/zstd/000z8mclk0p7jmrijj6l54bpnam29bqj-r-minfi-1.48.0
> it works.

Hmm, yeah the nar-herder/nginx on hatysa seems to be stuck, it looks
like quite a low level problem since I see btrfs related errors in
/var/log/messages

Oct 29 10:14:07 localhost vmunix: [2910798.796657] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Oct 29 10:14:07 localhost vmunix: [2910798.802941] rcu:         Tasks blocked on level-0 rcu_node (CPUs 0-15): P30086
Oct 29 10:14:07 localhost vmunix: [2910798.809730] rcu:         (detected by 11, t=5252 jiffies, g=253094433, q=9317 ncpus=16)
Oct 29 10:14:07 localhost vmunix: [2910798.817292] task:nginx           state:R  running task     stack:0     pid:30086 tgid:30086 ppid:30085  flags:0x0000000c
Oct 29 10:14:07 localhost vmunix: [2910798.828334] Call trace:
Oct 29 10:14:07 localhost vmunix: [2910798.830945]  dump_backtrace+0x90/0xe8
Oct 29 10:14:07 localhost vmunix: [2910798.834789]  show_stack+0x18/0x24
Oct 29 10:14:07 localhost vmunix: [2910798.838273]  sched_show_task+0x12c/0x18c
Oct 29 10:14:07 localhost vmunix: [2910798.842364]  rcu_sched_clock_irq+0xd00/0xdcc
Oct 29 10:14:07 localhost vmunix: [2910798.846804]  update_process_times+0x68/0xac
Oct 29 10:14:07 localhost vmunix: [2910798.851155]  tick_sched_handle+0x34/0x58
Oct 29 10:14:07 localhost vmunix: [2910798.855245]  tick_nohz_highres_handler+0x50/0xa8
Oct 29 10:14:07 localhost vmunix: [2910798.860030]  __hrtimer_run_queues+0x138/0x1b0
Oct 29 10:14:07 localhost vmunix: [2910798.864556]  hrtimer_interrupt+0xe8/0x244
Oct 29 10:14:07 localhost vmunix: [2910798.868736]  arch_timer_handler_phys+0x34/0x44
Oct 29 10:14:07 localhost vmunix: [2910798.873349]  handle_percpu_devid_irq+0x84/0x130
Oct 29 10:14:07 localhost vmunix: [2910798.878048]  generic_handle_domain_irq+0x2c/0x44
Oct 29 10:14:07 localhost vmunix: [2910798.882834]  gic_handle_irq+0x4c/0x110
Oct 29 10:14:07 localhost vmunix: [2910798.886748]  call_on_irq_stack+0x24/0x4c
Oct 29 10:14:07 localhost vmunix: [2910798.890839]  do_interrupt_handler+0x80/0x84
Oct 29 10:14:07 localhost vmunix: [2910798.895189]  el1_interrupt+0x34/0x68
Oct 29 10:14:07 localhost vmunix: [2910798.898934]  el1h_64_irq_handler+0x18/0x24
Oct 29 10:14:07 localhost vmunix: [2910798.903195]  el1h_64_irq+0x64/0x68
Oct 29 10:14:07 localhost vmunix: [2910798.906763]  xas_descend+0x20/0x8c
Oct 29 10:14:07 localhost vmunix: [2910798.910332]  filemap_get_entry+0x5c/0x1ac
Oct 29 10:14:07 localhost vmunix: [2910798.914513]  __filemap_get_folio+0x4c/0x394
Oct 29 10:14:07 localhost vmunix: [2910798.918864]  alloc_extent_buffer+0x210/0x860 [btrfs]
Oct 29 10:14:07 localhost vmunix: [2910798.924037]  read_tree_block+0x20/0x16c [btrfs]
Oct 29 10:14:07 localhost vmunix: [2910798.928766]  btrfs_release_path+0x2ac/0x3b4 [btrfs]
Oct 29 10:14:07 localhost vmunix: [2910798.933843]  btrfs_search_slot+0x340/0xb24 [btrfs]
Oct 29 10:14:07 localhost vmunix: [2910798.938835]  btrfs_delete_one_dir_name+0x194/0x4c8 [btrfs]
Oct 29 10:14:07 localhost vmunix: [2910798.944516]  btrfs_lookup_bio_sums+0x1e4/0x40c [btrfs]
Oct 29 10:14:07 localhost vmunix: [2910798.949854]  __btrfs_panic+0xb1c/0xec4 [btrfs]
Oct 29 10:14:07 localhost vmunix: [2910798.954498]  btrfs_submit_bio+0x28/0x40 [btrfs]
Oct 29 10:14:07 localhost vmunix: [2910798.959224]  ordered_data_exit+0x638/0x2e28 [btrfs]
Oct 29 10:14:07 localhost vmunix: [2910798.964300]  extent_readahead+0x34c/0x384 [btrfs]
Oct 29 10:14:07 localhost vmunix: [2910798.969203]  btrfs_transaction_exit+0x1a3c/0x3f08 [btrfs]
Oct 29 10:14:07 localhost vmunix: [2910798.974796]  read_pages+0x80/0x2e0
Oct 29 10:14:07 localhost vmunix: [2910798.978374]  page_cache_ra_unbounded+0x160/0x1e4
Oct 29 10:14:07 localhost vmunix: [2910798.983159]  page_cache_ra_order+0x8c/0x2f8
Oct 29 10:14:07 localhost vmunix: [2910798.987510]  ondemand_readahead+0x170/0x30c
Oct 29 10:14:07 localhost vmunix: [2910798.991859]  page_cache_sync_ra+0x74/0xa4
Oct 29 10:14:07 localhost vmunix: [2910798.996036]  filemap_get_pages+0xc4/0x66c
Oct 29 10:14:07 localhost vmunix: [2910799.000215]  filemap_read+0xbc/0x398
Oct 29 10:14:07 localhost vmunix: [2910799.003959]  btrfs_release_file+0xc84/0x13d8 [btrfs]
Oct 29 10:14:07 localhost vmunix: [2910799.009128]  vfs_read+0x24c/0x2ec
Oct 29 10:14:07 localhost vmunix: [2910799.012617]  ksys_pread64+0x78/0xbc
Oct 29 10:14:07 localhost vmunix: [2910799.016271]  __arm64_sys_pread64+0x20/0x2c
Oct 29 10:14:07 localhost vmunix: [2910799.020533]  invoke_syscall+0x48/0x118
Oct 29 10:14:07 localhost vmunix: [2910799.024451]  el0_svc_common.constprop.0+0x40/0xe8
Oct 29 10:14:07 localhost vmunix: [2910799.029322]  do_el0_svc+0x20/0x2c
Oct 29 10:14:07 localhost vmunix: [2910799.032803]  el0_svc+0x34/0xb8
Oct 29 10:14:07 localhost vmunix: [2910799.036025]  el0t_64_sync_handler+0x13c/0x158
Oct 29 10:14:07 localhost vmunix: [2910799.040547]  el0t_64_sync+0x190/0x194


> As far as I know, only Chris has access to this machine.

We should be able to get other people SSH access, I'll try restarting
the machine.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Default postgresql version

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

Christopher Baines <mail@cbaines.net> writes:

> Andreas Enge <andreas@enge.fr> writes:
>
>> Am Tue, Oct 29, 2024 at 12:42:32PM +0100 schrieb Andreas Enge:
>>> I have restarted nginx and nar-herder (just an educated guess), but
>>> to no avail.
>>
>> I think the problem is further upstream, in the place where the nars are
>> actually stored (hatysa). When I download a file that is in the cache,
>> such as
>>    wget https://bordeaux.guix.gnu.org/nar/zstd/000z8mclk0p7jmrijj6l54bpnam29bqj-r-minfi-1.48.0
>> it works.
>
> Hmm, yeah the nar-herder/nginx on hatysa seems to be stuck, it looks
> like quite a low level problem since I see btrfs related errors in
> /var/log/messages

...

>> As far as I know, only Chris has access to this machine.
>
> We should be able to get other people SSH access, I'll try restarting
> the machine.

I ended up pressing the power button to restart it, but it seems to have
come up OK. I've also reconfigured with some more sysadmins so hopefully
other people can access the machine.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Default postgresql version

[Andreas Enge]

Am Tue, Oct 29, 2024 at 02:14:33PM +0000 schrieb Christopher Baines:
> I ended up pressing the power button to restart it, but it seems to have
> come up OK. I've also reconfigured with some more sysadmins so hopefully
> other people can access the machine.

Excellent, thanks a lot for your reactivity!

Andreas