Password reset link / 'less' does not exit in psql version 13.4
Hello, I have two very simple questions: 1) I have an account at postgresql.org, but a link to a 'forgot password' seems to be missing on the login page. I have my password stored only on an old Fedora 32 computer. To change the password when logged in, you need to supply the old password. In short, I have no way to migrate this postgresql.org account to my new Fedora 35 and Fedora 36 computers. What can be done about this? 2) I have three psql clients running, a version 12.6, a version 13.4 and a version 14.3. Until now a 'select * from table;' showed the output in 'less' or something alike and exited from 'less' when the output was complete. Both version 12.6 and version 13.4 work that way. Version 14.3 does not exit from 'less' when the output is complete. Did anyone notice this already? Best regards, Mischa Baars.
Re: Password reset link / 'less' does not exit in psql version 13.4
On Mon, 2022-07-25 at 07:55 -0700, Adrian Klaver wrote: > On 7/25/22 03:01, Michael J. Baars wrote: > > Hello, > > > > I have two very simple questions: > > > > 1) I have an account at postgresql.org, but a link to a 'forgot password' > > seems to be missing on the login page. I have my password stored only on an > > old Fedora 32 computer. To change the password > > when logged in, you need to supply the old password. In short, I have no > > way to migrate this postgresql.org account to my new Fedora 35 and Fedora > > 36 computers. What can be done about this? > > If you go here: > > https://www.postgresql.org/account/login/?next=/account/ > > there is a password reset link that takes you to page where you can > specify the email address for the account and have a password reset link > sent to that email. At that link you can create a new password without > knowing the old one. Thank you Adrian! > > > 2) I have three psql clients running, a version 12.6, a version 13.4 and a > > version 14.3. Until now a 'select * from table;' showed the output in > > 'less' or something alike and exited from 'less' > > when > > the output was complete. Both version 12.6 and version 13.4 work that way. > > Version 14.3 does not exit from 'less' when the output is complete. Did > > anyone notice this already? > > Are all the clients running on the same machine? Nope, three out of four machines run psql. I have four identical machines. Small ones. Beelink MII-Vs. I was preparing to expand to twenty, but I have problems booting Fedora Server from a centralized Fedora Server / Fedora Workstation dual boot over NFS. It looks like the nfsroot= kernel parameter conflicts with the initrd, which holds some Fedora configuration scripts. It would have been really nice to see the PostgreSQL server running over an aggregated 20Gbit/s SFP+ connection, serving 20 1Gbit/s number crunchers without loss of any bandwidth :) Hopefully one day it will work. That's why I was fiddling around with the different Fedora and psql versions instead of working :) > > > Best regards, > > Mischa Baars. > > > > > > > > > >
Re: Password reset link / 'less' does not exit in psql version 13.4
On Mon, 2022-07-25 at 09:13 -0700, Adrian Klaver wrote: > On 7/25/22 09:03, Michael J. Baars wrote: > > On Mon, 2022-07-25 at 07:55 -0700, Adrian Klaver wrote: > > > On 7/25/22 03:01, Michael J. Baars wrote: > > > > Hello, > > > Are all the clients running on the same machine? > > > > Nope, three out of four machines run psql. I have four identical machines. > > Small ones. Beelink MII-Vs. > > The machines are identical but is the software also? > > If you run Postgres 14 on one of the machines that has 12 or 13 does the > pager work the same? I thought I already told this before, but some of the mails, apparently do not get through. I'm running Fedora 32, Fedora 35 and Fedora 36 at the moment. Fedora 32 and 35 do not show any problems with the pager, nor are there any PAGER or PSQL_PAGER environment variables. Fedora 36 behaves different from the older two versions. > > > I was preparing to expand to twenty, but I have problems booting Fedora > > Server from a centralized Fedora Server / Fedora Workstation dual boot over > > NFS. It looks like the nfsroot= kernel parameter > > conflicts with the initrd, which holds some Fedora configuration scripts. > > It would have been really nice to see the PostgreSQL server running over an > > aggregated 20Gbit/s SFP+ connection, serving > > 20 > > 1Gbit/s number crunchers without loss of any bandwidth :) Hopefully one day > > it will work. > > > > That's why I was fiddling around with the different Fedora and psql > > versions instead of working :) > > I'm going to say we have reached the core of the issue:) > > > > > Best regards, > > > > Mischa Baars. > >
Re: Password reset link / 'less' does not exit in psql version 13.4
On Mon, 25 Jul 2022, 18:41 Adrian Klaver, wrote: > On 7/25/22 09:23, Michael J. Baars wrote: > > On Mon, 2022-07-25 at 09:13 -0700, Adrian Klaver wrote: > >> On 7/25/22 09:03, Michael J. Baars wrote: > >>> On Mon, 2022-07-25 at 07:55 -0700, Adrian Klaver wrote: > >>>> On 7/25/22 03:01, Michael J. Baars wrote: > >>>>> Hello, > > > > > I thought I already told this before, but some of the mails, apparently > do not get through. > > I didn't seem them. > It's an evolution problem. I think it's had it's longest time. > > > > I'm running Fedora 32, Fedora 35 and Fedora 36 at the moment. Fedora 32 > and 35 do not show any problems with the pager, nor are there any PAGER or > PSQL_PAGER environment variables. Fedora 36 behaves > > different from the older two versions. > > > > So the issue is with Fedora not Postgres. > No, it's psql. Setting PAGER to "more -e" solved the problem l, but I never had to before. There are no other variables affecting this behavior, so it must be psql internal default piping command that has changed. > Does Fedora 36 have PAGER* env variables? > No, none of the distributions has by default. > In Fedora 36 at a terminal command line what happens if you do ls -al in > a directory with more then screen full of file listings? > > > >>>>> Best regards, > >>>>> Mischa Baars. > >> > >> > > > > > -- > Adrian Klaver > adrian.kla...@aklaver.com >
libpq and multi-threading
Hi All, I have a question about libpq and multi-threading. In the PostgreSQL documentation ( https://www.postgresql.org/docs/15/libpq-threading.html) it says that results can be passed around freely between threads. However, when I try to read the result from the parent thread, the program crashes with a segmentation fault. I have already tried to set the PostgreSQL 'dynamic_shared_memory_type' configuration option to 'mmap', but this does not help. Am I doing something wrong? How can I make libpq use mmap to allocate memory that *can* be read from the parent thread? Best regards, Mischa Baars.
Re: libpq and multi-threading
Hello Laurenz, I don't think it is, but let me shed some more light on it. After playing around a little with threads and memory, I now know that the PGresult is not read-only, it is read-once. The child can only read that portion of parent memory, that was written before the thread started. Read-only is not strong enough. Let me correct my first mail. Making libpq use mmap is not good enough either. Shared memory allocated by the child can not be accessed by the parent. I remembered right after pushing the send button. Shared memory needed by the child therefore has to be allocated through the parent. In conclusion. I have found no way to pass the PGresult around, other than by copying it to shared memory. Rather disappointing. One store too many if you ask me. But passing PGresults around freely between threads, because they are supposingly read-only, is not a finding that I was able to reproduce from here. On Tue, 2 May 2023, 15:49 Laurenz Albe, wrote: > On Tue, 2023-05-02 at 11:38 +0200, Michael J. Baars wrote: > > I have a question about libpq and multi-threading. > > > > In the PostgreSQL documentation ( > https://www.postgresql.org/docs/15/libpq-threading.html) > > it says that results can be passed around freely between threads. > However, when I try to read > > the result from the parent thread, the program crashes with a > segmentation fault. > > That's too little information. > > Yours, > Laurenz Albe >
Re: libpq and multi-threading
Hi David, My mistake. Too much fiddling around, but better than no fiddling around. It appears both sides make mistakes, or does your freely passing around work better than mine? On Tue, 2 May 2023, 17:57 David G. Johnston, wrote: > On Tue, May 2, 2023 at 2:38 AM Michael J. Baars < > mjbaars1977.pgsql.hack...@gmail.com> wrote: > >> I have already tried to set the PostgreSQL 'dynamic_shared_memory_type' >> configuration option to 'mmap', but this does not help. >> >> > Of course it doesn't, that is a server-side configuration. > > "Specifies the dynamic shared memory implementation that the server should > use." > > > https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY > > David J. > >
Re: libpq and multi-threading
Hi Peter, The shared common address space is controlled by the clone(2) CLONE_VM option. Indeed this results in an environment in which both the parent and the child can read / write each other's memory, but dynamic memory being allocated using malloc(3) from two different threads simulaneously will result in internal interference. Because libpq makes use of malloc to store results, you will come to find that the CLONE_VM option was not the option you were looking for. On Tue, 2 May 2023, 19:58 Peter J. Holzer, wrote: > On 2023-05-02 17:43:06 +0200, Michael J. Baars wrote: > > I don't think it is, but let me shed some more light on it. > > One possibly quite important information you haven't told us yet is > which OS you use. > > Or how you create the threads, how you pass the results around, what > else you are possibly doing between getting the result and trying to use > it ... > > A short self-contained test case might shed some light on this. > > > > After playing around a little with threads and memory, I now know that > the > > PGresult is not read-only, it is read-once. The child can only read that > > portion of parent memory, that was written before the thread started. > Read-only > > is not strong enough. > > > > Let me correct my first mail. Making libpq use mmap is not good enough > either. > > Shared memory allocated by the child can not be accessed by the parent. > > Are you sure you are talking about threads and not processes? In the OSs > I am familiar with, threads (of the same process) share a common address > space. You don't need explicit shared memory and there is no such thing > as "parent memory" (there is thread-local storage, but that's more a > compiler/library construct). > > hp > > -- >_ | Peter J. Holzer| Story must make more sense than reality. > |_|_) || > | | | h...@hjp.at |-- Charles Stross, "Creative writing > __/ | http://www.hjp.at/ | challenge!" >
Re: libpq and multi-threading
Hi Michael, Are pthread_* functions really such an improvement over clone? Does it make an 'freely passing around' of PGresult objects possible? Like it matters, process or thread. We were talking about the documentation and this 'freely passing around' PGresult object. I just don't think it is as simple as the documentation makes you believe. On Wed, 3 May 2023, 14:35 Michael Loftis, wrote: > > That is not a thread. Linux man clone right at the start … > > “clone, __clone2, clone3 - create a child process” > > What you want is pthread_create (or similar) > > There’s a bunch of not well documented dragons if you’re trying to treat a > child process as a thread. Use POSIX Threads, as pretty much anytime PG or > anything else Linux based says thread they’re talking about a POSIX Thread > environment. > > > On Wed, May 3, 2023 at 05:12 Michael J. Baars < > mjbaars1977.pgsql.hack...@gmail.com> wrote: > >> Hi Peter, >> >> The shared common address space is controlled by the clone(2) CLONE_VM >> option. Indeed this results in an environment in which both the parent and >> the child can read / write each other's memory, but dynamic memory being >> allocated using malloc(3) from two different threads simulaneously will >> result in internal interference. >> >> Because libpq makes use of malloc to store results, you will come to find >> that the CLONE_VM option was not the option you were looking for. >> >> On Tue, 2 May 2023, 19:58 Peter J. Holzer, wrote: >> >>> On 2023-05-02 17:43:06 +0200, Michael J. Baars wrote: >>> > I don't think it is, but let me shed some more light on it. >>> >>> One possibly quite important information you haven't told us yet is >>> which OS you use. >>> >>> Or how you create the threads, how you pass the results around, what >>> else you are possibly doing between getting the result and trying to use >>> it ... >>> >>> A short self-contained test case might shed some light on this. >>> >>> >>> > After playing around a little with threads and memory, I now know that >>> the >>> > PGresult is not read-only, it is read-once. The child can only read >>> that >>> > portion of parent memory, that was written before the thread started. >>> Read-only >>> > is not strong enough. >>> > >>> > Let me correct my first mail. Making libpq use mmap is not good enough >>> either. >>> > Shared memory allocated by the child can not be accessed by the parent. >>> >>> Are you sure you are talking about threads and not processes? In the OSs >>> I am familiar with, threads (of the same process) share a common address >>> space. You don't need explicit shared memory and there is no such thing >>> as "parent memory" (there is thread-local storage, but that's more a >>> compiler/library construct). >>> >>> hp >>> >>> -- >>>_ | Peter J. Holzer| Story must make more sense than reality. >>> |_|_) || >>> | | | h...@hjp.at |-- Charles Stross, "Creative writing >>> __/ | http://www.hjp.at/ | challenge!" >>> >> -- > > "Genius might be described as a supreme capacity for getting its possessors > into trouble of all kinds." > -- Samuel Butler >
