Thread: pgAdmin 4: "PostgreSQL Binary Path"?
Hi, which binary (on Windows) is supposed to go in the field "Paths > Binary paths > PostgreSQL Binary Path"? Details: I have PostgreSQL 9.6 RC 1 (i.e. pgAdmin 4 1.0-rc1), downloaded from http://www.enterprisedb.com/products-services-training/pgdownload#windows running on Windows 10 x64. And when I'm trying to restore a database backup, I get the error message "Please configure the PostgreSQL Binary Path in the Preferences dialog." Thanks!! Cheers, Thomas
On Tue, Sep 6, 2016 at 11:39 AM, Thomas Landauer <thomas@landauer.at> wrote: > Hi, > > which binary (on Windows) is supposed to go in the field "Paths > Binary > paths > PostgreSQL Binary Path"? > > > Details: > I have PostgreSQL 9.6 RC 1 (i.e. pgAdmin 4 1.0-rc1), downloaded from > http://www.enterprisedb.com/products-services-training/pgdownload#windows > running on Windows 10 x64. > > And when I'm trying to restore a database backup, I get the error message > "Please configure the PostgreSQL Binary Path in the Preferences dialog." The directory containing the pg_dump/pg_restore/pg_dumpall that you want to use (it's the same as in pgAdmin 3). -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Hi Dave, thanks!! I think I've discovered a bug: I started the restore, and since then I have this message in the lower right corner of the screen (see attached screenshot). I've already restarted the computer twice, but the timer still keeps counting. The restore did create 24 of my 30+ tables, but didn't enter any data yet. The entire .backup-file is less than 1 MB - so that's nothing that could take 20.000 seconds ;-) About the initial question: I was thinking I was supposed to enter a single .exe-file, not an entire directory. So if it's not possible to figure it out automatically (like pgAdmin 3 did), please rephrase the label of the field from "PostgreSQL Binary Path" to "Directory containing the PostgreSQL binaries". Thanks! Thomas Am 06.09.2016 um 12:49 schrieb Dave Page: > On Tue, Sep 6, 2016 at 11:39 AM, Thomas Landauer <thomas@landauer.at> wrote: >> Hi, >> >> which binary (on Windows) is supposed to go in the field "Paths > Binary >> paths > PostgreSQL Binary Path"? >> >> >> Details: >> I have PostgreSQL 9.6 RC 1 (i.e. pgAdmin 4 1.0-rc1), downloaded from >> http://www.enterprisedb.com/products-services-training/pgdownload#windows >> running on Windows 10 x64. >> >> And when I'm trying to restore a database backup, I get the error message >> "Please configure the PostgreSQL Binary Path in the Preferences dialog." > > The directory containing the pg_dump/pg_restore/pg_dumpall that you > want to use (it's the same as in pgAdmin 3). >
Attachment
Hi On Tue, Sep 6, 2016 at 7:24 PM, Thomas Landauer <thomas@landauer.at> wrote: > Hi Dave, > > thanks!! > > I think I've discovered a bug: > I started the restore, and since then I have this message in the lower right > corner of the screen (see attached screenshot). I've already restarted the > computer twice, but the timer still keeps counting. Ashesh knows that part of the code far better than me, so CCing him. If you click for details, what is displayed? When we spawn jobs like this, they are executed independently of pgAdmin. It keeps track of the process IDs of the tasks and monitors them until completion, so the task will be re-displayed if pgAdmin is restarted, and it still appears to be running. > The restore did create 24 of my 30+ tables, but didn't enter any data yet. > The entire .backup-file is less than 1 MB - so that's nothing that could > take 20.000 seconds ;-) > > About the initial question: > I was thinking I was supposed to enter a single .exe-file, not an entire > directory. So if it's not possible to figure it out automatically (like > pgAdmin 3 did), please rephrase the label of the field from "PostgreSQL > Binary Path" to "Directory containing the PostgreSQL binaries". I've changed the hint text (shown under the text box) to "Path to the directory containing the PostgreSQL utility programs (pg_dump, pg_restore etc).". The label remains the same, as it should be quite short. Thanks. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Hi folks, see attached screenshot - this appears when I click on "details". I doubt that the process is really still running. I restarted the computer, and meanwhile also deleted the mentioned backup-file. > "Path to the > directory containing the PostgreSQL utility programs (pg_dump, > pg_restore etc)." Great!! Cheers, Thomas
Attachment
On Wed, Sep 7, 2016 at 10:17 AM, Thomas Landauer <thomas@landauer.at> wrote: > Hi folks, > > see attached screenshot - this appears when I click on "details". > > I doubt that the process is really still running. I restarted the computer, > and meanwhile also deleted the mentioned backup-file. OK, I think Ashesh would be be better placed to suggest a next step... -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Sep 7, 2016 at 2:50 PM, Dave Page <dpage@pgadmin.org> wrote:
On Wed, Sep 7, 2016 at 10:17 AM, Thomas Landauer <thomas@landauer.at> wrote:
> Hi folks,
>
> see attached screenshot - this appears when I click on "details".
>
> I doubt that the process is really still running. I restarted the computer,
> and meanwhile also deleted the mentioned backup-file.
OK, I think Ashesh would be be better placed to suggest a next step...
We generally starts a background process, which will report back the error code, stderr, and stdout back to the pgAdmin server as a file.
I think - you discovered a bug - the background process did not report the status code back to pgAdmin server.
I will take a look at it.
Can you please create a RM case for the same?
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Sep 7, 2016 at 10:32 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
On Wed, Sep 7, 2016 at 2:50 PM, Dave Page <dpage@pgadmin.org> wrote:
On Wed, Sep 7, 2016 at 10:17 AM, Thomas Landauer <thomas@landauer.at> wrote:
> Hi folks,
>
> see attached screenshot - this appears when I click on "details".
>
> I doubt that the process is really still running. I restarted the computer,
> and meanwhile also deleted the mentioned backup-file.
OK, I think Ashesh would be be better placed to suggest a next step...We generally starts a background process, which will report back the error code, stderr, and stdout back to the pgAdmin server as a file.I think - you discovered a bug - the background process did not report the status code back to pgAdmin server.
Presumably there's a status file still on Thomas' machine, as the task keeps re-displaying. Is it worth looking at that?
I will take a look at it.Can you please create a RM case for the same?
Me? :-)
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hi Ashesh, so what am I supposed to do now? If the "RM case" was addressed to me, you need to tell me where and how ;-) I'd like to get the database up and running again, so I don't want to remain in this state forever...... Cheers, Thomas Am 07.09.2016 um 11:32 schrieb Ashesh Vashi: > On Wed, Sep 7, 2016 at 2:50 PM, Dave Page <dpage@pgadmin.org > <mailto:dpage@pgadmin.org>> wrote: > > On Wed, Sep 7, 2016 at 10:17 AM, Thomas Landauer <thomas@landauer.at > <mailto:thomas@landauer.at>> wrote: > > Hi folks, > > > > see attached screenshot - this appears when I click on "details". > > > > I doubt that the process is really still running. I restarted the computer, > > and meanwhile also deleted the mentioned backup-file. > > OK, I think Ashesh would be be better placed to suggest a next step... > > We generally starts a background process, which will report back the > error code, stderr, and stdout back to the pgAdmin server as a file. > I think - you discovered a bug - the background process did not report > the status code back to pgAdmin server. > > I will take a look at it. > > Can you please create a RM case for the same? > > -- > > Thanks & Regards, > > Ashesh Vashi > EnterpriseDB INDIA: Enterprise PostgreSQL Company > <http://www.enterprisedb.com/> > > > /http://www.linkedin.com/in/asheshvashi/ > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > >
On Fri, Sep 9, 2016 at 8:43 AM, Thomas Landauer <thomas@landauer.at> wrote: > Hi Ashesh, > > so what am I supposed to do now? He's currently on leave for a couple of days. > If the "RM case" was addressed to me, you need to tell me where and how ;-) https://redmine.postgresql.org/projects/pgadmin4/issues/new You'll need a postgresql.org community account to login if you don't already have one - https://www.postgresql.org/account > I'd like to get the database up and running again, so I don't want to remain > in this state forever...... Oh sorry, I didn't realise it was down. You can call pg_restore directly from the command line for now; that's all that pgAdmin is doing behind the scenes: https://www.postgresql.org/docs/current/static/app-pgrestore.html > Am 07.09.2016 um 11:32 schrieb Ashesh Vashi: >> >> On Wed, Sep 7, 2016 at 2:50 PM, Dave Page <dpage@pgadmin.org >> <mailto:dpage@pgadmin.org>> wrote: >> >> On Wed, Sep 7, 2016 at 10:17 AM, Thomas Landauer <thomas@landauer.at >> <mailto:thomas@landauer.at>> wrote: >> > Hi folks, >> > >> > see attached screenshot - this appears when I click on "details". >> > >> > I doubt that the process is really still running. I restarted the >> computer, >> > and meanwhile also deleted the mentioned backup-file. >> >> OK, I think Ashesh would be be better placed to suggest a next step... >> >> We generally starts a background process, which will report back the >> error code, stderr, and stdout back to the pgAdmin server as a file. >> I think - you discovered a bug - the background process did not report >> the status code back to pgAdmin server. >> >> I will take a look at it. >> >> Can you please create a RM case for the same? >> >> -- >> >> Thanks & Regards, >> >> Ashesh Vashi >> EnterpriseDB INDIA: Enterprise PostgreSQL Company >> <http://www.enterprisedb.com/> >> >> >> /http://www.linkedin.com/in/asheshvashi/ >> >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> >> > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Hi, OK, thanks - here's the issue: https://redmine.postgresql.org/issues/1679 Do you think this is relevant?: > Presumably there's a status file still on Thomas' machine, as the task keeps re-displaying. If yes, please tell where I can find it, and I'll attach it to the issue. For the initial "PostgreSQL Binary Path" question, I've created a short topic on stackoverflow: http://stackoverflow.com/questions/39408061/postgresql-binary-path-in-pgadmin-4-1-0-rc1 Cheers, Thomas