Stefan Schwarzer writes:
> I do as indicated in Kyngchaos ReadMe file:
> export PATH="/usr/local/pgsql-9.1/bin:$PATH"
> export USE_PGXS=1
> make
> sudo make install
I'm beginning to wonder who are Kyngchaos and whether they are competent
at all. They obviously didn't test the ab
>> I do as indicated in Kyngchaos ReadMe file:
>
>>export PATH="/usr/local/pgsql-9.1/bin:$PATH"
>>export USE_PGXS=1
>>make
>>sudo make install
>
> I'm beginning to wonder who are Kyngchaos and whether they are competent
> at all. They obviously didn't test the above advice. It d
Like I said in my original post, I understand the workaround. I just
think that:
1) The workaround requires extra work for each developer (or at least
each client application) using PostgreSQL, while a fix in PostgreSQL
would solve this once and for all.
2) The workaround requires superuser pr
2012/6/21 P. Broennimann :
> Hi there
>
> In my stored function I use:
>
> select query_to_xml('select * from table12', true, true, '') into ...
>
>
> The result is OK but there is always an empty line:
>
> http://www.w3.org/2001/XMLSchema-instance";>
> <-- Empty lin
-Message d'origine-
De : Merlin Moncure [mailto:mmonc...@gmail.com]
Envoyé : June-20-12 11:36 AM
It should pretty much work. The main thing to watch out for is that very large
results sets will hit the upper limit on memory allocations.
merlin
De : Craig Ringer [mailto:r
Hello,
is there a way to read the storage parameters values set on a table
(i.e. what set with ALTER TABLE foo SET (autovacuum_enabled=false) and
so on...)? I can't find it in the docs.
-- Daniele
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subs
On Thu, Jun 21, 2012 at 2:03 PM, Evan Martin
wrote:
> 1) The workaround requires extra work for each developer (or at least each
> client application) using PostgreSQL, while a fix in PostgreSQL would solve
> this once and for all.
It is not clean what database you need to reconnect automatically
On 21 June 2012 13:12, Daniele Varrazzo wrote:
> Hello,
>
> is there a way to read the storage parameters values set on a table
> (i.e. what set with ALTER TABLE foo SET (autovacuum_enabled=false) and
> so on...)? I can't find it in the docs.
SELECT c.reloptions
FROM pg_class c
INNER JOIN pg_name
On Thu, Jun 21, 2012 at 5:42 PM, Daniele Varrazzo <
daniele.varra...@gmail.com> wrote:
> Hello,
>
> is there a way to read the storage parameters values set on a table
> (i.e. what set with ALTER TABLE foo SET (autovacuum_enabled=false) and
> so on...)? I can't find it in the docs.
>
>
One way is
On Thu, Jun 21, 2012 at 1:26 PM, Thom Brown wrote:
> On 21 June 2012 13:12, Daniele Varrazzo wrote:
>> Hello,
>>
>> is there a way to read the storage parameters values set on a table
>> (i.e. what set with ALTER TABLE foo SET (autovacuum_enabled=false) and
>> so on...)? I can't find it in the do
On 21/06/2012 10:20 PM, Sergey Konoplev wrote:
On Thu, Jun 21, 2012 at 2:03 PM, Evan Martin
wrote:
1) The workaround requires extra work for each developer (or at least each
client application) using PostgreSQL, while a fix in PostgreSQL would solve
this once and for all.
It is not clean what
>
>
> SELECT pg_terminate_backend(procpid)
> FROM pg_stat_activity
> WHERE datname = 'dropme';
>
> ERROR: must be superuser to signal other server processes
>
> You can try this approach.
http://archives.postgresql.org/pgsql-general/2012-04/msg00100.php
---
Regards,
Raghavendra
EnterpriseDB Corp
Evan Martin wrote:
> Like I said in my original post, I understand the workaround. I just
> think that:
>
> 1) The workaround requires extra work for each developer (or at least
> each client application) using PostgreSQL, while a fix in PostgreSQL
> would solve this once and for all.
For a devel
Evan Martin writes:
> That's a fair point, so perhaps DROP DATABASE should still fail if the
> /current/ connection is to that database (preferably with a helpful
> error like "you cannot drop the database you are connected to").
It does that.
> SELECT pg_terminate_backend(procpid)
> FROM pg_s
On 06/20/2012 10:40 PM, Stefan Schwarzer wrote:
I need unfortunately to come back to this issue. I (again) re-installed Lion
from scratch, and finally got everything working. The Postgres was running, I
uploaded a couple of dumped SQL files. And then re-started the machine for
another reason
(9.1.4)
Hello,
following query is wrong in my understanding, as it doesn't specify
which oid to use (pg_proc or pg_roles ?)
but it is accepted by the parser
select pg_get_functiondef(oid) -- should be
pg_get_functiondef(pg_proc.oid)
from pg_proc join pg_roles
on ( pg_proc.proowner
On 22/06/2012 12:07 AM, Tom Lane wrote:
SELECT pg_terminate_backend(procpid)
FROM pg_stat_activity
WHERE datname = 'dropme';
ERROR: must be superuser to signal other server processes
As far as that goes, there's a pending patch to reduce the privileges
required to use pg_terminate_backend. I'm
Hi all,
Given a cluster of three database servers running 9.1.3 (master, sync
slave, async slave), it seems that there are two ways to promote the sync
slave to become master:
1. pg_ctl promote the sync slave (increments timeline counter)
2. remove recovery.conf on the sync slave and pg_ctl rest
I'm writing a tool for web-based management of DNS records, and I've
come up against a UI nuisance that I'm hoping I can get solved in
Postgres instead of some higher layer.
One table contains all of the live records:
CREATE TABLE records (
domain_id integer NOT NULL DEFAULT 0,
rdns_id in
"Marc Mamin" writes:
> following query is wrong in my understanding, as it doesn't specify
> which oid to use (pg_proc or pg_roles ?)
> but it is accepted by the parser
> select pg_get_functiondef(oid) -- should be
> pg_get_functiondef(pg_proc.oid)
> from pg_proc join pg_roles
> on
On Jun 21, 2012, at 8:45 AM, Kris Deugau wrote:
> I'm writing a tool for web-based management of DNS records, and I've
> come up against a UI nuisance that I'm hoping I can get solved in
> Postgres instead of some higher layer.
>
> One table contains all of the live records:
>
> CREATE TABLE re
Steve Atkins wrote:
>
> On Jun 21, 2012, at 8:45 AM, Kris Deugau wrote:
>> CREATE TABLE records (
>>domain_id integer NOT NULL DEFAULT 0,
>>rdns_id integer NOT NULL DEFAULT 0,
>>record_id serial NOT NULL,
>>host text DEFAULT '' NOT NULL,
>>"type" integer DEFAULT 1 NOT NULL,
>>
On Thu, Jun 21, 2012 at 10:10 AM, David Pirotte wrote:
>
> 2ndQuadrant's repmgr uses the second option so that the async slave can
> "follow" the new master, saving you from having to do a new base backup.
> Additionally, the old master is able to start streaming replication from the
> new master
On 21 June 2012 16:10, David Pirotte wrote:
> So, given a hard failure (i.e. power loss) of the master, `pg_ctl promote`
> provides availability more quickly, but `pg_ctl restart` provides data
> redundancy more quickly.
Not sure where this idea of "more quickly" comes from. Can you explain?
>
>>
>> When I do: sudo launchctl load
>> /Library/LaunchDaemons/org.postgresql.postgres.plist
>> it says: org.postgresql.postgres: Already loaded
>>
>> When I do: /usr/local/pgsql-9.1/bin/initdb -U postgres -D
>> /usr/local/pgsql-9.1/data --encoding=UTF8 --locale=en_US
>> it s
25 matches
Mail list logo
