fluxh wrote
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:
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
On Thu, Mar 13, 2014 at 12:59 PM, Johannes Bauer dfnsonfsdu...@gmx.dewrote:
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
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
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
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 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,
Joe Van Dyk j...@tanga.com 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
--
On Thu, Mar 13, 2014 at 12:15 PM, Joe Van Dyk j...@tanga.com 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;
Susan Cassidy susan.cass...@decisionsciencescorp.com 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
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_page_cost = 2.0 cpu_tuple_cost = 0.03
On Mar 13, 2014, at 12:18 PM, Susan Cassidy
susan.cass...@decisionsciencescorp.com 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
2014-03-13 20:26 GMT+01:00 fburg...@radiantblue.com:
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 =
On Mar 13, 2014, at 12:18 PM, Susan Cassidy
susan.cass...@decisionsciencescorp.com 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
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
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
On Mar 13, 2014, at 1:20 PM, Susan Cassidy
susan.cass...@decisionsciencescorp.com 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.
On Thu, 13 Mar 2014 13:20:53 -0700
Susan Cassidy susan.cass...@decisionsciencescorp.com 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
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 rjgonzale.li...@gmail.com
wrote:
On Thu, 13 Mar 2014 13:20:53 -0700
Susan Cassidy susan.cass...@decisionsciencescorp.com wrote:
Another odd thing is
On Thu, 13 Mar 2014 13:28:38 -0700
Susan Cassidy susan.cass...@decisionsciencescorp.com 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
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
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 -cselect
version();
2)
Add a query into your perl script to perform the following SQL and print
the results:
select current_database();
On Thu, 13 Mar 2014 13:44:48 -0700
Susan Cassidy susan.cass...@decisionsciencescorp.com 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
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
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 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
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,
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
On Thu, Mar 13, 2014 at 12:26 PM, fburg...@radiantblue.com 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
2014-03-14 4:26 GMT+09:00 fburg...@radiantblue.com:
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
30 matches
Mail list logo
