>>
>> with the patch:
>> vacuumdb -areal6m41.306s
>> idle steady state: 7.86% user, 5.00% system 0.09% iowait 87% idle,
>
> Nice. Another interesting numbers would be device utilization, average
> I/O speed and required space (which should be ~2x the pgstat.stat size
> without the patch)
Dimitri Fontaine escribió:
> And already a v1.
>
> Álvaro did spot a line I did remove by mistake in the docs, and some
> extra whitespace changes that pgindent will change anyway and that as
> such I shouldn't force you to read and discard.
The bigger change I mentioned was the stuff in dependen
Tom Lane wrote:
> Simon Riggs writes:
> > On 23 January 2013 17:15, Andres Freund wrote:
> >> On 2013-01-23 11:58:28 -0500, Andrew Dunstan wrote:
> >>> Can't we do better than that?
>
> > "row level locks cannot be applied to the NULLable side of an outer join"
>
> I think it should read "row-l
Robert Haas escribió:
> On Mon, Feb 4, 2013 at 11:59 AM, Dimitri Fontaine
> wrote:
> > Thanks. Agreed that we will have more of them. In the attached version 3
> > of the patch, it got renamed to pg_event_trigger_dropped_objects().
>
> Works for me.
>
> >> With this approach, there's no real nee
Alvaro Herrera writes:
> Patch attached.
Seems like a couple of the comments could use updates:
>* Note: RM_MAX_ID could be as much as 255 without breaking the XLOG file
>* format, but we keep it small to minimize the size of RmgrTable[].
This is no longer particularly sensible, since w
Tomas Vondra writes:
> I've managed to further simplify the test-case, and I've verified that
> it's reproducible on current 9.2 and 9.3 branches.
I'm not sure why you're getting unstable behavior --- it's pretty stable
for me, at least in a debug build. What I'm finding is that gistsplit.c
appe
On 5.2.2013 19:23, Jeff Janes wrote:
> On Sun, Feb 3, 2013 at 4:51 PM, Tomas Vondra wrote:
>
>> LOG: last_statwrite 11133-08-28 19:22:31.711744+02 is later than
>> collector's time 2013-02-04 00:54:21.113439+01 for db 19093
>> WARNING: pgstat wait timeout
>> LOG: last_statwrite 39681-12-23 18:
And already a v1.
Álvaro did spot a line I did remove by mistake in the docs, and some
extra whitespace changes that pgindent will change anyway and that as
such I shouldn't force you to read and discard.
It's a 3 lines change set from before.
Dimitri Fontaine writes:
> Robert Haas writes:
>>
Robert Haas writes:
> Well, having spent a year or more trying to convince you that we need
> sql_drop - mostly because of the complexities of passing an array of
> arguments to the trigger function - I now think we don't, because the
> pg_event_trigger_dropped_objects() bit solves that problem ra
Tom Lane wrote:
> Alvaro Herrera writes:
> > The
> > approach in the second patch is to turn these into "extern const RmgrId"
> > instead, and use a second inclusion of rmgrlist.h in rmgr.c that assigns
> > them the values as consts.
>
> ... but I don't especially like that implementation, as it
hi,
As reported in BUG #7715 [1], hstore's use of ? as an operator conflicts
with JDBC's bind variables.
I think we could just alias ? to ~ and tell JDBC users to use that
instead. [2]
Best,
Seamus
[1]
http://www.postgresql.org/message-id/e1teiju-0003qb...@wrigleys.postgresql.org
[2] htt
hi,
> Hi,
>
> On Mon, Jan 28, 2013 at 03:27:28PM +, YAMAMOTO Takashi wrote:
>>
>> can you give me a pointer?
>
> This bug report for a start:
> http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=46833
thanks!
YAMAMOTO Takashi
>
> This is the only one I've filled; I also remember
Alvaro Herrera writes:
> Tom Lane wrote:
>> Couldn't we do something similar to the design for SQL keyword constants,
>> wherein the actual data is in macros in a header file (providing exactly
>> one source of truth for each RM) and then various .c files can #include
>> that after #defining the m
On Sun, Feb 3, 2013 at 4:51 PM, Tomas Vondra wrote:
> LOG: last_statwrite 11133-08-28 19:22:31.711744+02 is later than
> collector's time 2013-02-04 00:54:21.113439+01 for db 19093
> WARNING: pgstat wait timeout
> LOG: last_statwrite 39681-12-23 18:48:48.9093+01 is later than
> collector's tim
On Tue, Feb 05, 2013 at 11:34:26AM -0500, Andrew Dunstan wrote:
> OK, I have looked at this and it seems perfectly sane. In fact, after a
> very frustrating time VS2012 is the *only* way I have found to get a 64
> bit build using MS tools on Windows 8. Given that, I propose to backport
> thes
For many aggregate functions it is necessary to store the actual column values
in the aggregate state and then do whatever calculation across them in the
final function. In many examples this is done by using array_append as the
sfunc and then a custom plpgsql function as the final function ope
On Tue, Feb 5, 2013 at 9:08 AM, Phil Sorber wrote:
> On Tue, Feb 5, 2013 at 9:06 AM, Alvaro Herrera
> wrote:
>> Phil Sorber escribió:
>>> On Tue, Feb 5, 2013 at 6:41 AM, Robert Haas wrote:
>>> > On Sat, Feb 2, 2013 at 9:55 PM, Phil Sorber wrote:
>>> >> OK, here is the patch that handles the co
On Feb 5, 2013 5:34 PM, "Andrew Dunstan" wrote:
>
>
> On 02/01/2013 08:55 AM, Andrew Dunstan wrote:
>>
>>
>> On 02/01/2013 06:12 AM, Craig Ringer wrote:
>>>
>>> On 01/26/2013 10:56 PM, Noah Misch wrote:
On Sat, Jan 26, 2013 at 12:20:56PM +0800, Craig Ringer wrote:
>
> Just to con
Tom Lane wrote:
> Couldn't we do something similar to the design for SQL keyword constants,
> wherein the actual data is in macros in a header file (providing exactly
> one source of truth for each RM) and then various .c files can #include
> that after #defining the macro as they need?
Here are
On 02/01/2013 08:55 AM, Andrew Dunstan wrote:
On 02/01/2013 06:12 AM, Craig Ringer wrote:
On 01/26/2013 10:56 PM, Noah Misch wrote:
On Sat, Jan 26, 2013 at 12:20:56PM +0800, Craig Ringer wrote:
Just to confirm, I think that this is ready for commit as posted in
20130101025421.ga17...@tornado
Sean Chittenden writes:
> I agree it's not ideal for some filesystems, but being overly protective
> doesn't buy us much either, because in some setups, it's entirely acceptable.
No, it isn't. As several people have told you already, the idea of
letting a mount point be used directly as a data
Sean Chittenden wrote:
> In thinking about it, I like ignoring the hidden directories and failing when
> lost+found is present
> because, IMO, filesystems where lost+found is going to be present are exactly
> the filesystems that
> shouldn't have PGDATA located at the top of a mount point.
Huh?
>> Currently src/port/pgcheckdir.c will reject non-empty
>> directories, which is an issue during initdb(1) when PGDATA is
>> also the mount point for filesystems that support snapshots (e.g.
>> ZFS or UFS2).
>
>> Granted it's not hard to create a subdirectory, initdb there and
>> move the content
On 5 February 2013 13:50, Craig Ringer wrote:
> On 02/05/2013 08:32 PM, Kevin Grittner wrote:
>
>> I would rather add a sentence or two to the
>> initdb documentation recommending that a cluster not be created at
>> a mount point; it should be created in a directory underneath the
>> mount point.
On Tue, Feb 5, 2013 at 9:06 AM, Alvaro Herrera wrote:
> Phil Sorber escribió:
>> On Tue, Feb 5, 2013 at 6:41 AM, Robert Haas wrote:
>> > On Sat, Feb 2, 2013 at 9:55 PM, Phil Sorber wrote:
>> >> OK, here is the patch that handles the connection string in dbname.
>> >> I'll post the other patch un
Phil Sorber escribió:
> On Tue, Feb 5, 2013 at 6:41 AM, Robert Haas wrote:
> > On Sat, Feb 2, 2013 at 9:55 PM, Phil Sorber wrote:
> >> OK, here is the patch that handles the connection string in dbname.
> >> I'll post the other patch under a different posting because I am sure
> >> it will get pl
On Tue, Feb 5, 2013 at 6:41 AM, Robert Haas wrote:
> On Sat, Feb 2, 2013 at 9:55 PM, Phil Sorber wrote:
>> OK, here is the patch that handles the connection string in dbname.
>> I'll post the other patch under a different posting because I am sure
>> it will get plenty of debate on it's own.
>
>
On 02/05/2013 08:32 PM, Kevin Grittner wrote:
> I would rather add a sentence or two to the
> initdb documentation recommending that a cluster not be created at
> a mount point; it should be created in a directory underneath the
> mount point.
That makes a great deal of sense, actually. There's no
On 2/5/13 7:32 AM, Kevin Grittner wrote:
> Sean Chittenden wrote:
>
>> > Currently src/port/pgcheckdir.c will reject non-empty
>> > directories, which is an issue during initdb(1) when PGDATA is
>> > also the mount point for filesystems that support snapshots (e.g.
>> > ZFS or UFS2).
>> > Granted
On 02/05/2013 07:32 AM, Kevin Grittner wrote:
Sean Chittenden wrote:
Currently src/port/pgcheckdir.c will reject non-empty
directories, which is an issue during initdb(1) when PGDATA is
also the mount point for filesystems that support snapshots (e.g.
ZFS or UFS2).
Granted it's not hard to cr
>> Hello. This was bounced my way via IRC[1] and I'm kicking an updated version
>> of the patch upstream for review and committing.
>>
>> Instead, it seems more correct to simply ignore all directories that begin
>> with a dot character. I'm not aware of any special directories exposed by
>> fi
Sean Chittenden wrote:
> Currently src/port/pgcheckdir.c will reject non-empty
> directories, which is an issue during initdb(1) when PGDATA is
> also the mount point for filesystems that support snapshots (e.g.
> ZFS or UFS2).
> Granted it's not hard to create a subdirectory, initdb there and
>
On Mon, Feb 4, 2013 at 11:59 AM, Dimitri Fontaine
wrote:
> Thanks. Agreed that we will have more of them. In the attached version 3
> of the patch, it got renamed to pg_event_trigger_dropped_objects().
Works for me.
>> With this approach, there's no real need to introduce a new event
>> type. W
On Sat, Feb 2, 2013 at 9:55 PM, Phil Sorber wrote:
> OK, here is the patch that handles the connection string in dbname.
> I'll post the other patch under a different posting because I am sure
> it will get plenty of debate on it's own.
I'm sorry, can you remind me what this does for us vs. the e
I found a small bug in the implementation of LDAP connection
parameter lookup.
As documented in
http://www.postgresql.org/docs/current/static/libpq-ldap.html
processing should continue after a failed attempt
to connect to an LDAP server.
The code in src/interfaces/libpq/fe-connect.c defines a
tim
On Fri, Feb 1, 2013 at 2:22 AM, Daniel Farina wrote:
> On Tue, Jan 29, 2013 at 1:19 AM, Kohei KaiGai wrote:
>> I noticed the v10 patch cannot be applied on the latest master branch
>> cleanly. The attached ones were rebased.
>
> Anyway, I'm looking at the first patch, which applies neatly. Thanks
2013/2/5 Andrew Dunstan :
>
> On 02/05/2013 02:09 AM, Pavel Stehule wrote:
>
>
>>
>> I don't see any nice on design select
>> myjson->>'{"authors",0,"name"}'::text[]; - more it is ugly as
>> dinosaurs
>
>
> I rather like dinosaurs. Beauty is, as they say, in the eye of the beholder.
>
> Let me al
On 02/05/2013 04:36 PM, Sean Chittenden wrote:
> Hello. This was bounced my way via IRC[1] and I'm kicking an updated version
> of the patch upstream for review and committing.
>
> Instead, it seems more correct to simply ignore all directories that begin
> with a dot character. I'm not aware of
Hello. This was bounced my way via IRC[1] and I'm kicking an updated version of
the patch upstream for review and committing.
Currently src/port/pgcheckdir.c will reject non-empty directories, which is an
issue during initdb(1) when PGDATA is also the mount point for filesystems that
support sn
On 02/05/2013 02:09 AM, Pavel Stehule wrote:
I don't see any nice on design select
myjson->>'{"authors",0,"name"}'::text[]; - more it is ugly as
dinosaurs
I rather like dinosaurs. Beauty is, as they say, in the eye of the beholder.
Let me also point out that you can say (somewhat less ef
On Tue, Feb 5, 2013 at 01:41:05PM +0530, Pavan Deolasee wrote:
> On Fri, Feb 1, 2013 at 10:53 PM, Bruce Momjian wrote:
> >
> >
> > Are these TODO items?
> >
>
> BTW, there are couple of TODOs.
>
> 1. Analyze should be done based on the total row churn across the
> parent + children. Looking a
On Fri, Feb 1, 2013 at 10:53 PM, Bruce Momjian wrote:
>
>
> Are these TODO items?
>
BTW, there are couple of TODOs.
1. Analyze should be done based on the total row churn across the
parent + children. Looking at the parent only, as we do now, can
result in analyzing too often or too seldom.
2
On Mon, Feb 4, 2013 at 9:05 PM, Robert Haas wrote:
> On Fri, Feb 1, 2013 at 12:33 PM, Pavan Deolasee
> wrote:
>> I can write a patch in next couple of days if we are willing to accept
>> for this release. I think it should be fairly easy and non-intrusive.
>
> I think it's too late to consider th
43 matches
Mail list logo
