On Mon, Dec 1, 2014 at 2:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
That was my fault -- the alvh.no-ip.org domain was deleted, and the
email system in postgresql.org rejected the commit message because the
sender was not in a deliverable domain.
Magnus Hagander wrote:
On Mon, Dec 1, 2014 at 2:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
That was my fault -- the alvh.no-ip.org domain was deleted, and the
email system in postgresql.org rejected the commit message because the
sender was
Initial message:
http://www.postgresql.org/message-id/5447b3ff.2080...@sigaev.ru
Second version fixes a forgotten changes in pg_am.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
Hi all
I've attached a revised patchset for GetSystemTimeAsFileTime and
GetSystemTimePreciseAsFileTime to address David Rowley's review notes.
Thanks for the review, and for poking me to follow up.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
Il 01/12/14 14:16, Craig Ringer ha scritto:
+#ifndef FRONTEND
+#include utils/elog.h
+#endif
+
I think this is a leftover, as you don't use elog afterwards.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it |
On Thu, Nov 27, 2014 at 11:43 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Nov 27, 2014 at 8:18 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Thu, Nov 27, 2014 at 1:07 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Nov 27, 2014 at 12:55 AM, Sawada Masahiko
On Mon, Dec 01, 2014 at 02:55:22PM +0800, Craig Ringer wrote:
Hi all
Currently the client must know the size of a large lob/clob field, like
a 'bytea' or 'text' field, in order to send it to the server. This can
force the client to buffer all the data before sending it to the server.
Yes,
On 12/01/2014 10:38 PM, David Fetter wrote:
On Mon, Dec 01, 2014 at 02:55:22PM +0800, Craig Ringer wrote:
Hi all
Currently the client must know the size of a large lob/clob field, like
a 'bytea' or 'text' field, in order to send it to the server. This can
force the client to buffer all the
Craig Ringer cr...@2ndquadrant.com writes:
Currently the client must know the size of a large lob/clob field, like
a 'bytea' or 'text' field, in order to send it to the server. This can
force the client to buffer all the data before sending it to the server.
It would be helpful if the v4
I wrote:
I spent a fair chunk of the weekend hacking on this patch to make
it more understandable and fix up a lot of what seemed to me pretty
clear arithmetic errors in the upper layers of the patch. However,
I couldn't quite convince myself to commit it, because the business
around
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
All of the MSVC critters are failing at make check.
Yeah, I noticed that, thanks. As far as I can see the only way to fix
it is to install dummy_seclabel to run the core seclabel test. That
doesn't seem
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Sounds good to me. The other parts of the core tests that depend on
contrib modules aren't exactly good models to follow.
Pushed; tests pass for me, let's see what buildfarm says.
Pushed? Don't see it ...
On Nov 28, 2014, at 8:43 AM, Peter Eisentraut pete...@gmx.net wrote:
At the moment, this is probably just an experiment that shows where
refactoring and better abstractions might be suitable if we want to
support multiple locale libraries. If we want to pursue ICU, I think
this could be a
Alex Shulgin a...@commandprompt.com writes:
Here's an attempt to revive this patch.
Here's the patch rebased against current HEAD, that is including the
recently committed action_at_recovery_target option.
The default for the new GUC is 'pause', as in HEAD, and
pause_at_recovery_target is
On 12/1/14, 11:57 AM, Andres Freund wrote:
On 2014-11-30 20:46:51 -0600, Jim Nasby wrote:
On 11/10/14, 7:52 PM, Tom Lane wrote:
On the whole, I'm +1 for just logging the events and seeing what we learn
that way. That seems like an appropriate amount of effort for finding out
whether there is
There doesn't seem to be documentation on *= (or search isn't finding it). Is
this intentional?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Wed, Nov 26, 2014 at 4:13 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, Nov 25, 2014 at 9:30 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Using both 9.2.9 and 9_2_STABLE 9b468bcec15f1ea7433d4, I get a fairly
reproducible startup failure.
What I was doing is restore a database from a
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Sounds good to me. The other parts of the core tests that depend on
contrib modules aren't exactly good models to follow.
Pushed; tests pass for me, let's see what buildfarm says.
Pushed? Don't see it
Adam,
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
Please let me know what you think, all feedback is greatly appreciated.
Thanks for this. Found time to do more of a review and have a few
comments:
diff --git a/src/backend/catalog/aclchk.c
On 11/28/2014 12:55 PM, Tom Lane wrote:
* This would only really address Josh's complaint if we were to back-patch
it into 9.4, but I'm hesitant to change error texts post-RC1. Thoughts?
If we don't fix an error text in an RC, what would we fix in an RC?
That's as minor as things get.
--
Josh Berkus j...@agliodbs.com writes:
On 11/28/2014 12:55 PM, Tom Lane wrote:
* This would only really address Josh's complaint if we were to back-patch
it into 9.4, but I'm hesitant to change error texts post-RC1. Thoughts?
If we don't fix an error text in an RC, what would we fix in an RC?
On 12/01/2014 12:28 PM, Josh Berkus wrote:
On 11/28/2014 12:55 PM, Tom Lane wrote:
* This would only really address Josh's complaint if we were to back-patch
it into 9.4, but I'm hesitant to change error texts post-RC1. Thoughts?
If we don't fix an error text in an RC, what would we fix in
On 2014-12-01 15:30:06 -0500, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
On 11/28/2014 12:55 PM, Tom Lane wrote:
* This would only really address Josh's complaint if we were to back-patch
it into 9.4, but I'm hesitant to change error texts post-RC1. Thoughts?
If we don't fix
On 12/01/2014 12:30 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
On 11/28/2014 12:55 PM, Tom Lane wrote:
* This would only really address Josh's complaint if we were to back-patch
it into 9.4, but I'm hesitant to change error texts post-RC1. Thoughts?
If we don't fix an error
Josh Berkus j...@agliodbs.com writes:
On 12/01/2014 12:30 PM, Tom Lane wrote:
Code-wise, yeah, but it would put some pressure on the translators.
What did you think of the new error texts in themselves?
I would prefer invalid input syntax to malformed array literal, but
I'll take anything
On Mon, Dec 1, 2014 at 3:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
On 12/01/2014 12:30 PM, Tom Lane wrote:
Code-wise, yeah, but it would put some pressure on the translators.
What did you think of the new error texts in themselves?
I would prefer
Hi all,
while working on the patch decreasing amount of memory consumed by
array_agg [1], I've ran into some strange OOM issues. Reproducing them
using the attached SQL script is rather simple.
[1] https://commitfest.postgresql.org/action/patch_view?id=1652
At first I thought there's some
On 12/01/2014 05:39 PM, Tomas Vondra wrote:
Hi all,
while working on the patch decreasing amount of memory consumed by
array_agg [1], I've ran into some strange OOM issues. Reproducing them
using the attached SQL script is rather simple.
[1]
On 2.12.2014 00:31, Andrew Dunstan wrote:
On 12/01/2014 05:39 PM, Tomas Vondra wrote:
Hi all,
while working on the patch decreasing amount of memory consumed by
array_agg [1], I've ran into some strange OOM issues. Reproducing them
using the attached SQL script is rather simple.
[1]
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Dec 1, 2014 at 3:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd be good with going to invalid input syntax if we also change
record_in to match. Anyone have a feeling pro or con about that?
I don't know. malformed array literal is a mighty
Tomas Vondra t...@fuzzy.cz writes:
On 2.12.2014 00:31, Andrew Dunstan wrote:
Doesn't this line:
TopMemoryContext: 136614192 total in 16678 blocks; 136005936 free
(500017 chunks); 608256 used
look pretty suspicious?
It certainly looks a bit large, especially considering this is a fresh
On Tue, Dec 2, 2014 at 1:58 AM, Alex Shulgin a...@commandprompt.com wrote:
Here's the patch rebased against current HEAD, that is including the
recently committed action_at_recovery_target option.
If this patch gets in, it gives a good argument to jump to 10.0 IMO.
That's not a bad thing, only
On 2.12.2014 01:33, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
On 2.12.2014 00:31, Andrew Dunstan wrote:
Doesn't this line:
TopMemoryContext: 136614192 total in 16678 blocks; 136005936 free
(500017 chunks); 608256 used
look pretty suspicious?
It certainly looks a bit large,
Tomas Vondra t...@fuzzy.cz writes:
On 2.12.2014 01:33, Tom Lane wrote:
What I suspect you're looking at here is the detritus of creation of
a huge number of memory contexts. mcxt.c keeps its own state about
existing contents in TopMemoryContext. So, if we posit that those
contexts weren't
Stephen,
Thanks for this. Found time to do more of a review and have a few
comments:
Thanks for taking a look at this and for the feedback.
I'd put the superuser_arg() check in role_has_attribute.
Ok. Though, this would affect how CATUPDATE is handled. Peter Eisentraut
previously raised
Petr Jelinek wrote:
On 25/11/14 16:30, Alvaro Herrera wrote:
Petr Jelinek wrote:
On 25/11/14 16:23, Alvaro Herrera wrote:
Robert Haas wrote:
Maybe 0 should get translated to a NULL return, instead of a bogus
timestamp.
That's one idea --- surely no transaction is going to commit at
On 12/01/2014 09:51 PM, Marco Nenciarini wrote:
I think this is a leftover, as you don't use elog afterwards.
Good catch, fixed.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
From
(2014/11/28 18:14), Ashutosh Bapat wrote:
On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
Apart from the above, I noticed that the patch doesn't consider to
call ExplainForeignModify during EXPLAIN for an inherited
On Sun, 2014-11-30 at 17:49 -0800, Peter Geoghegan wrote:
On Mon, Nov 17, 2014 at 11:39 PM, Jeff Davis pg...@j-davis.com wrote:
I can also just move isReset there, and keep mem_allocated as a uint64.
That way, if I find later that I want to track the aggregated value for
the child contexts
On Mon, Dec 1, 2014 at 11:29 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Thu, Nov 27, 2014 at 11:43 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
If you get that done, I'll have an extra look at it and then let's
have a committer look at it.
Attached patch is latest version.
On Thu, Nov 20, 2014 at 10:37 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
CLUSTER and VACUUM are not part of the supported commands anymore, so
I think that we could replace that by the addition of a reference
number in the cell of ALTER
41 matches
Mail list logo
