On 19 May 2011 15:33, Robert Haas wrote:
> On Tue, May 17, 2011 at 2:44 PM, Dean Rasheed
> wrote:
>> The algorithm for this was discussed in the original thread
>> (http://archives.postgresql.org/pgsql-hackers/2010-10/msg02050.php)
>> but I don't that think a satisfactory conclusion was really r
Robert Haas wrote:
> Mark wrote:
>> Could somebody explain me on which methods is based ts_rank and
>> how it works? I would appreciate some articles, if exist.
> As far as I can tell, our documentation contains no useful
> information on this topic whatsoever. :-(
There's some potentially
On Thu, May 19, 2011 at 10:26 AM, Robert Haas wrote:
> At the risk of opening a can of worms, if we're going to fix \dd,
> shouldn't we fix it completely, and include comments on ALL the object
> types that can have them? IIRC it's missing a bunch, not just
> constraints.
You opened this can up,
From: "Andrew Dunstan"
On Thu, May 19, 2011 10:32 am, Robert Haas wrote:
2011/5/16 MauMau :
Can't open perl script "make-errcodes-table.pl": No such file or
directory
I think this is the root of the problem. We have no script called
make-errcodes-table.pl. Can you try changing it to
genera
2011/5/19 Robert Haas :
> On Thu, May 19, 2011 at 8:19 AM, Cédric Villemain
> wrote:
>> 2011/5/19 Robert Haas :
>>> On Tue, May 17, 2011 at 6:11 PM, Cédric Villemain
>>> wrote:
The point is to get ratio in cache, not the distribution of the data
in cache (pgfincore also allows you to se
There is no way to tell pg_basebackup to "just compress the thing in a
default way". You have to pick some number and then write -Z8 or
something. I suppose that interface was copied from pg_dump, but there
it's not that commonly used because the right formats are compressed by
default.
I sugges
On Thu, May 19, 2011 at 03:53:12PM -0400, Robert Haas wrote:
> On Thu, May 19, 2011 at 3:24 PM, Noah Misch wrote:
> > On Thu, May 19, 2011 at 11:42:03AM -0400, Robert Haas wrote:
> >> On Thu, May 19, 2011 at 11:13 AM, Noah Misch wrote:
> >> > It would solve the problem, but it would mean resettin
Excerpts from Robert Haas's message of jue may 19 15:32:57 -0400 2011:
> On Thu, May 19, 2011 at 1:48 PM, Alvaro Herrera
> > The following things acquire a lock on database:
> >
> > ALTER DATABASE SET
> > ALTER DATABASE OWNER
> > COMMENT ON DATABASE
> >
> > So as far as features that would caus
Apparently, you can write this (an attempt at a convenient workaround
for lack of functional dependency tracking pre-9.1):
SELECT pg_class.* FROM pg_class GROUP BY pg_class.*;
It won't work:
ERROR: 42803: column "pg_class.relname" must appear in the GROUP BY clause or
be used in an aggregate f
On Thu, May 19, 2011 at 3:17 PM, Alvaro Herrera wrote:
> Is there a reason we don't allow moving the toast table to a separate
> tablespace, other than unimplemented feature? If not, I propose such a
> syntax as
>
> ALTER TABLE foo SET TOAST TABLESPACE bar;
Off the top of my head, I don't see an
On Thu, May 19, 2011 at 3:24 PM, Noah Misch wrote:
> On Thu, May 19, 2011 at 11:42:03AM -0400, Robert Haas wrote:
>> On Thu, May 19, 2011 at 11:13 AM, Noah Misch wrote:
>> > It would solve the problem, but it would mean resetting unlogged relations
>> > on
>> > the standby at every shutdown chec
On Thu, May 19, 2011 at 1:48 PM, Alvaro Herrera
wrote:
>> I can't see getting rid of that lock, since we'd simply have to invent
>> some other interlock for new connections vs. DROP DATABASE. However,
>> I do think that we might sometime need to convert it to a session lock
>> that's held for the
On Thu, May 19, 2011 at 11:42:03AM -0400, Robert Haas wrote:
> On Thu, May 19, 2011 at 11:13 AM, Noah Misch wrote:
> > It would solve the problem, but it would mean resetting unlogged relations
> > on
> > the standby at every shutdown checkpoint. ?That's probably not a performance
> > problem, bu
Is there a reason we don't allow moving the toast table to a separate
tablespace, other than unimplemented feature? If not, I propose such a
syntax as
ALTER TABLE foo SET TOAST TABLESPACE bar;
--
Álvaro Herrera
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
* Greg Stark (st...@mit.edu) wrote:
> On Thu, May 19, 2011 at 1:53 PM, Stephen Frost wrote:
> > Quick code-only review: sortedAttrs is a horrible var name for what it
> > is. More like 'sortbyName' would make more sense, at least to me.
> > Also, no regression test..? :)
>
> Do we have regressio
On Thu, May 19, 2011 at 1:53 PM, Stephen Frost wrote:
> Quick code-only review: sortedAttrs is a horrible var name for what it
> is. More like 'sortbyName' would make more sense, at least to me.
> Also, no regression test..? :)
Do we have regression tests for psql \ commands?
--
greg
--
Sent
On Thu, May 19, 2011 at 11:09, Dave Page wrote:
> On Thu, May 19, 2011 at 2:44 PM, Selena Deckelmann wrote:
>> On Wed, May 18, 2011 at 8:20 PM, Alvaro Herrera
>> wrote:
>>> Excerpts from Greg Smith's message of mié may 18 23:07:13 -0400 2011:
Two things that could be changed from this examp
On Thu, May 19, 2011 at 12:57 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of jue may 19 10:18:20 -0400 2011:
>> On Wed, May 18, 2011 at 7:11 PM, Alvaro Herrera
>> wrote:
>> >> 1. I suggested that this looks a lot like the controls of pg_hba.conf
>> >>
>> >> When our DBAs are
Excerpts from Stephen Frost's message of jue may 19 13:49:33 -0400 2011:
> * Alvaro Herrera (alvhe...@commandprompt.com) wrote:
> > Excerpts from Greg Stark's message of jue may 19 12:11:29 -0400 2011:
> > > Adding such a feature would be pretty trivial, attached is a patch.
> >
> > Interesting, b
* Greg Stark (st...@mit.edu) wrote:
> Adding such a feature would be pretty trivial, attached is a patch.
Quick code-only review: sortedAttrs is a horrible var name for what it
is. More like 'sortbyName' would make more sense, at least to me.
Also, no regression test..? :) The interface looks al
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue may 19 13:34:13 -0400 2011:
>> I can't see getting rid of that lock, since we'd simply have to invent
>> some other interlock for new connections vs. DROP DATABASE. However,
>> I do think that we might sometime need to convert it to
* Alvaro Herrera (alvhe...@commandprompt.com) wrote:
> Excerpts from Greg Stark's message of jue may 19 12:11:29 -0400 2011:
> > Adding such a feature would be pretty trivial, attached is a patch.
>
> Interesting, but not so trivial I think -- I mean if you're doing this I
> think you should add a
Excerpts from Tom Lane's message of jue may 19 13:34:13 -0400 2011:
> Alvaro Herrera writes:
> > Excerpts from Robert Haas's message of jue may 19 10:18:20 -0400 2011:
> >> Second, it relies on the fact that a new connection briefly grabs a
> >> lock on the database that is then released.
>
> > Y
Alvaro Herrera writes:
> I just noticed that logging_collector does not have its default value
> documented. I checked and other settings were also missing defaults.
> Do we have a policy that they should all be documented, or is this
> intentional?
I think if the default value isn't pretty obvi
I just noticed that logging_collector does not have its default value
documented. I checked and other settings were also missing defaults.
Do we have a policy that they should all be documented, or is this
intentional?
--
Álvaro Herrera
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of jue may 19 10:18:20 -0400 2011:
>> Second, it relies on the fact that a new connection briefly grabs a
>> lock on the database that is then released.
> Yes. This is well known and it's not going away.
>> If we happened (for whateve
Excerpts from Robert Haas's message of jue may 19 10:18:20 -0400 2011:
> On Wed, May 18, 2011 at 7:11 PM, Alvaro Herrera
> wrote:
> >> 1. I suggested that this looks a lot like the controls of pg_hba.conf
> >>
> >> When our DBAs are doing major management of replication, they are
> >> known to re
Excerpts from Greg Stark's message of jue may 19 12:11:29 -0400 2011:
> A user at Pgcon made a pretty convincing case that it would sometimes
> be handy to be able to see a list of columns in alphabetical order in
> psql's \dt output. This is especially true when there are a very large
> number of
Robert Haas writes:
> On Thu, May 19, 2011 at 12:12 PM, Tom Lane wrote:
>> We could do that, but the issue that this code is trying to avoid is
>> that identify_system_timezone can easily add several seconds to the
>> postmaster startup time. So one of the reasons why someone would be
>> putting
On Thu, May 19, 2011 10:32 am, Robert Haas wrote:
> 2011/5/16 MauMau :
>> Can't open perl script "make-errcodes-table.pl": No such file or
>> directory
>
> I think this is the root of the problem. We have no script called
> make-errcodes-table.pl. Can you try changing it to
> generate-errcodes-ta
On Thu, May 19, 2011 at 12:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> So I think you whacked this around some more to get a *somewhat* more
>> sensible behavior, but ISTM that the behavior here still not really
>> right. Should we select a timezone at startup time even if we don't
>> immedi
On Sun, May 8, 2011 at 8:31 PM, Dan Ports wrote:
> On Fri, May 06, 2011 at 10:49:22PM -0400, Dan Ports wrote:
>> Will update the patch.
>
> Updated patch (in response to Robert's comments) attached.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Co
A user at Pgcon made a pretty convincing case that it would sometimes
be handy to be able to see a list of columns in alphabetical order in
psql's \dt output. This is especially true when there are a very large
number of columns and you're looking for a specific column with name
matching some patte
Robert Haas writes:
> So I think you whacked this around some more to get a *somewhat* more
> sensible behavior, but ISTM that the behavior here still not really
> right. Should we select a timezone at startup time even if we don't
> immediately need it, so that this can work correctly if we reve
On Thu, Apr 7, 2011 at 1:36 AM, Tom Lane wrote:
> Robert Haas writes:
>> If you have the timezone configured to a non-default value in
>> postgresql.conf, and you comment it out and reload, it says:
>
>> LOG: parameter "TimeZone" removed from configuration file, reset to default
>
>> ...but at l
On Tue, May 10, 2011 at 6:21 AM, Mark wrote:
> Could somebody explain me on which methods is based ts_rank and how it works?
> I would appreciate some articles, if exist.
> Thanks a lot for reply.
As far as I can tell, our documentation contains no useful information
on this topic whatsoever. :-
On Wed, May 18, 2011 at 9:11 AM, Leonardo Francalanci wrote:
> this is a second version: now using
>
> int counts[1]; /* variable-length array of counts */
>
> in xl_xact_commit to keep track of number of
>
> different arrays at the end of the struct.
>
> Waiting for feedbacks...
On Thu, May 19, 2011 at 11:13 AM, Noah Misch wrote:
> It would solve the problem, but it would mean resetting unlogged relations on
> the standby at every shutdown checkpoint. That's probably not a performance
> problem, but it is a hack.
I haven't thought about this too deeply, but I'm not sure
On Thu, May 19, 2011 at 01:52:46PM +0100, Leonardo Francalanci wrote:
> > I'd guess some WAL record arising from the post-crash master restart makes
> the
> > standby do so. When a crash isn't involved, the commit or abort record is
> >that
> > signal. You could test and find out how it happ
On Thu, May 19, 2011 at 2:44 PM, Selena Deckelmann wrote:
> On Wed, May 18, 2011 at 8:20 PM, Alvaro Herrera
> wrote:
>> Excerpts from Greg Smith's message of mié may 18 23:07:13 -0400 2011:
>>> Two things that could be changed from this example to make it more useful:
>>
>>> -The default database
On Wed, May 18, 2011 at 8:20 PM, Alvaro Herrera
wrote:
> Excerpts from Greg Smith's message of mié may 18 23:07:13 -0400 2011:
>> Two things that could be changed from this example to make it more useful:
>
>> -The default database is based on your user name, which is postgres in
>> most packaged
On Tue, May 17, 2011 at 2:44 PM, Dean Rasheed wrote:
> The algorithm for this was discussed in the original thread
> (http://archives.postgresql.org/pgsql-hackers/2010-10/msg02050.php)
> but I don't that think a satisfactory conclusion was really reached.
> In particular, it is way too easy to com
2011/5/16 MauMau :
> Can't open perl script "make-errcodes-table.pl": No such file or directory
I think this is the root of the problem. We have no script called
make-errcodes-table.pl. Can you try changing it to
generate-errcodes-table.pl and see if that works?
--
Robert Haas
EnterpriseDB: ht
On Tue, May 17, 2011 at 10:27 PM, Josh Kupershmidt wrote:
> Hi all,
>
> Attached is a simple patch addressing the TODO item "Allow \dd to show
> constraint comments". If you have comments on various constraints
> (column, foreign key, primary key, unique, exclusion), they should
> show up via \dd
On Tue, May 17, 2011 at 3:11 PM, Jaime Casanova wrote:
> On Tue, May 17, 2011 at 12:19 PM, Robert Haas wrote:
>>
>> The more controversial question is what to do if someone tries to
>> create such a cast anyway. We could just ignore that as we do now, or
>> we could throw a NOTICE, WARNING, or E
On Wed, May 18, 2011 at 7:11 PM, Alvaro Herrera
wrote:
>> 1. I suggested that this looks a lot like the controls of pg_hba.conf
>>
>> When our DBAs are doing major management of replication, they are
>> known to reconfigure pg_hba.conf to lock out all users save for the
>> one used by Slony.
>
>
> I'd guess some WAL record arising from the post-crash master restart makes
the
> standby do so. When a crash isn't involved, the commit or abort record is
>that
> signal. You could test and find out how it happens after a master crash
> with
>a
> procedure like this:
>
> 1. Start a mas
On Thu, May 19, 2011 at 8:19 AM, Cédric Villemain
wrote:
> 2011/5/19 Robert Haas :
>> On Tue, May 17, 2011 at 6:11 PM, Cédric Villemain
>> wrote:
>>> The point is to get ratio in cache, not the distribution of the data
>>> in cache (pgfincore also allows you to see this information).
>>> I don't
2011/5/19 Robert Haas :
> On Tue, May 17, 2011 at 6:11 PM, Cédric Villemain
> wrote:
>> The point is to get ratio in cache, not the distribution of the data
>> in cache (pgfincore also allows you to see this information).
>> I don't see how a stable (a server in production) system can have its
>>
On Tue, May 17, 2011 at 6:11 PM, Cédric Villemain
wrote:
> The point is to get ratio in cache, not the distribution of the data
> in cache (pgfincore also allows you to see this information).
> I don't see how a stable (a server in production) system can have its
> ratio moving up and down so fast
On Wed, May 18, 2011 at 3:37 PM, Magnus Hagander wrote:
> On Wed, May 18, 2011 at 15:29, Marko Kreen wrote:
>> On Wed, May 18, 2011 at 2:57 PM, Magnus Hagander wrote:
>>> On Wed, May 18, 2011 at 10:25, Greg Smith wrote:
Some of my personal discussions of this topic have suggested that some
On Thu, May 19, 2011 at 09:23:53AM +0100, Leonardo Francalanci wrote:
> > On Wed, May 18, 2011 at 04:02:59PM +0100, Leonardo Francalanci wrote:
> > > > By the time the startup process
> > > > releases the AccessExclusiveLock acquired by the proposed
> > > > UNLOGGED -> normal conversion proces
> On Wed, May 18, 2011 at 04:02:59PM +0100, Leonardo Francalanci wrote:
> > > By the time the startup process
> > > releases the AccessExclusiveLock acquired by the proposed
> > > UNLOGGED -> normal conversion process, that relfilenode
> > > needs to be either fully copied or unlinked all ov
53 matches
Mail list logo
