On Mon, Feb 4, 2013 at 9:05 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Feb 1, 2013 at 12:33 PM, Pavan Deolasee
pavan.deola...@gmail.com 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.
On Fri, Feb 1, 2013 at 10:53 PM, Bruce Momjian br...@momjian.us 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
On Tue, Feb 5, 2013 at 01:41:05PM +0530, Pavan Deolasee wrote:
On Fri, Feb 1, 2013 at 10:53 PM, Bruce Momjian br...@momjian.us 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.
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
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
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 any
2013/2/5 Andrew Dunstan and...@dunslane.net:
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
On Fri, Feb 1, 2013 at 2:22 AM, Daniel Farina dan...@heroku.com wrote:
On Tue, Jan 29, 2013 at 1:19 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
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
On Sat, Feb 2, 2013 at 9:55 PM, Phil Sorber p...@omniti.com 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
On Mon, Feb 4, 2013 at 11:59 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr 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
Sean Chittenden s...@chittenden.org 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,
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
filesystems
On 02/05/2013 07:32 AM, Kevin Grittner wrote:
Sean Chittenden s...@chittenden.org 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 2/5/13 7:32 AM, Kevin Grittner wrote:
Sean Chittenden s...@chittenden.org 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).
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 Tue, Feb 5, 2013 at 6:41 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Feb 2, 2013 at 9:55 PM, Phil Sorber p...@omniti.com 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
Phil Sorber escribió:
On Tue, Feb 5, 2013 at 6:41 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Feb 2, 2013 at 9:55 PM, Phil Sorber p...@omniti.com 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
On Tue, Feb 5, 2013 at 9:06 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Phil Sorber escribió:
On Tue, Feb 5, 2013 at 6:41 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Feb 2, 2013 at 9:55 PM, Phil Sorber p...@omniti.com wrote:
OK, here is the patch that handles the connection
On 5 February 2013 13:50, Craig Ringer cr...@2ndquadrant.com 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
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 contents of the
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?
Sean Chittenden s...@chittenden.org 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
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
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 two
On Feb 5, 2013 5:34 PM, Andrew Dunstan and...@dunslane.net 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 confirm, I think
On Tue, Feb 5, 2013 at 9:08 AM, Phil Sorber p...@omniti.com wrote:
On Tue, Feb 5, 2013 at 9:06 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Phil Sorber escribió:
On Tue, Feb 5, 2013 at 6:41 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Feb 2, 2013 at 9:55 PM, Phil Sorber
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
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
these
On Sun, Feb 3, 2013 at 4:51 PM, Tomas Vondra t...@fuzzy.cz 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
Alvaro Herrera alvhe...@2ndquadrant.com 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
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 having irc
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]
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com 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
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 dimi...@2ndquadrant.fr writes:
On 5.2.2013 19:23, Jeff Janes wrote:
On Sun, Feb 3, 2013 at 4:51 PM, Tomas Vondra t...@fuzzy.cz 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
Tomas Vondra t...@fuzzy.cz 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
Alvaro Herrera alvhe...@2ndquadrant.com 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
Robert Haas escribió:
On Mon, Feb 4, 2013 at 11:59 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr 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
Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 23 January 2013 17:15, Andres Freund and...@2ndquadrant.com 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
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 dependency.c
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).
this
43 matches
Mail list logo
