Re: [GENERAL] pg_upgrade & tablespaces
> [root@postgres-93-upgrade /usr/local/pgsql/data/drupal_dbspace]# ls -la
>> /home/jkregloh/pg_data/data/drupal_dbspace/
>> drwx-- 4 pgsql pgsql 4 Oct 20 2011 PG_9.0_201008051
>>
>
> So that looks like it worked, or am I missing something.
>
Yes, it works but once it gets to the step where it creates the relations I
get the error:
Copying user relation files
...l/data/drupal_dbspace/PG_9.0_201008051/2752430/10913518
error while copying relation "pg_catalog.pg_largeobject"
("/usr/local/pgsql/data/drupal_dbspace/PG_9.0_201008051/2752430/10913518"
to "/usr/local/pgsql/data/drupal_dbspace/PG_9.3_201306121/16499/12301"): No
such file or directory
>
>
>> Case B:
>> pg_upgrade -b /home/jkregloh/pg_bin/ -B /usr/local/bin/ -D
>> /usr/local/pgsql_93/data -d /usr/local/pgsql/data/ -P 5452 -p 5451
>>
>
> You realize order of switches is not important, but case is, where lower
> case is old version, upper is new version. I mention this because the ports
> are switched again, assuming your previous statement is correct:
>
> " But the ports I am using are 5451 for 9.3 and 5452 for 9.0."
>
Thanks for pointing this out. I reset and ran:
pg_upgrade -b /home/jkregloh/pg_bin/ -B /usr/local/bin/ -D
/usr/local/pgsql_93/data -d /usr/local/pgsql/data/ -p 5452 -P 5451
Same results as I posted previously for Case B.
>> [pgsql@postgres-93-upgrade /usr/local/pgsql_93/data/drupal_dbspace]$ ls
>> -la /usr/local/pgsql/data/drupal_dbspace/
>> drwx-- 4 pgsql pgsql 4 Oct 20 2011 PG_9.0_201008051
>> drwx-- 3 pgsql pgsql 3 Dec 20 16:44 PG_9.3_201306121
>>
>
> To me this looks crossed wires, possibly from the crossed ports above.
>
> What has me confused is where /usr/local/pgsql_93/data comes from?
> Did you actually install a Postgres 9.3 instance there?
> Or is the 9.3 instance installed in the location in Case A
> /usr/local/pgsql/data/ ?
>
>
For Case B I switch it around the /usr/local/pgsql/data belongs to 9.0 and
/usr/local/pgsql_93/data belongs to 9.3. This I found allows me to not get
the same error as I do in Case A.
/usr/local/pgsql_93/data is the data dir of the 9.3 cluster, created using
/usr/local/bin/initdb -D /usr/local/pgsql_93/data
>
> The rest of the message I will leave alone as I pretty sure you are seeing
> the results of a crossed install.
>
>
>
> --
> Adrian Klaver
> adrian.kla...@gmail.com
>
[GENERAL] Unix domain socket inconsistency
Hi all, I'm a bit confused by my development set up. I can connect to PostgreSQL using unix domain sockets by not specifying any host with psql, and the same applies to vacuumdb, createdb and dropdb. However, when I go to use pgbench, it seems to be looking in the wrong place for the domain socket: thom@swift ~/Development/postgresql $ psql postgres psql (9.4devel) Type "help" for help. postgres=# \q thom@swift ~/Development/postgresql $ createdb pgbench thom@swift ~/Development/postgresql $ pgbench -i -s 20 pgbench Connection to database "pgbench" failed: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5488"? The actual location is /tmp/.s.PGSQL.5488: thom@swift ~/Development/postgresql $ pg_ctl stop waiting for server to shut downLOG: received smart shutdown request LOG: autovacuum launcher shutting down LOG: shutting down LOG: database system is shut down done server stopped thom@swift ~/Development/postgresql $ psql postgres psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5488"? What am I missing? -- Thom -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Unix domain socket inconsistency
On 12/22/2013 04:51 PM, Thom Brown wrote: PostgreSQL using unix domain sockets by not specifying any host with psql, and the same applies to vacuumdb, createdb and dropdb. However, when I go to use pgbench, it seems to be looking in the wrong place for the domain socket: thom@swift ~/Development/postgresql $ psql postgres psql (9.4devel) Type "help" for help. postgres=# \q thom@swift ~/Development/postgresql $ createdb pgbench thom@swift ~/Development/postgresql $ pgbench -i -s 20 pgbench Connection to database "pgbench" failed: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5488"? The actual location is /tmp/.s.PGSQL.5488: thom@swift ~/Development/postgresql $ pg_ctl stop waiting for server to shut downLOG: received smart shutdown request LOG: autovacuum launcher shutting down LOG: shutting down LOG: database system is shut down done server stopped thom@swift ~/Development/postgresql $ psql postgres psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5488"? What am I missing? Best guess pgbench is being run from a different install then rest of your Postgres set up. Might want to check whether you have more than one copy of pgbench and if so where they are in PATH. -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Unix domain socket inconsistency
On 23 December 2013 01:13, Adrian Klaver wrote: > On 12/22/2013 04:51 PM, Thom Brown wrote: > >> PostgreSQL using unix domain sockets by not specifying any host with >> psql, and the same applies to vacuumdb, createdb and dropdb. However, >> when I go to use pgbench, it seems to be looking in the wrong place >> for the domain socket: >> >> thom@swift ~/Development/postgresql $ psql postgres >> psql (9.4devel) >> Type "help" for help. >> >> postgres=# \q >> thom@swift ~/Development/postgresql $ createdb pgbench >> thom@swift ~/Development/postgresql $ pgbench -i -s 20 pgbench >> Connection to database "pgbench" failed: >> could not connect to server: No such file or directory >> Is the server running locally and accepting >> connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5488"? >> >> The actual location is /tmp/.s.PGSQL.5488: >> >> thom@swift ~/Development/postgresql $ pg_ctl stop >> waiting for server to shut downLOG: received smart shutdown request >> LOG: autovacuum launcher shutting down >> LOG: shutting down >> LOG: database system is shut down >> done >> server stopped >> thom@swift ~/Development/postgresql $ psql postgres >> psql: could not connect to server: No such file or directory >> Is the server running locally and accepting >> connections on Unix domain socket "/tmp/.s.PGSQL.5488"? >> >> What am I missing? > > > Best guess pgbench is being run from a different install then rest of your > Postgres set up. Might want to check whether you have more than one copy of > pgbench and if so where they are in PATH. I should have mentioned that I've checked that: thom@swift ~/Development $ which psql pgbench /home/thom/Development/psql/bin//psql /home/thom/Development/psql/bin//pgbench -- Thom -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Unix domain socket inconsistency
On 23 December 2013 01:15, Thom Brown wrote: > On 23 December 2013 01:13, Adrian Klaver wrote: >> On 12/22/2013 04:51 PM, Thom Brown wrote: >> >>> PostgreSQL using unix domain sockets by not specifying any host with >>> psql, and the same applies to vacuumdb, createdb and dropdb. However, >>> when I go to use pgbench, it seems to be looking in the wrong place >>> for the domain socket: >>> >>> thom@swift ~/Development/postgresql $ psql postgres >>> psql (9.4devel) >>> Type "help" for help. >>> >>> postgres=# \q >>> thom@swift ~/Development/postgresql $ createdb pgbench >>> thom@swift ~/Development/postgresql $ pgbench -i -s 20 pgbench >>> Connection to database "pgbench" failed: >>> could not connect to server: No such file or directory >>> Is the server running locally and accepting >>> connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5488"? >>> >>> The actual location is /tmp/.s.PGSQL.5488: >>> >>> thom@swift ~/Development/postgresql $ pg_ctl stop >>> waiting for server to shut downLOG: received smart shutdown request >>> LOG: autovacuum launcher shutting down >>> LOG: shutting down >>> LOG: database system is shut down >>> done >>> server stopped >>> thom@swift ~/Development/postgresql $ psql postgres >>> psql: could not connect to server: No such file or directory >>> Is the server running locally and accepting >>> connections on Unix domain socket "/tmp/.s.PGSQL.5488"? >>> >>> What am I missing? >> >> >> Best guess pgbench is being run from a different install then rest of your >> Postgres set up. Might want to check whether you have more than one copy of >> pgbench and if so where they are in PATH. > > I should have mentioned that I've checked that: > > thom@swift ~/Development $ which psql pgbench > /home/thom/Development/psql/bin//psql > /home/thom/Development/psql/bin//pgbench Hmm... now this is odd. I went to correct the PATH information in my .bashrc script file (to remove the superfluous trailing forward-slash), and when running both psql and pgbench in a new terminal, all is fine: thom@swift ~/Development $ which psql pgbench /home/thom/Development/psql/bin/psql /home/thom/Development/psql/bin/pgbench thom@swift ~/Development $ psql postgres psql (9.4devel) Type "help" for help. postgres=# \q thom@swift ~/Development $ pgbench -i -s 20 pgbench NOTICE: table "pgbench_history" does not exist, skipping NOTICE: table "pgbench_tellers" does not exist, skipping NOTICE: table "pgbench_accounts" does not exist, skipping NOTICE: table "pgbench_branches" does not exist, skipping creating tables... 10 of 200 tuples (5%) done (elapsed 0.10 s, remaining 1.86 s). 20 of 200 tuples (10%) done (elapsed 0.19 s, remaining 1.72 s). ... So it's all working now, but I don't know why. I don't think that change would be the thing that fixed it. Perhaps it's something to do with me attempting to run pgbench before building the development contrib module of it, so it picks up the OS package-installed version, and when I go to build the local dev version, it has cached the location for the domain socket from the previous attempt. *shrug* -- Thom -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Unix domain socket inconsistency
On 12/22/2013 05:21 PM, Thom Brown wrote: On 23 December 2013 01:15, Thom Brown wrote: On 23 December 2013 01:13, Adrian Klaver wrote: On 12/22/2013 04:51 PM, Thom Brown wrote: I should have mentioned that I've checked that: thom@swift ~/Development $ which psql pgbench /home/thom/Development/psql/bin//psql /home/thom/Development/psql/bin//pgbench Hmm... now this is odd. I went to correct the PATH information in my .bashrc script file (to remove the superfluous trailing forward-slash), and when running both psql and pgbench in a new terminal, all is fine: thom@swift ~/Development $ which psql pgbench /home/thom/Development/psql/bin/psql /home/thom/Development/psql/bin/pgbench thom@swift ~/Development $ psql postgres psql (9.4devel) Type "help" for help. postgres=# \q thom@swift ~/Development $ pgbench -i -s 20 pgbench NOTICE: table "pgbench_history" does not exist, skipping NOTICE: table "pgbench_tellers" does not exist, skipping NOTICE: table "pgbench_accounts" does not exist, skipping NOTICE: table "pgbench_branches" does not exist, skipping creating tables... 10 of 200 tuples (5%) done (elapsed 0.10 s, remaining 1.86 s). 20 of 200 tuples (10%) done (elapsed 0.19 s, remaining 1.72 s). ... So it's all working now, but I don't know why. I don't think that change would be the thing that fixed it. Perhaps it's something to do with me attempting to run pgbench before building the development contrib module of it, so it picks up the OS package-installed version, and when I go to build the local dev version, it has cached the location for the domain socket from the previous attempt. *shrug* That's what I like, problems that fix themselves:) -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Unix domain socket inconsistency
On 12/22/2013 5:21 PM, Thom Brown wrote: Hmm... now this is odd. I went to correct the PATH information in my .bashrc script file (to remove the superfluous trailing forward-slash), and when running both psql and pgbench in a new terminal, all is fine: fyi, I was going to suggest ther'es more than one libpq.so on your system, and for whatever reason the failing program was loading the wrong one. this VERY frequently happens on mac OSX systems, as OSX provides a libpq.so which doesn't use the same socket path as most of the OSX postgres server distributions. -- john r pierce 37N 122W somewhere on the middle of the left coast -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] index and table corruption
> >Thanks Shaun! > >Yes, we're getting synchronous_commit on right now. > >The log_min_duration was briefly set to 0 at the time I sent out the post, >just to see what statements were logged right before everything went to >hell. Didn't yield much since we very quickly realized we couldn't cope >with the volume of logs. > >We also noticed that when trying to recover from a snapshot and replay >archived wal logs, it would corrupt right away, in under an hour. When >recovering from snapshots *without* replaying wal logs, we go on for a day >or two without the problem, so it does seem like wal logs are probably not >being flushed to disk as expected. > >Will update once we get onto the new h/w to see if that fixes it. >>> FYI - the change of server hardware didn't help >>> Also, I'm able to run a full pg_dump of the database (without output >>>to /dev/null) and it completes okay. >>> And then a few hours later the issue shows up again >>> We run an ext3 filesystem with journaling=ordered, and kernel 2.6.18 >>> Currently testing an upgrade to the kernel and turning off journaling >>>on the filesystem to see if that will help > >Thanks, >Karthik > > > >-- >Sent via pgsql-general mailing list (pgsql-general@postgresql.org) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
