postgres=#create table public.sample(x int);
> postgres=#create schema new;
>> postgres=#create table new.sample(x int);
>> postgres=#set search_path=public,new;
>>
>> postgres=#\dt
>> Schema | Name | Type | Owner
>> --**-
>> public | sample | table
On 02.10.2011 08:31, Nikhil Sontakke wrote:
Consider the following sequence of commands in a psql session:
postgres=#create table public.sample(x int);
postgres=#create schema new;
postgres=#create table new.sample(x int);
postgres=#set search_path=public,new;
postgres=#\dt
Schema | Name | Type
Hi,
Consider the following sequence of commands in a psql session:
postgres=#create table public.sample(x int);
postgres=#create schema new;
postgres=#create table new.sample(x int);
postgres=#set search_path=public,new;
postgres=#\dt
Schema | Name | Type | Owner
On 01-10-2011 17:44, Daniel Farina wrote:
On Fri, Sep 30, 2011 at 9:30 PM, Tom Lane wrote:
ISTM it would be reasonably non-controversial to allow users to issue
pg_cancel_backend against other sessions logged in as the same userID.
The question is whether to go further than that, and if so how
On 10/01/2011 05:48 PM, Joe Abbate wrote:
On 10/01/2011 05:08 PM, Andrew Dunstan wrote:
While investigating a client problem I just observed that pg_dump takes
a surprisingly large amount of time to dump a schema with a large number
of views. The client's hardware is quite spiffy, and yet pg_d
Robert Haas wrote:
On Tue, Sep 27, 2011 at 6:30 PM, Tom Lane wrote:
If I have to break up the recipe with annotations like "run this part as
root" and then "these commands no longer need root", I don't think
that's going to be an improvement over either of the above.
Fair enough, I'm not g
"""
In *every* case -- and there are many -- where we've had people
express pain, this would have sufficed. Usually the problem is a
large index creation gone awry, or an automated backup process
blocking a schema change that has taken half the locks it needs, or
something like that -- all by the
On Sat, Oct 1, 2011 at 3:47 PM, Kääriäinen Anssi
wrote:
> I would be a step in the right direction if the DB owner would see all queries
> to the DB in pg_stat_activity.
"All," including that of the superuser? I'd like to pass on that one, please.
In general, I feel there is this problem that on
Mr. Aaron W. Swenson wrote:
> I went through several iterations trying to find a command that can work
> the way we'd like it to. (Essentially is works the way you're describing
> it should.) So, in Gentoo, for the initscript, we have this really ugly
> command to start the server:
>
> su -l p
On 10/01/2011 05:08 PM, Andrew Dunstan wrote:
> While investigating a client problem I just observed that pg_dump takes
> a surprisingly large amount of time to dump a schema with a large number
> of views. The client's hardware is quite spiffy, and yet pg_dump is
> taking many minutes to dump a sc
On Sat, Oct 01, 2011 at 02:08:33PM -0400, Bruce Momjian wrote:
> In researching pg_ctl -w/wait mode for pg_upgrade, I found that pg_ctl
> -w's handling of configuration-only directories is often incorrect. For
> example, 'pg_ctl -w stop' checks for the postmaster.pid file to
> determine when the s
While investigating a client problem I just observed that pg_dump takes
a surprisingly large amount of time to dump a schema with a large number
of views. The client's hardware is quite spiffy, and yet pg_dump is
taking many minutes to dump a schema with some 35,000 views. Here's a
simple test
On Fri, Sep 30, 2011 at 9:30 PM, Tom Lane wrote:
> ISTM it would be reasonably non-controversial to allow users to issue
> pg_cancel_backend against other sessions logged in as the same userID.
> The question is whether to go further than that, and if so how much.
In *every* case -- and there are
On Sep 23, 2011, at 11:37 AM, Robert Haas wrote:
> Another thing I'm not sure whether to worry about is the question of
> where we store the vacuum generation information. I mean, if we store
> it in pg_class, then what happens if the user does a manual update of
> pg_class just as we're updating
In researching pg_ctl -w/wait mode for pg_upgrade, I found that pg_ctl
-w's handling of configuration-only directories is often incorrect. For
example, 'pg_ctl -w stop' checks for the postmaster.pid file to
determine when the server is shut down, but there is no postmaster.pid
file in the config d
Marti Raudsepp writes:
> On Wed, Sep 14, 2011 at 05:26, Kyotaro HORIGUCHI
> wrote:
>> This is a review for the patch `Generate column names for
>> subquery expressions'
>> (https://commitfest.postgresql.org/action/patch_view?id=632)
> Thanks for the review. :)
Applied with minor adjustments.
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> Yeah. I think the only sensible way to do this would be to provide an
> > >> operating mode for the postgres executable that would just parse the
> > >> config file and spit out requested values.
> >
>
I notice that we use '(none)' as a default for external_pid_file, while
other default no-value settings in the file are ''. The attached patch
changes this.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for e
18 matches
Mail list logo
