ything about broken
connections or client not responding?
Also, the pooler might maintanin some *minimum* number of
connections but go beyond that "on demand". Without knowing what
pooler and how it is configured, it's hard to say what might be
going on.
--
Kevin Grittner
E
not enough information to give much advice. Please read
this page and start a new thread on the pgsql-performance list:
http://wiki.postgresql.org/wiki/SlowQueryQuestions
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-admin ma
t if they all become active at one time, you can
have a seemingly-random server overload.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
hat direction a little at a time and watch the behavior. I
do think that periodic VACUUM ANALYZE statements (weekly?) of the
database might be a good supplement to the autovacuum jobs,
especially if you have a time when load tends to be lower to
schedule that in.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
ht pay to move to partitioning, so that a group of
rows could be deleted pretty much as fast as you can drop a table.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
es, table truncation after a large number of deletes is now
smarter, getting more done with less effort and blocking. This
message, which was useful for developing the fix, made it into
production at the LOG level. In the next minor release it will be
changed to the DEBUG level to avoid cluttering the
After getting past this crisis, I would take a close look at your
vacuuming regimen -- it sounds like it is not aggressive enough to
keep you out of trouble.
I'm sorry that I don't have a better suggestion for resolving the
crisis than running VACUUM at maximum speed.
--
Kevin Grittner
d of VACUUM was a shared table
and it just happened to mention db1 because that was the database
it was scanning at the time. (Every database includes the shared
system tables in its catalog.)
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsq
a couple large tables which take long enough
to scan to prevent small, frequently-updated tables from getting
attention soon enough, you might want to boost
autovacuum_max_workers, too.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-admi
;);
select * from pg_prepared_xacts where prepared < (now() - interval '1 minute');
You can, of course, adjust the intervals to what makes the most
sense for your environment. If you have max_prepared_transactions
set to zero, the latter query is not really necessary.
if that's what you mean.
> Which means it is consistent at the time that the pg_start_backup
> is run.
No. It will be consistent with the time that pg_stop_backup was
run, or any later point in time that you choose, as long as you
have WAL to that point in time.
--
Kevin Grittner
EDB: http://
pg_dumpall client had an
error writing, due to permissions problems or disk space
exhaustion, and the reason needs to be found on the "client" side,
not in the server log.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-admin mai
to have problems.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
to increase to 32 GB.
Well, you could try that; if the symptoms get worse, then you might
be willing to go the other direction
> max_connections = 500 and ~400 connections average
How many cores (not "hardware threads") does the machine have? You
will probably have better throughpu
I already did that. In fact, it works fine for pgAdmin III access from my
laptop to my db server.
Kevin Struckhoff, TDWI
Sr. IT Mgr, LA DR Operations
kstruckh...@ebay.comebayenterprise.com
o: 818.686.4719 | c: 818.968.0634 |
The information contained in this electronic mail
Thanks Alvaro, that works. Appreciate the help.
Kevin Struckhoff, TDWI
Sr. IT Mgr, LA DR Operations
kstruckh...@ebay.comebayenterprise.com
o: 818.686.4719 | c: 818.968.0634 |
The information contained in this electronic mail transmission is intended only
for the use of the individual
rg/docs/9.2/interactive/backup.html
Of course, the machines must be of the same architecture.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscri
"Struckhoff, Kevin" wrote:
> From: Kevin Grittner [mailto:kgri...@ymail.com]
>> "Struckhoff, Kevin" wrote:
>>> I've installed postgres 9.2 on a server, call it db01. I now want
>>> to access postgres from my app server, call it app01.
>&g
I'm trying to use the psql tool:
/home/postgres->psql test
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.5432"?
the answer of course is No..
Kevin Struc
Sorry, rhel 5.8. so there is a separate client install package?
Kevin Struckhoff, TDWI
Sr. IT Mgr, LA DR Operations
kstruckh...@ebay.comebayenterprise.com
o: 818.686.4719 | c: 818.968.0634 |
The information contained in this electronic mail transmission is intended only
for the use of
"Struckhoff, Kevin" wrote:
> I've installed postgres 9.2 on a server, call it db01. I now want
> to access postgres from my app server, call it app01.
>
> What do I install on the app01 server? I've installed postgres
> 9.2 on it and set the postgresesql.conf
both
machines. I've also modified the pg_hba.conf file to be wide open for now on
both machines.
It seems that something else is missing or needs to be done. Googling wasn't
much help, the results weren't current.
Any help would be appreciated. Thanks.
Kevin Struckhoff
kstruckh...@ebay.com
target was done while normal production hit the
database, without too much of a performance hit. With this
technique we were able to let users in with near-normal performance
with 10 or 15 minutes of down time rather than hours.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The E
t Albe assumed you deleted or truncated the
underlying disk file rather than using the DELETE or TRUNCATE SQL
statement.
In any event, more details would help people come up with ideas on
what might be wrong.
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
--
Kevin Grittner
Ent
large, shrank again, and then wrapped around to the
beginning of the table's file space. In some cases performance was
so impaired that when such an event was triggered they would shut
down their application until a manual VACUUM could be run.
--
Kevin Grittner
EnterpriseDB: http://www.enter
you.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
fects on the explicit command were
unintended and should be reverted.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
of those bug fixes and see if you can make it
happen again.
In general, it pays to apply fixes as they become available.
http://www.postgresql.org/support/versioning/
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-admin mailing l
ne
replica. To avoid stalls on the master, you may want to define
multiple synchronous replicas, so that when one goes down you keep
running without DBA intervention.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-admin mailing
ally want to avoid RULES, especially where a trigger works
so well.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Benjamin Krajmalnik wrote:
> Kevin Grittner wrote:
>> Benjamin Krajmalnik wrote:
>>> I also assume that if no data has changed in an index, nothing
>>> is done when the record is updated as pertains to the
>>> particular index - am I correct in this assumpt
l be on the index for a while.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
ent cancelations, since the lag can otherwise
accumulate.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
overy purposes.
It might be worthwhile to keep two standby clusters, one that is
aggressive about applying the latest transactions, and another
which allows long-running queries.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
for "*"
> 2013-01-10 01:58:46 PST FATAL: could not create any TCP/IP sockets
It would appear that something is probably already (or still)
running on port 5432 when you try to start.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your su
suhas.basavaraj12 wrote:
> We will be dumping data from version 9.0 and restore to 9.1.
That should work fine, as long as use use pg_dump from version
9.1 to dump the 9.0 database.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscript
nge.
http://www.postgresql.org/support/versioning/
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
t anyway, so it may be a
case of "the straw that broke the camel's back". Especially since
you made autovacuum many times more resource-hungry than it is by
default.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
clear that more frequent statistical sampling of
the tables would change the plans. Perhaps you should post one such
query to the performance list, with supporting data, and see
whether someone can suggest a way to speed that query.
http://wiki.postgresql.org/wiki/SlowQueryQuestions
-Ke
satish kumar wrote:
> How to convert Mysql procedures to Postgresql Functions using migration
> tools.
http://wiki.postgresql.org/wiki/Converting_from_other_Databases_to_PostgreSQL#MySQL
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes t
Kong Man wrote:
> The postgresql.conf file has always been using the default value, which is
> 'warning'.
Maybe it's not using the postgresql.conf file you think it is. Does
this show the file you've been looking at?:
SHOW config_file;
-Kevin
--
Sent via pgsql
you could start
`vmstat 1` before you let it get into this state, and capture `ps
aux | postgres`, pg_stat_activity, and pg_locks at intervals while
it is in this state. Looking at all of the above might suggest a
cause. If we can find the cause, we can almost certainly fix it.
-Kevin
--
Sent
f a bug is fixed which
could corrupt a particular type of index, the release notes may
recommend rebuilding all indexes of that type to repair any damage
which may have occurred before the bug was fixed.
http://www.postgresql.org/support/versioning/
-Kevin
--
Sent via pgsql-admin mailing lis
g on?
What messages related to autovacuum or deadlocks do you see in the
server log while this is going on?
> PostgreSQL 8.4.11
Would it be possible to update your 8.4 installation to the latest
bug fix (currently 8.4.15) to rule out the influence of any bugs
which have already been fixed?
-Kevin
as idle or (especially) idle in transaction. The query
column no longer shows anything other than a query.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
figuration
is better for that particular query. If the same configuration wins
in general, use it.
Since performance differences which are that small are often caused
by very obscure issues, it can be very difficult to pin down the
reason. It's generally not anything to fret over.
-Kevin
--
amjad usman wrote:
> ERROR: index row size 3176 exceeds maximum 2712 for
> index "description_department_of_aeronautics_and_astronautics_5_pkey"
Can you show us the definitions of the table and the index?
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgre
w both estimates and actual.
> One more thing Kevin, could you please help me out to understand
> how did calculate those parameters?
My own experience and reading about the experiences of others. If
you follow the pgsql-performance list, you will get a better "gut
feel" on these issues
til you have one
you can be less crippled on preformance by setting
synchronous_commit = off. The trade-off is that there will be a
slight delay between when PostgreSQL acknoleges a commit and when
the data is actually persisted.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.o
Haifeng Liu wrote:
> I wanna know if executeBatch really keep all the records in a
> batch untouched when the batch failed.
I recommend asking on the pgsql-jdbc list. You might want to
mention what autoCommit is set to during the attempt.
-Kevin
--
Sent via pgsql-admin mailing list
Sabry Sadiq wrote:
> Does it work well with version 9.1.3?
It might work better in 9.1.6:
http://www.postgresql.org/support/versioning/
And it would probably pay to keep up-to-date as new minor releases
become available.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-ad
20ms
Making VACUUM less aggressive usually backfires and causes
unacceptable performance, although that might not happen for days or
weeks after you make the configuration change.
By the way, the software is called PostgreSQL. It is often shortened
to Postgres, but "Postgre" is just
ex on both
> timestamp column. Will it be more efficient for us to configure the
> autovacuum daemon analyze task only on those columns ?
No.
> 4 * 300 Go Raid 0
You do realize that if any of those four drives fail you will need to
use your backup, right?
-Kevin
--
Sent via
o be good. Hardware? Load?
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
dmin-support list.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Bruce Momjian wrote:
> On Wed, Sep 12, 2012 at 10:13:38PM -0500, Kevin Grittner wrote:
>> Radovan Jablonovsky wrote:
>>
>>> In documentation
>>> http://www.postgresql.org/docs/9.1/static/routine-vacuuming.html
>>> is this inform
th working through some of the bumps in converting to
later versions. You should really be targeting the 9.1 release at
this point.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
| setting | min_val | max_val
---+---+---+
autovacuum_freeze_max_age | 2 | 1 | 20
(1 row)
Perhaps we should drop "a little less than" from the docs.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
d use a lot more
detail. What steps have you taken to get to where you are now?
Exactly what version of PostgreSQL is this (8.0.what?)?
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
Without knowing more, it's hard to give much advice.
-Kevin
--
Sent via pgsql-admin mail
ectory.
PostgreSQL is down only for the time it takes for a restart. We
normally do this during off-hours; but even if this is done during
normal operations, properly coded clients (which retry a database
transaction if it fails with a broken connection, without giving the
client any error) only see a short stutter in response time.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
ologies.
FWIW, on Linux I would start with `netstat -plnt` to see if the
process was listening on the expected port and host address.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
ior,
and to change code which counted on the implicit casts which were
eliminated in 8.3.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
[Forwarding to the -hackers list. Please respond there.]
Craig Ringer wrote:
> On 08/09/2012 04:24 AM, Kevin Grittner wrote:
>> http://wiki.postgresql.org/wiki/Number_Of_Database_Connections
>>
> Can we please please PLEASE link to that as a comment above
> max_connection
Craig Ringer wrote:
> On 08/09/2012 04:24 AM, Kevin Grittner wrote:
>> http://wiki.postgresql.org/wiki/Number_Of_Database_Connections
>>
> Can we please please PLEASE link to that as a comment above
> max_connections?
>
> Last time this came up nobody was happy wit
tabase_Connections
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
h a queue, including
the last person, will get their results sooner with such queuing
than turning loose a "thundering herd" of requests which puts the
system into swapping. I guarantee it.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes t
Majid Azimi wrote:
> ran VACUUM ANALYZE on it(it is not VACUUM FULL). but this cause
> the database to completely block.
Please show the results from running the query here:
http://wiki.postgresql.org/wiki/Server_Configuration
-Kevin
--
Sent via pgsql-admin mailing list (pgsql
we tend to ignore it in favor of ensuring that
it never comes into play. We run about 200 databases 24/7 and I
think I've seen it kick in about twice -- when we ran queries that
leaked memory on each row in a big query.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql
heavily
exercised. Less frequently executed code is more likely to have
subtle bugs which only show up in rare corner cases. I like to
minimize my risk.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
ql.org/wiki/SlowQueryQuestions
A wild guess on the evidence we have is that you might benefit from
an index on MCL.ctid if you don't already have one.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
can make sure it doesn't happen again. The contents of the
pg_xlog directory are an integral part of your database cluster.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
ent version of
PostgreSQL is likely to help some, too.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
PostgreSQL, click the link at the
top for the version you are using.
If you still have questions after reading the manual, feel free to
post with a more specific question.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.po
every minute by crontab but my
> concern is that the data inconsistent, because the lastest log in
> pg_xlog is being updated all the time, am I right? Any
> suggestions?
Use streaming replication? Or at the very least, set a short
archive_timeout value and copy from the archive tar
ity from the renderers to particular
database servers to keep a consistent timeline for each user
session. This sort of approach is a viable alternative to sharding
in some cases.
I hope that helps.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
that you will need
to split the database across machines; you might be right, but you
might be engaging in "premature optimization".
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
t case, how do I find out "effective_spindle_count"? I know
> "core_count" can be determined from Amazon EC2 instance type. Per
> Amazon EC2, EBS volumes are reportedly a shared resource.
I think you need to experiment with different pools sizes. Please
post results and/o
Elizandro Gallegos wrote:
> Please can I be removed from the mailing list
The answer was in the email to which you responded. Did you have
trouble using the referenced page?
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-admin
-Kevi
of WIP
for version 9.3 suggest that this formula will need adjustment on
that release. I haven't looked at how well the formula works with
SDDs. In any event, I would recommend using this as a starting
point for a connection pool size, and trying incremental adjustments
with your
rove the heuristic used
for promoting predicate locks of one granularity to another, to
allow a more graceful performance degradation when predicate locks
get tight, but I've lacked data on what sort of workloads hit this.
If you could send me (of list) a copy of your pg_locks data when you
are
"Fred Parkinson" wrote:
> 2. Is there way to tell psql NOT to clear the screen, so I can
> subsequently view it while I work?
\pset pager off
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgre
ool, but contention was
reducing performance, and we found that throughput and latency both
improved with a smaller pool of database connections.
If you want to handle more users than you can currently support, you
probably need to use fewer database connections.
-Kevin
--
Sent via pgsql
h for possible
problems afterward.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
"k...@rice.edu" wrote:
> You may also want to consider setting a statement_timeout to
> prevent this until you can find the problem with the application.
How would a statement timeout help close a transaction on an idle
connection? It's idle because no statements ar
le that are defined as
> AFTER triggers. The actual update and delete operation works,
> however the triggers do not seem to be firing. What am I doing
> wrong?
The DELETE and UPDATE triggers need to be on the child tables. An
operation on a child doesn't fire the triggers of the parent
ognize everything in the newer server,
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
.html
Also, please consider updating to 9.0.7.
http://www.postgresql.org/support/versioning/
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
2 12:14:12 IST LOG: unexpected EOF on client connection
> 2012-05-02 12:14:13 IST LOG: could not send data to client:
> Broken pipe
Those messages mean that the TCP connection from the client was
broken by something other than the PostgreSQL server.
-Kevin
--
Sent via pgsql-admin mailing l
Bèrto ëd Sèra wrote:
> I'm asked to benchmark a PG-related product. I was wondering if
> there is any "sort of standard" public dataset for such operations.
You might want to take a look at pgbench:
http://www.postgresql.org/docs/9.1/interactive/pgbench.html
-Kevi
On 04/28/2012 10:32 AM, Fernando Hevia wrote:
On Sat, Apr 28, 2012 at 13:10, Kevin Kempter
mailto:cs_...@consistentstate.com>> wrote:
All;
I just want to be sure that I'm not causing myself greif. I have
a kvm in the cloud that is supposed to have access to
All;
I just want to be sure that I'm not causing myself greif. I have a kvm
in the cloud that is supposed to have access to 32GB of ram. when I do a
top I only see 1GB of ram, I've pinged the hosting provider, maybe it
shows up as it's used?
Anyway when I try and start postgres I see this:
On 04/25/2012 10:50 PM, Tom Lane wrote:
Kevin Kempter writes:
I can scp files between the servers
Really?
$ psql -h 192.168.1.125
psql: could not connect to server: No route to host
Because that is not a Postgres problem, that is a network connectivity
problem. I'd bet that th
Hi all;
I've setup PostgreSQL to talk across servers thousand of times... not
sure what I'm doing wrong, maybe I'm just over-tired.
I have 2 scientific linux VM's running in vmware workstation
server 1 - 192.168.1.125
server 2 - 192.168.1.127
I've disabled selinux on both servers
Ive insta
Ricardo Bayley wrote:
> Does anybody know if it is possible to create a PL which sends an
> http GET request and retrieves its response ?
Have you looked at PL/Python?
http://www.postgresql.org/docs/current/interactive/plpython.html
-Kevin
--
Sent via pgsql-admin mailing list
@
> to_tsquery('hun'); does not return anything.
It sounds like trigrams might be a better fit for you than text
search.
http://www.postgresql.org/docs/9.1/static/pgtrgm.html
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
ant to understand internals like this, the best thing to do
is probably to read the source code.
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/utils/cache/relmapper.c;h=6f214957bf831c4a5c17ebc630f5151adc860135;hb=HEAD
-Kevin
--
Sent via pgsql-admin mailing list (pgs
tion of the hot standby feature
from the transaction logs which were originally used just for crash
recovery.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
the archived file name, would this
> adversely affect the restore_command and render the %f file coming
> back unusable?
Well, you could use a wildcard in the restore command to find a
matching file, but if there is more than one because of the
timestamps added to the filename, which one d
[rearranged; please don't top-post]
Wells Oliver wrote:
> Kevin Grittner > Wells Oliver wrote:
>>
>>> I'd like to create a schema on my slave so that users who do not
>>> have access to the master can create some data. Clearly this
>>> data
n the slave?
What are you using for replication?
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
1 - 100 of 1038 matches
Mail list logo
