On Thu, Nov 20, 2014 at 10:37 PM, Dimitri Fontaine
wrote:
> Alvaro Herrera 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 TABLE for the event table_rewrite and
On Mon, Dec 1, 2014 at 11:29 PM, Sawada Masahiko wrote:
> On Thu, Nov 27, 2014 at 11:43 PM, Michael Paquier
> 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.
> I added new enum values like REINDEX_O
On Sun, 2014-11-30 at 17:49 -0800, Peter Geoghegan wrote:
> On Mon, Nov 17, 2014 at 11:39 PM, Jeff Davis 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 as well, I
(2014/11/28 18:14), Ashutosh Bapat wrote:
On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
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
UPDATE/DELETE, as shown bel
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 63edf0571961f2f2c7fd6a08b99e747ee39a3
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 transact
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 raise
Tomas Vondra 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 real sma
On 2.12.2014 01:33, Tom Lane wrote:
> Tomas Vondra 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, es
On Tue, Dec 2, 2014 at 1:58 AM, Alex Shulgin 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 the cost of making rec
Tomas Vondra 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
> cluster
Merlin Moncure writes:
> On Mon, Dec 1, 2014 at 3:01 PM, Tom Lane 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 big clue that you
> have a ba
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.
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] https://commitfest.postgresql.org/action/patch_vi
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 rare
On Mon, Dec 1, 2014 at 3:01 PM, Tom Lane wrote:
> Josh Berkus 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 "
Josh Berkus 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 we ca
On 12/01/2014 12:30 PM, Tom Lane wrote:
> Josh Berkus 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 i
On 2014-12-01 15:30:06 -0500, Tom Lane wrote:
> Josh Berkus 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 er
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
Josh Berkus 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?
> That's as
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.
--
Jo
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 b/src/backend/catalog/aclch
Tom Lane wrote:
> Alvaro Herrera 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 ...
Meh. D
On Wed, Nov 26, 2014 at 4:13 PM, Jeff Janes wrote:
> On Tue, Nov 25, 2014 at 9:30 PM, Jeff Janes 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 base backup and roll it
>> forwa
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 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 r
Alex Shulgin 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 removed completely in fav
On Nov 28, 2014, at 8:43 AM, Peter Eisentraut 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 useful third
Alvaro Herrera 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 ...
regards, tom la
Tom Lane wrote:
> Alvaro Herrera 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 smart; I t
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 e
Craig Ringer 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 protocol permitted the
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
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.
Ye
On Thu, Nov 27, 2014 at 11:43 PM, Michael Paquier
wrote:
> On Thu, Nov 27, 2014 at 8:18 PM, Sawada Masahiko
> wrote:
>> On Thu, Nov 27, 2014 at 1:07 PM, Michael Paquier
>> wrote:
>>> On Thu, Nov 27, 2014 at 12:55 AM, Sawada Masahiko
>>> wrote:
+1 to define new something object type and r
Il 01/12/14 14:16, Craig Ringer ha scritto:
>
> +#ifndef FRONTEND
> +#include
> +#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 | www.2nd
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 Supp
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/
spgist
On Mon, Dec 1, 2014 at 1:41 PM, Alvaro Herrera wrote:
> Magnus Hagander wrote:
>> On Mon, Dec 1, 2014 at 2:22 AM, Tom Lane wrote:
>> > Alvaro Herrera writes:
>> >> That was my fault -- the alvh.no-ip.org domain was deleted, and the
>> >> email system in postgresql.org rejected the commit message
Magnus Hagander wrote:
> On Mon, Dec 1, 2014 at 2:22 AM, Tom Lane wrote:
> > Alvaro Herrera 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. I
On Mon, Dec 1, 2014 at 1:31 AM, Ian Barwick wrote:
> This fixes a missing space here:
>
> http://www.postgresql.org/docs/devel/static/wal-reliability.html
>
> (present in 9.3 onwards).
Applied, thanks!
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Mon, Dec 1, 2014 at 2:22 AM, Tom Lane wrote:
> Alvaro Herrera 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. I noticed within a few hours,
>> bu
43 matches
Mail list logo
