Services breakage from the PostgreSQL socket-directory configuration change

Christopher Baines wrote on 24 Feb 2021 01:44

Recipients:(address . bug-guix@gnu.org)

Message-ID:87lfbel2fa.fsf@cbaines.net

Hey,

When reconfiguring recently, I ran in to issues with the Guix Data

Service and probably the Patchwork service too.

Looking at the change, I think it's clear there's a problem, because

some system tests were changed, and I'm guessing they were changed so

that they passed [1].

1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=6c0679215f4ffa534c1eb2e8c8a6e043a0c993fe

Passing tests are good, but working around real issues in tests is not,

because that means that the situation outside of the tests can break and

if it does, the test result is misleading.

Patchwork, the Guix Data Service and maybe other things currently depend

on the default behaviour of PostgreSQL to find the socket. Given that

the service now uses a different (non-default) value, they don't

work.

One workaround, the one employed in the tests is to revert to the old

behaviour for the PostgreSQL service by setting socket-directory to #f.

Mathieu Othacehe wrote on 25 Feb 2021 14:39

Recipients:(name . Christopher Baines)(address . mail@cbaines.net)(address . 46737@debbugs.gnu.org)

Message-ID:87a6rsmfky.fsf@gnu.org

Hello Chris,

Toggle quote (3 lines)

> One workaround, the one employed in the tests is to revert to the old

> behaviour for the PostgreSQL service by setting socket-directory to #f.

You're right, sorry about the breakage. As you noticed we are in an

in-between situation where the patch updating Postgresql package to use

"/var/run/postgresql" by default is only on core-updates, but the

service is already using it as a default on master.

This means that "createdb", "dropdb" and other Postgresql user tools

need to have an explicit "-h /var/run/postgresql" argument for now.

Until the package patch gets merged in the master branch, we could set

the "socket-directory" field of <postgresql-config-file> record to #f to

restore an acceptable default behaviour.

WDYT?

Sorry again for breaking things,

Mathieu

Christopher Baines wrote on 25 Feb 2021 19:35

Recipients:(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 46737@debbugs.gnu.org)

Message-ID:87pn0oj8ql.fsf@cbaines.net

Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (17 lines)>> One workaround, the one employed in the tests is to revert to the old
>> behaviour for the PostgreSQL service by setting socket-directory to #f.
>
> You're right, sorry about the breakage. As you noticed we are in an
> in-between situation where the patch updating Postgresql package to use
> "/var/run/postgresql" by default is only on core-updates, but the
> service is already using it as a default on master.
>
> This means that "createdb", "dropdb" and other Postgresql user tools
> need to have an explicit "-h /var/run/postgresql" argument for now.
>
> Until the package patch gets merged in the master branch, we could set
> the "socket-directory" field of <postgresql-config-file> record to #f to
> restore an acceptable default behaviour.
>
> WDYT?

I think that would be good. It's unfortunate that the package change is

stuck on core-updates for now, but configuring the service on master to

keep the old behaviour until core-updates is merged sounds sensible.

Thanks,

Chris

Christopher Baines wrote on 12 Apr 2021 22:47

Recipients:(address . 46737@debbugs.gnu.org)

Message-ID:87k0p7z0um.fsf@cbaines.net

Christopher Baines <mail@cbaines.net> writes:

Toggle quote (23 lines)> Mathieu Othacehe <othacehe@gnu.org> writes:
>
>>> One workaround, the one employed in the tests is to revert to the old
>>> behaviour for the PostgreSQL service by setting socket-directory to #f.
>>
>> You're right, sorry about the breakage. As you noticed we are in an
>> in-between situation where the patch updating Postgresql package to use
>> "/var/run/postgresql" by default is only on core-updates, but the
>> service is already using it as a default on master.
>>
>> This means that "createdb", "dropdb" and other Postgresql user tools
>> need to have an explicit "-h /var/run/postgresql" argument for now.
>>
>> Until the package patch gets merged in the master branch, we could set
>> the "socket-directory" field of <postgresql-config-file> record to #f to
>> restore an acceptable default behaviour.
>>
>> WDYT?
>
> I think that would be good. It's unfortunate that the package change is
> stuck on core-updates for now, but configuring the service on master to
> keep the old behaviour until core-updates is merged sounds sensible.

I don't know if the expectation was that I was going to fix this, but

since it seems there's a release coming up, I went ahead and prepared a

patch [1].

1: https://issues.guix.gnu.org/47736

Leo Famulari wrote on 13 Apr 2021 01:15

Recipients:(name . Christopher Baines)(address . mail@cbaines.net)(address . 46737-done@debbugs.gnu.org)

Message-ID:YHTUpGDguIKJA2cQ@jasmine.lan

On Mon, Apr 12, 2021 at 09:47:45PM +0100, Christopher Baines wrote:

Toggle quote (32 lines)> 
> Christopher Baines <mail@cbaines.net> writes:
> 
> > Mathieu Othacehe <othacehe@gnu.org> writes:
> >
> >>> One workaround, the one employed in the tests is to revert to the old
> >>> behaviour for the PostgreSQL service by setting socket-directory to #f.
> >>
> >> You're right, sorry about the breakage. As you noticed we are in an
> >> in-between situation where the patch updating Postgresql package to use
> >> "/var/run/postgresql" by default is only on core-updates, but the
> >> service is already using it as a default on master.
> >>
> >> This means that "createdb", "dropdb" and other Postgresql user tools
> >> need to have an explicit "-h /var/run/postgresql" argument for now.
> >>
> >> Until the package patch gets merged in the master branch, we could set
> >> the "socket-directory" field of <postgresql-config-file> record to #f to
> >> restore an acceptable default behaviour.
> >>
> >> WDYT?
> >
> > I think that would be good. It's unfortunate that the package change is
> > stuck on core-updates for now, but configuring the service on master to
> > keep the old behaviour until core-updates is merged sounds sensible.
> 
> I don't know if the expectation was that I was going to fix this, but
> since it seems there's a release coming up, I went ahead and prepared a
> patch [1].
> 
> 1: https://issues.guix.gnu.org/47736

I pushed your patch as c311147bd16aa0e5746d9cbf31502f5fd61e470c

Closed

Your comment

This issue is archived.

To comment on this conversation send email to 46737@debbugs.gnu.org

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date