2014-03-14 4:26 GMT+09:00 :
> PostgreSQL 9.3.3 RHEL 6.4
>
> Total db Server memory 64GB
(...)
> effective_cache_size = 48MB
I'm not sure if this will help directly, but is the value for
'effective_cache_size' intentional? 48 *GB* would be a more likely
setting.
Regards
Ian Barwick
--
Sent v
On Thu, Mar 13, 2014 at 12:26 PM, wrote:
> *** Problem Query ***
>
> explain (analyze on, buffers on) Select * from measurement this_
> where this_.logdate between '2007-12-19
> 23:38:41.22'::timestamp and '2007-12-20 08:01:04.22'::timestamp
>
The only one that comes out different is inet_server_addr, via the
program, it comes out:
::1
whereas via psql it comes out empty.
Yes, I am 100% sure I am using the same schema (which I never specify, so I
am using 'public') and the same user and database.
Susan
On Thu, Mar 13, 2014 at 1:53
I finally figured it out, after changing my code to output the lines per
the number of rows of output, instead of until data[0] was blank. It
turned out that data[0] was sometimes blank, and I forgot about that, and
was stopping the output after I got back an empty record (or so I thought).
So, a
On 03/13/2014 03:23 PM, Susan Cassidy wrote:
The only one that comes out different is inet_server_addr, via the
program, it comes out:
::1
whereas via psql it comes out empty.
Yes, I am 100% sure I am using the same schema (which I never specify,
so I am using 'public') and the same user and
You asked for it (by the way, just p is asking for a lot of output):
root23 0.0 0.0 0 0 ?SFeb20 0:00 [cgroup]
root24 0.0 0.0 0 0 ?SFeb20 0:00 [khelper]
root27 0.0 0.0 0 0 ?SFeb20 0:00 [pm]
root
On 03/13/2014 02:44 PM, Susan Cassidy wrote:
No, I don't have 2 instances running. I default the port on the psql
command line, and the perl program is using 5432, as normal.
Now, I'm discovering that syslog is no longer logging anything. I
bounced it, but to no avail.
Susan
On Thu, Mar
On Thu, 13 Mar 2014 13:44:48 -0700
Susan Cassidy wrote:
> No, I don't have 2 instances running. I default the port on the psql
> command line, and the perl program is using 5432, as normal.
>
> Now, I'm discovering that syslog is no longer logging anything. I
> bounced it, but to no avail.
Th
1)
Run both "psql" and "perl" under "strace" and search the output for which
sockets it connects to.
eg, strace -o /tmp/psql.log psql -Upgsql -dmydatabase -c"select
version();"
2)
Add a query into your perl script to perform the following SQL and print
the results:
select current_database();
No, I don't have 2 instances running. I default the port on the psql
command line, and the perl program is using 5432, as normal.
Now, I'm discovering that syslog is no longer logging anything. I bounced
it, but to no avail.
Susan
On Thu, Mar 13, 2014 at 1:34 PM, Rodrigo Gonzalez wrote:
> O
On Thu, 13 Mar 2014 13:28:38 -0700
Susan Cassidy wrote:
> No, it is connecting to localhost, which is the same system I am
> running psql on.
>
> Susan
>
Well, if one query is logged and the other one is not it means that it
is running against different servers (as far as I understand
logging).
No, it is connecting to localhost, which is the same system I am running
psql on.
Susan
On Thu, Mar 13, 2014 at 1:26 PM, Rodrigo Gonzalez wrote:
> On Thu, 13 Mar 2014 13:20:53 -0700
> Susan Cassidy wrote:
>
> > Another odd thing is that it is apparently not logging statements from
> > Perl, o
On Thu, 13 Mar 2014 13:20:53 -0700
Susan Cassidy wrote:
> Another odd thing is that it is apparently not logging statements from
> Perl, only from psql. I don't know why. I thought I had it set up
> right to log to syslog. I've had good luck before with that on other
> installations.
>
I can
On Mar 13, 2014, at 1:20 PM, Susan Cassidy
wrote:
> Yes, I am running with use strict. The statement I pasted in is after perl
> quoting, being written out by the same perl program. I just take that
> statement and paste it into the psql window.
>
> DBI->trace showed nothing out of the ord
No, I am connecting to the right database, as my log info shows. No
duplicate table names, except in different databases. Those tables show
all the data I expect, oddly enough, if I connect the perl program to that
database. It is only this database that is giving me trouble. Which is
another o
Yes, I am running with use strict. The statement I pasted in is after perl
quoting, being written out by the same perl program. I just take that
statement and paste it into the psql window.
DBI->trace showed nothing out of the ordinary. It just shows the lines
being fetched that I am seeing in
On Mar 13, 2014, at 12:18 PM, Susan Cassidy
wrote:
> I have a weird issue that I can't figure out.
>
> If I run the exact same query through psql as through perl DBI, I get
> different results. I get far fewer results with DBI than through the psql
> command line.
>
> Any ideas why that wo
2014-03-13 20:26 GMT+01:00 :
> PostgreSQL 9.3.3 RHEL 6.4
>
> Total db Server memory 64GB
>
>
> # -
> # PostgreSQL configuration file
> # -
> max_connections = 100
> shared_buffers = 16GB
> work_mem = 32MB
> maintenance_work_mem = 1GB
> seq_pa
On Mar 13, 2014, at 12:18 PM, Susan Cassidy
wrote:
> I copied and pasted the query from the program's log file, so I know I'm
> doing the exact same query. If it matters, I'm only seeing the rows with
> 'root' in them via DBI, which the CASE statement refers to.
Try enabling full query l
PostgreSQL 9.3.3 RHEL 6.4Total db Server memory 64GB# -# PostgreSQL configuration file# -max_connections = 100shared_buffers = 16GBwork_mem = 32MB maintenance_work_mem = 1GBseq_page_cost = 1.0 random_p
Susan Cassidy writes:
> I have a weird issue that I can't figure out.
> If I run the exact same query through psql as through perl DBI, I get
> different results. I get far fewer results with DBI than through the psql
> command line.
Any possibility that the perl program is connecting to a diffe
On Thu, Mar 13, 2014 at 12:15 PM, Joe Van Dyk wrote:
> I've got a postgresql 9.3.2 server, compiled from scratch. Getting this
> error:
>
> # select hstore('a', 'b')::json;
> ERROR: cannot cast type hstore to json
> LINE 1: select hstore('a', 'b')::json;
>^
> # se
Joe Van Dyk writes:
> I've got a postgresql 9.3.2 server, compiled from scratch. Getting this
> error:
> # select hstore('a', 'b')::json;
> ERROR: cannot cast type hstore to json
Probably need to update the hstore extension to 1.2.
regards, tom lane
--
Sent via pgsql
I have a weird issue that I can't figure out.
If I run the exact same query through psql as through perl DBI, I get
different results. I get far fewer results with DBI than through the psql
command line.
Any ideas why that would be?
The query is:
SELECT st.description, st.scene_thing_instan
I've got a postgresql 9.3.2 server, compiled from scratch. Getting this
error:
# select hstore('a', 'b')::json;
ERROR: cannot cast type hstore to json
LINE 1: select hstore('a', 'b')::json;
^
# select array_to_json(array[hstore('a', 'b')]);
array_to_json
-
I have the same problem. I have a log like patrick keshishian. I have not a
backup.
I don't know that do.
Help me please!!!
Information:
- Server with RAID1 on SAS HD Hot-plug.
- Ubuntu Server 12.04 x64.
- Postgresql 9.1.
When I do "psql" PostgreSQL shows "psql: FATAL: the database system is
s
On 13.03.2014 13:02, Magnus Hagander wrote:
> My guess is you're looking in the wrong place in the docs - can you specify
> where you are looking? If you are in the right place then the docs are
> wrong.
Here: http://www.postgresql.org/docs/8.4/static/sql-createtable.html
> Deferrable unique con
On Thu, Mar 13, 2014 at 12:59 PM, Johannes Bauer wrote:
> Hi list,
>
> I'm having trouble with a UNIQUE constraint that I need to have
> DEFERRABLE INITIALLY DEFERRED. On my Dev machine (Postgres 9.1) it works
> fine:
>
> alter table foo drop constraint bar;
> ALTER TABLE
>
> alter table foo add c
Hi list,
I'm having trouble with a UNIQUE constraint that I need to have
DEFERRABLE INITIALLY DEFERRED. On my Dev machine (Postgres 9.1) it works
fine:
alter table foo drop constraint bar;
ALTER TABLE
alter table foo add constraint bar UNIQUE (col1, col2) deferrable
initially deferred;
ALTER TAB
29 matches
Mail list logo
