* Heikki Linnakangas (hlinn...@iki.fi) wrote:
On 05/13/2015 06:07 AM, Stephen Frost wrote:
This does change the XLOG functions to require pg_monitor, as discussed
on the other thread where it was pointed out by Heikki that the XLOG
location information could be used to extract sensitive
(please keep the mailing list CC'd, and please don't top-post)
On 05/13/2015 05:00 AM, digoal zhou wrote:
I test it, but use exponent not very perfect in any environment.
why cann't use time only?
As you mentioned yourself earlier, if you only use time but you reach
checkpoint_segments
Hello, this might be somewhat out of place but strongly related
to this patch so I'll propose this here.
This is a proposal of new feature for this patch or asking for
your approval for my moving on this as a different (but very
close) project.
===
Attached is v6 of the multivariate stats,
On 13/05/15 12:56, Heikki Linnakangas wrote:
On 05/13/2015 07:10 AM, Alvaro Herrera wrote:
Heikki, do you have time to go through this at this point?
I'm afraid I won't :-(. I did intend to, but looking at the calendar, I
won't have the time to review this thoroughly enough to commit. Sorry.
On 05/13/2015 06:07 AM, Stephen Frost wrote:
This does change the XLOG functions to require pg_monitor, as discussed
on the other thread where it was pointed out by Heikki that the XLOG
location information could be used to extract sensitive information
based on what happens during compression.
On 05/13/2015 07:10 AM, Alvaro Herrera wrote:
Heikki, do you have time to go through this at this point?
I'm afraid I won't :-(. I did intend to, but looking at the calendar, I
won't have the time to review this thoroughly enough to commit. Sorry.
I haven't looked at the CREATE/DROP ACCESS
On 2015/05/13 6:22, Tom Lane wrote:
I wrote:
I did a very basic update of your postgres_fdw patch to test this with,
and attach that so that you don't have to repeat the effort. I'm not sure
whether we want to try to convert that into something committable. I'm
afraid that the extra round
On 13 May 2015 at 11:56, Heikki Linnakangas hlinn...@iki.fi wrote:
On 05/13/2015 07:10 AM, Alvaro Herrera wrote:
Heikki, do you have time to go through this at this point?
I'm afraid I won't :-(. I did intend to, but looking at the calendar, I
won't have the time to review this thoroughly
On Mon, May 11, 2015 at 12:00 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
And here is a new version of the patch. I kept the approach of using pgstat,
but it now only polls pgstat every 10 seconds, and doesn't block to wait for
updated stats.
It's not entirely a new problem, but this error
On Wed, May 13, 2015 at 8:53 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
Our manual says that archive_command should refuse to overwrite an existing
file. But to work-around the double-archival problem, where the same file is
archived twice, it would be even better if it would simply return
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Craig Ringer wrote:
For some time I've wanted a way to SET SESSION AUTHORISATION or SET
ROLE in a way that cannot simply be RESET, so that a connection may be
handed to a less-trusted service or application to do some work with.
Some
2015-05-13 21:45 GMT+09:00 Robert Haas robertmh...@gmail.com:
On Sun, May 10, 2015 at 3:15 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2015-05-01 9:52 GMT+09:00 Kohei KaiGai kai...@kaigai.gr.jp:
2015-05-01 7:40 GMT+09:00 Alvaro Herrera alvhe...@2ndquadrant.com:
Kouhei Kaigai wrote:
* Tom
On Mon, May 11, 2015 at 9:07 PM, David Steele da...@pgmasters.net wrote:
On 5/1/15 5:58 AM, Sawada Masahiko wrote:
For now, since pg_audit patch has a pg_audit_ddl_command_end()
function which uses part of un-committed deparsing utility commands
patch API,
pg_audit patch is completely depend
On 13/05/15 14:15, Heikki Linnakangas wrote:
I don't see what calamity will occur if we commit this. If you don't
want a
sequence AM, don't ever use this.
I'd like the API to be good for its purpose. Also, I did mention that
the the current patch makes the situation slightly worse for people
On Mon, May 11, 2015 at 10:00 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 7, 2015 at 4:57 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, May 7, 2015 at 11:02 AM, Stephen Frost sfr...@snowman.net
wrote:
I realize it's not
On 05/13/2015 02:12 PM, Simon Riggs wrote:
This has had around 2 years of thought at this point. I don't agree it
needs more thought.
Noted.
There is one clear use case for this and it is of benefit to many
distributed architectures.
Right. What's your point?
I don't see what calamity
On 05/13/2015 03:36 PM, Robert Haas wrote:
On Mon, May 11, 2015 at 12:00 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
And here is a new version of the patch. I kept the approach of using pgstat,
but it now only polls pgstat every 10 seconds, and doesn't block to wait for
updated stats.
It's
On Tue, May 12, 2015 at 7:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
MinMaxExpr is an implicit invocation of a btree comparison function.
Are we supposing that all of those are necessarily leakproof?
I suspect it's an oversight, because the comment gives no hint that
any such intention was
On Wed, May 13, 2015 at 8:01 AM, Volker Aßmann volker.assm...@gmail.com wrote:
Even in this case it still means that any breach in any of the network
services running on your application server would immediately own your
database, or at least everything your application can access. This applies
All,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
On 05/13/2015 06:07 AM, Stephen Frost wrote:
This does change the XLOG functions to require pg_monitor, as discussed
on the other thread where it was pointed out by Heikki that the XLOG
location information could be used to extract sensitive
On Sun, May 10, 2015 at 3:15 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2015-05-01 9:52 GMT+09:00 Kohei KaiGai kai...@kaigai.gr.jp:
2015-05-01 7:40 GMT+09:00 Alvaro Herrera alvhe...@2ndquadrant.com:
Kouhei Kaigai wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
The idea of making the
On Tue, May 12, 2015 at 1:57 PM, David G. Johnston
david.g.johns...@gmail.com wrote:
In a literal that has been determined to be timestamp without time zone,
PostgreSQL will silently ignore any time zone indication. That is, the
resulting value is derived from the date/time fields in the input
On Sat, May 9, 2015 at 8:48 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, May 8, 2015 at 10:27 PM, Simon Riggs wrote:
On 8 May 2015 at 13:02, Michael Paquier wrote:
I think that we should redefine subxcnt as uint32 for consistency with
xcnt, and remove the two assertions that
On Wed, May 13, 2015 at 10:16:39AM -0400, Robert Haas wrote:
On Tue, May 12, 2015 at 11:07 PM, Stephen Frost sfr...@snowman.net wrote:
Thoughts? Comments? Suggestions?
Yes: let's punt this to 9.6. The decisions you're making here are way
too significant to be making a couple of days
On Wed, May 13, 2015 at 11:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
- Code review for foreign/custom join pushdown patch - Whacks around
my earlier commit without agreement or adequate discussion, apparently
on the theory that Tom always knows best.
As far as that goes, obviously I've got
On Thu, May 7, 2015 at 2:18 PM, Fabien COELHO coe...@cri.ensmp.fr wrote:
Since an expression syntax has been added to pgbench, I find that the
readability of expressions is not great. An extra '=' improves the situation
for me:
\set id = 1 + abs((:id * 1021) % (10 * :scale))
seems
Robert Haas robertmh...@gmail.com writes:
It's pretty clear that the impending feature freeze proposed by core
has spurred a lot of activity. This is both good and bad. On the
good side, we're getting a bunch of stuff done. On the bad side,
there is inevitably going to be a temptation to
On Tue, May 12, 2015 at 11:07 PM, Stephen Frost sfr...@snowman.net wrote:
Thoughts? Comments? Suggestions?
Yes: let's punt this to 9.6. The decisions you're making here are way
too significant to be making a couple of days before feature freeze,
and this patch has changed massively since it
Hi,
It's pretty clear that the impending feature freeze proposed by core
has spurred a lot of activity. This is both good and bad. On the
good side, we're getting a bunch of stuff done. On the bad side,
there is inevitably going to be a temptation to rush things in that
are really not quite
On Fri, Jan 23, 2015 at 4:13 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
[pruning the Cc: list and starting a new thread]
Here's the cleaned-up version of the patch to allow abbreviated keys
when sorting a single Datum. This also removes comments that suggest
that the caller of
On Wed, May 13, 2015 at 11:40 AM, Robert Haas robertmh...@gmail.com wrote:
Committed. Thanks for the patch and your patience.
This comment was not updated:
/*
* The sortKeys variable is used by every case other than the datum and
* hash index cases; it is set by tuplesort_begin_xxx. tupDesc
On Wed, May 13, 2015 at 10:16 PM, Heikki Linnakangas hlinn...@iki.fi
wrote:
On 04/17/2015 12:05 PM, Alexander Korotkov wrote:
On Wed, Feb 25, 2015 at 12:15 PM, Alexander Korotkov
aekorot...@gmail.com
wrote:
Hi!
On Tue, Feb 24, 2015 at 5:39 PM, Tomas Vondra
Robert Haas wrote:
On Wed, May 13, 2015 at 2:10 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Uh, are we really using INFO to log this? I thought that was a
discouraged level to use anymore. Why not NOTICE?
Well, as Masahiko-san points out, VACUUM uses INFO. I can't see any
good
[redirecting to -hackers]
On 05/12/2015 01:30 PM, Amit Kapila wrote:
On Tue, May 12, 2015 at 9:02 PM, Andrew Dunstan and...@dunslane.net
mailto:and...@dunslane.net wrote:
On 05/12/2015 10:33 AM, Heikki Linnakangas wrote:
On 05/12/2015 04:42 PM, Andrew Dunstan wrote:
On Wed, May 13, 2015 at 2:44 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, May 13, 2015 at 11:40 AM, Robert Haas robertmh...@gmail.com wrote:
Committed. Thanks for the patch and your patience.
This comment was not updated:
/*
* The sortKeys variable is used by every case other than
On Wed, May 13, 2015 at 2:10 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Uh, are we really using INFO to log this? I thought that was a
discouraged level to use anymore. Why not NOTICE?
Well, as Masahiko-san points out, VACUUM uses INFO. I can't see any
good reason to make this
On Thu, Apr 30, 2015 at 6:20 PM, Tomas Vondra tomas.von...@2ndquadrant.com
wrote:
Hi,
On 04/30/15 22:57, Robert Haas wrote:
On Tue, Mar 31, 2015 at 3:02 PM, Tomas Vondra
tomas.von...@2ndquadrant.com wrote:
attached is v4 of the patch implementing adaptive ndistinct estimator.
So, I
hi
i don't want to make this post long. i just started to use PostgreSQL and
it is absolutely awesome . just want to say thank you very much
On 2015-05-12 05:36:19 +0200, Andres Freund wrote:
Another controversial item was the introduction of GroupedVar. The need
for this can be avoided by explicitly setting to NULL the relevant
columns of the representative group tuple when evaluating result rows,
but (a) I don't think that's
On Thu, May 14, 2015 at 3:10 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Uh, are we really using INFO to log this? I thought that was a
discouraged level to use anymore. Why not NOTICE?
I think it should be INFO level because it is a information of REINDEX
command,such as progress of
On 04/17/2015 12:05 PM, Alexander Korotkov wrote:
On Wed, Feb 25, 2015 at 12:15 PM, Alexander Korotkov aekorot...@gmail.com
wrote:
Hi!
On Tue, Feb 24, 2015 at 5:39 PM, Tomas Vondra
tomas.von...@2ndquadrant.com wrote:
On 17.2.2015 14:21, Alexander Korotkov wrote:
On Sun, Feb 15, 2015 at
Hi,
I am using Debian Jessie and install pgAdmin4 Required modules.
after I clone pgAdmin4 from
http://git.postgresql.org/gitweb/?p=pgadmin4.git;a=summary ,
First of, ıf I want run setup.py, I must fix bug .
after I want run pgadmin4.py, I must fix gravatar import line.
In this case,
There are
On 14/05/15 09:35, essam Gndelee essam wrote:
hi
i don't want to make this post long. i just started to use PostgreSQL
and it is absolutely awesome . just want to say thank you very much
You're allowed to say more!!! :-)
What particular features do you like best, and why?
What O/S,
On 13 May 2015 at 17:55, Tom Lane t...@sss.pgh.pa.us wrote:
Aaron W. Swenson titanof...@gentoo.org writes:
Trying to build HEAD and ran into this issue building the docs:
openjade:logicaldecoding.sgml:575:62:Q: length of name token must
not exceed NAMELEN (44)
Aaron W. Swenson titanof...@gentoo.org writes:
Trying to build HEAD and ran into this issue building the docs:
openjade:logicaldecoding.sgml:575:62:Q: length of name token must
not exceed NAMELEN (44)
openjade:replication-origins.sgml:87:67:Q: length of name token must
not
On Wed, May 13, 2015 at 3:54 PM, Fabien COELHO coe...@cri.ensmp.fr wrote:
Ok. I've marked this one as REJECTED.
Otherwise, I was considering this kind of things:
n := expr
n, m, p, q := SELECT ...
Also, having ; as a end of commands could also help by allowing multiline
commands, but
Emre Hasegeli wrote:
I pushed patches 04 and 07, as well as adopting some of the changes to
the regression test in 06. I'm afraid I caused a bit of merge pain for
you -- sorry about that.
No problem. I rebased the remaining ones.
Thanks!
After some back-and-forth between Emre and me,
Oh well... then, THANKS GUYS!!!
I'm not the original poster, btw.
I felt a bit 'abandoned' a while back, since I started using
Interbase/Firebird since, like, ~2000. But since Firebird never really took
off, I felt I had to look for better solutions. I worked with Oracle for a
bit, and then
I think you want PGAdmin support:
http://www.pgadmin.org/support/list.php
Also, why isn't the non-subscribe email address listed on that webpage?
---
On Thu, May 14, 2015 at 12:11:15AM +0300, Seçkin Alan wrote:
On Thu, May 14, 2015 at 4:53 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 13, 2015 at 2:10 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Uh, are we really using INFO to log this? I thought that was a
discouraged level to use anymore. Why not NOTICE?
Well, as Masahiko-san
On Wed, May 13, 2015 at 2:49 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Thu, May 14, 2015 at 12:28 AM, Robert Haas robertmh...@gmail.com
wrote:
On Thu, May 7, 2015 at 6:55 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
Sorry, I forgot attach files.
Review comments:
-
Looking at what remains open in the current commitfest:
* fsync $PGDATA recursively at startup
Andres is the reviewer of record on this one. He should either commit it
if he feels it's ready, or bounce it to next CF if not.
* EvalPlanQual behaves oddly for FDW queries involving system columns
On Wed, May 13, 2015 at 11:19:29AM -0400, Bruce Momjian wrote:
On Wed, May 13, 2015 at 10:32:03AM -0400, Robert Haas wrote:
We also need to start thinking about what happens after feature
freeze. The CommitFest application currently lists a 2015-06
CommitFest which, according to previous
Tom, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
* Optimization for updating foreign tables in Postgres FDW
I concur with Stephen's assessment that this doesn't look well designed.
I think we should just mark it RWF for now.
I had meant to do that already, sorry about that, done now.
*
On Thu, May 14, 2015 at 1:03 AM, Michael Paquier wrote:
On Thu, May 14, 2015 at 12:02 AM, Robert Haas wrote:
I'm just going to remove the useless assertion for now. What you're
proposing here may (or may not) be worth doing, but it carries a
non-zero risk of breaking something somewhere, if
On 05/13/2015 11:38 AM, Tom Lane wrote:
* Grouping Sets
I had originally promised to be committer for this one, and still want
to go look at it, but Robert's nearby message about not committing stuff
in haste definitely seems to apply.
That makes me sad. I wish you would still try.
Sadly,
I wrote:
* Cube extension kNN support
This is still marked as needs review, I'm afraid we have to push to 9.6.
* compress method for spgist
Sigh. There was a Ditto under this one, but somehow it disappeared
in editing :-(
regards, tom lane
--
Sent via
* Robert Haas (robertmh...@gmail.com) wrote:
Yes: let's punt this to 9.6. The decisions you're making here are way
too significant to be making a couple of days before feature freeze,
and this patch has changed massively since it was first submitted.
There isn't time now for people who want
Bruce Momjian br...@momjian.us writes:
Let me put a finer point on this --- whatever gets pushed to 9.6
unreasonably will be a feature we don't have in 9.5 and will discourage
future development. I know we can't do magic, but now is the time to
try.
The other side of that coin is that the
On 05/13/2015 08:09 AM, Tom Lane wrote:
What I think we need to be doing this week is triage. Commit what's
ready, punt what's not. I'll post a separate list about that.
regards, tom lane
+1
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/
On Wed, May 13, 2015 at 11:50 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Yes: let's punt this to 9.6. The decisions you're making here are way
too significant to be making a couple of days before feature freeze,
and this patch has changed
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, May 13, 2015 at 11:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
* Additional role attributes
Is this ready to commit? Stephen's call.
-1 for committing this, per discussion earlier today on a thread
that's probably not linked into the
On Wed, May 13, 2015 at 11:52:40AM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Let me put a finer point on this --- whatever gets pushed to 9.6
unreasonably will be a feature we don't have in 9.5 and will discourage
future development. I know we can't do magic, but now is
On Thu, May 14, 2015 at 12:02 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, May 9, 2015 at 8:48 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, May 8, 2015 at 10:27 PM, Simon Riggs wrote:
On 8 May 2015 at 13:02, Michael Paquier wrote:
I think that we should redefine
On 2015-05-13 11:49:45 -0400, Robert Haas wrote:
On Wed, May 13, 2015 at 11:40 AM, Bruce Momjian br...@momjian.us wrote:
Let me put a finer point on this --- whatever gets pushed to 9.6
unreasonably will be a feature we don't have in 9.5 and will discourage
future development. I know we
Andres Freund and...@anarazel.de writes:
On 2015-05-13 11:38:27 -0400, Tom Lane wrote:
* Manipulating complex types as non-contiguous structures in-memory
This one's mine of course. I've been hoping to get more independent
performance testing than it's gotten, but time grows short. I'm
Andres Freund and...@anarazel.de writes:
On 2015-05-13 11:52:40 -0400, Tom Lane wrote:
One thing that continues to bother me about the commitfest process is that
it's created a default expectation that things get committed eventually.
Agreed that this is a problem. I think we need to work on
On 05/13/2015 09:27 AM, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-05-13 11:52:40 -0400, Tom Lane wrote:
One thing that continues to bother me about the commitfest process is that
it's created a default expectation that things get committed eventually.
Agreed that
On Thu, May 7, 2015 at 6:55 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
Sorry, I forgot attach files.
Review comments:
- Customarily we use int, rather than uint8, for flags variables. I
think we should do that here also.
- reindex_index() emits a log message either way, but at DEBUG2
* Bruce Momjian (br...@momjian.us) wrote:
On Wed, May 13, 2015 at 11:19:29AM -0400, Bruce Momjian wrote:
On Wed, May 13, 2015 at 10:32:03AM -0400, Robert Haas wrote:
We also need to start thinking about what happens after feature
freeze. The CommitFest application currently lists a
On Wed, May 13, 2015 at 11:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
* fsync $PGDATA recursively at startup
Andres is the reviewer of record on this one. He should either commit it
if he feels it's ready, or bounce it to next CF if not.
I committed the first part of this as
On 2015-05-13 11:52:40 -0400, Tom Lane wrote:
One thing that continues to bother me about the commitfest process is that
it's created a default expectation that things get committed eventually.
But many new ideas are just plain bad, and others are things that nobody
but the author cares about.
Robert Haas robertmh...@gmail.com writes:
Now, if six people who are all well-known PostgreSQL contributors show
up and they all say I looked at the latest version of this carefully
and I'm confident you've got it right, then go ahead: push it. But
don't make the mistake of thinking that
On 13/05/15 17:38, Tom Lane wrote:
* Sequence Access Method
Heikki's marked as reviewer, so it's his call as to whether this is ready,
but the impression I have is that there's not really consensus as to
whether the API is good. If not, it's something I think we should push
to 9.6.
Heikki
On 2015-05-13 20:48:51 -0400, Tom Lane wrote:
I still think that going back to defining the second byte as the size
would be better. Fortunately, since this is only a matter of in-memory
representations, we aren't committed to any particular answer.
Requiring sizes to be different still
On Wed, May 13, 2015 at 8:25 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
The v15 patch emits a line for each table when reindexing multiple
tables, and emits a line for each index when reindexing single table.
But v14 patch emits a line for each index, regardless of reindex target.
Should
Andres Freund and...@anarazel.de writes:
On 2015-05-13 20:48:51 -0400, Tom Lane wrote:
I still think that going back to defining the second byte as the size
would be better. Fortunately, since this is only a matter of in-memory
representations, we aren't committed to any particular answer.
Andres Freund and...@anarazel.de writes:
On 2015-05-10 12:09:41 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
* The VARTAG_IS_EXPANDED(tag) trick in VARTAG_SIZE is unlikely to
beneficial, before the compiler could implement the whole thing as a
computed goto or lookup table,
Andres Freund and...@anarazel.de writes:
On 2015-05-13 21:01:43 -0400, Tom Lane wrote:
It is, but why would it be a disaster? We could add StaticAsserts
verifying that the sizes actually are different. I doubt that the pad
space itself could amount to any issue performance-wise, since it
Andres Freund and...@anarazel.de writes:
On 2015-05-10 12:09:41 -0400, Tom Lane wrote:
* I find the ARRAY_ITER_VARS/ARRAY_ITER_NEXT macros rather ugly. I don't
buy the argument that turning them into functions will be slower. I'd
bet the contrary on common platforms.
Perhaps; do you want to
* ctidscan as an example of custom-scan
This basically hasn't gotten any attention, which may mean nobody cares
enough to justify putting it in the tree. We need to either push it to
next CF or reject altogether.
Agreed. I was fine with never committing this. I don't think we have
Hi,
I've been pulling over Tom's occasional remarks about redoing
grouping_planner - and maybe further layers of the planner - to work
with Paths instead of Plans. I've had difficulty locating all of the
relevant threads. Here's everything I've found so far, which I'm
pretty sure is not
On Wed, May 13, 2015 at 10:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Both of those are problems all right, but there is more context here.
Thanks for providing the context.
I'm inclined to think that it would be useful to solve the first
problem even if we didn't solve the second one right
On 2015-05-13 20:28:52 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Similarly using inline funcs for AARR_NDIMS/HASNULL does not appear to
hamper performance and gets rid of the multiple evaluation risk.
I'm less excited about that part though. The original ARR_FOO
On 2015-05-13 21:01:43 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-05-13 20:48:51 -0400, Tom Lane wrote:
I still think that going back to defining the second byte as the size
would be better. Fortunately, since this is only a matter of in-memory
Robert Haas robertmh...@gmail.com writes:
I've been pulling over Tom's occasional remarks about redoing
grouping_planner - and maybe further layers of the planner - to work
with Paths instead of Plans. ...
I think there are two separate problems here. First, there's the
problem that
On 2015-05-13 22:51:15 +0200, Andres Freund wrote:
I'm pretty sure by now that I dislike the introduction of GroupedVar,
and not just tentatively. While I can see why you found its
introduction to be nicer than fiddling with the result tuple, for me the
disadvantages seem to outweigh the
On Wed, May 13, 2015 at 12:17 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, May 14, 2015 at 1:03 AM, Michael Paquier wrote:
On Thu, May 14, 2015 at 12:02 AM, Robert Haas wrote:
I'm just going to remove the useless assertion for now. What you're
proposing here may (or may not)
Andres Freund and...@anarazel.de writes:
On 2015-05-13 11:38:27 -0400, Tom Lane wrote:
* parallel mode/contexts
Robert's patch, his to deal with (likewise for assessing parallel-safety).
Just as a note, a large part of this has been committed.
Right, and Robert commented that he isn't
On 2015-05-13 11:38:27 -0400, Tom Lane wrote:
* parallel mode/contexts
Robert's patch, his to deal with (likewise for assessing parallel-safety).
Just as a note, a large part of this has been committed.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Wed, May 13, 2015 at 1:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
On 2015-05-13 11:38:27 -0400, Tom Lane wrote:
* parallel mode/contexts
Robert's patch, his to deal with (likewise for assessing parallel-safety).
Just as a note, a large part of this
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
On 2015/05/13 6:22, Tom Lane wrote:
Of course, if we don't do that then we still have your original gripe
about ctid not being correct in EvalPlanQual results. I poked at this
a bit and it seems like we could arrange to pass ctid through even
On 05/13/2015 04:29 PM, Robert Haas wrote:
On Wed, May 13, 2015 at 8:53 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
Our manual says that archive_command should refuse to overwrite an existing
file. But to work-around the double-archival problem, where the same file is
archived twice, it would
On Wed, May 13, 2015 at 10:32:03AM -0400, Robert Haas wrote:
We also need to start thinking about what happens after feature
freeze. The CommitFest application currently lists a 2015-06
CommitFest which, according to previous practice, would be expected to
start on the 15th of the month.
On Wed, May 13, 2015 at 11:40 AM, Bruce Momjian br...@momjian.us wrote:
We have three days left so I think we need committers to devote serious
time, if possible, to helping us resolve as much as we can. If we start
thinking about this on Friday, it is too late.
Let me put a finer point on
On 2015-05-13 11:38:27 -0400, Tom Lane wrote:
Looking at what remains open in the current commitfest:
* fsync $PGDATA recursively at startup
Andres is the reviewer of record on this one. He should either commit it
if he feels it's ready, or bounce it to next CF if not.
The more important
On Thu, May 14, 2015 at 12:28 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 7, 2015 at 6:55 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
Sorry, I forgot attach files.
Review comments:
- Customarily we use int, rather than uint8, for flags variables. I
think we should do that
Uh, are we really using INFO to log this? I thought that was a
discouraged level to use anymore. Why not NOTICE?
Also, when multiple tables are reindexed, do we emit lines for each
index, or only for each table? If we're going to emit a line for each
index in the single-table mode, it seems
On Wed, May 13, 2015 at 09:34:53AM -0400, Robert Haas wrote:
On Tue, May 12, 2015 at 7:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
MinMaxExpr is an implicit invocation of a btree comparison function.
Are we supposing that all of those are necessarily leakproof?
I suspect it's an oversight,
On Thu, May 14, 2015 at 2:10 AM, Andrew Dunstan and...@dunslane.net wrote:
How about if we simply abort if we find a non-symlink where we want the
symlink to be, and only remove something that is actually a symlink (or a
junction point, which is more or less the same thing)?
We can do that way
1 - 100 of 106 matches
Mail list logo
