On 3 March 2016 at 13:08, Craig Ringer wrote:
> On 3 March 2016 at 11:06, Craig Ringer wrote:
>
>> Hi all
>>
>> I've prepared a Dockerfile that produces a canned Perl 5.8.8 environment
>> based on CentOS 5 on any host with Docker. It has ccache installed and
>> enabled, git installed, IPC::Run i
On Wed, Mar 2, 2016 at 7:33 PM, Alvaro Herrera
wrote:
> Shulgin, Oleksandr wrote:
>
> > Alright. I'm attaching the latest version of this patch split in two
> > parts: the first one is NULLs-related bugfix and the second is the
> > "improvement" part, which applies on top of the first one.
>
> S
On 2016-03-01 18:31:42 +0100, Petr Jelinek wrote:
> On 01/03/16 18:18, Andres Freund wrote:
> >I'd rather just initialize commit_time to parsed->xact_time.
> >
> >This indeed is clearly a bug. I do wonder if anybody has a good idea
> >about how to add regression tests for this? It's rather annoying
On Wed, Mar 2, 2016 at 4:25 PM, wcting wrote:
> /*
> * If at page start, we must skip over the page header. But
> we can't
> * do that until we've read in the page, since the header
> size is
> * variable.
> */
>
> i don't know t
On 3 March 2016 at 13:23, Michael Paquier wrote:
> On Thu, Mar 3, 2016 at 2:20 PM, Craig Ringer
> wrote:
> > On the Perl 5.8.8 test env I've set up now, per
> >
> >
> http://www.postgresql.org/message-id/camsr+ygr6pu-guyp-ft98xwxasc9n6j-awzaqxvw_+p3rtc...@mail.gmail.com
> >
> > master currently
On Thu, Mar 3, 2016 at 3:34 PM, Michael Paquier
wrote:
> That's one of my concerns about this patch now: it is trying to do too
> much. I think that there is definitely a need for both things:
> applications may be fine to pay the lagging price when remote_apply is
> used by not having an extra er
On Tue, Mar 1, 2016 at 11:53 AM, Thomas Munro
wrote:
> On Tue, Mar 1, 2016 at 2:46 PM, Amit Langote
> wrote:
>>
>> Hi,
>>
>> On 2016/02/29 18:05, Thomas Munro wrote:
>>> On Mon, Feb 29, 2016 at 9:05 PM, Amit Langote wrote:
+ servers. A transaction that is run with
causal_reads
Noah Misch writes:
> I've modified buildfarm member mandrill to use force_parallel_mode=regress and
> max_parallel_degree=5; a full run passes. We'll now see if it intermittently
> fails the stats test, like Tom witnessed:
> http://www.postgresql.org/message-id/30385.1456077...@sss.pgh.pa.us
htt
At Wed, 2 Mar 2016 17:57:27 -0600, Jim Nasby wrote
in <56d77de7.7080...@bluetreble.com>
> On 3/2/16 5:41 PM, Tom Lane wrote:
> > Jim Nasby writes:
> >> On 3/2/16 4:21 PM, Peter Geoghegan wrote:
> >>> I think you should commit this. The chances of anyone other than you
> >>> and Masahiko recallin
On Thu, Mar 3, 2016 at 8:51 AM, Oleg Bartunov wrote:
>
>
> On Wed, Mar 2, 2016 at 11:56 PM, Emre Hasegeli wrote:
>
>> Attached patches add SP-GiST support to the inet datatypes. The
>> operator class comes with a small change on the SP-GiST framework to allow
>> fixed number of child nodes.
>>
On Wed, Mar 2, 2016 at 11:56 PM, Emre Hasegeli wrote:
> Attached patches add SP-GiST support to the inet datatypes. The operator
> class comes with a small change on the SP-GiST framework to allow fixed
> number of child nodes.
>
> The index is like prefix tree except that it doesn't bother to s
On Thu, Mar 3, 2016 at 2:20 PM, Craig Ringer wrote:
> On the Perl 5.8.8 test env I've set up now, per
>
> http://www.postgresql.org/message-id/camsr+ygr6pu-guyp-ft98xwxasc9n6j-awzaqxvw_+p3rtc...@mail.gmail.com
>
> master currently fails with
>
> t/004_timeline_switch."remove_tree" is not expor
On Fri, Feb 5, 2016 at 2:29 PM, Haribabu Kommi wrote:
>
>This patch needs to be applied on top discard_hba_and_ident_cxt patch
>that is posted earlier.
Here I attached a re-based patch to the latest head with inclusion of
discard_hba_ident_cxt patch for easier review as a single patch.
Regards,
On 3 March 2016 at 05:26, Alvaro Herrera wrote:
>
> Pushed it with that fix. I also added a further "data_" prefix, so it's
> "data_${name}_" now. Hopefully this is less problematic than
> yesterday's ...
>
>
On the Perl 5.8.8 test env I've set up now, per
http://www.postgresql.org/message
Ashutosh Bapat writes:
> On Thu, Mar 3, 2016 at 7:27 AM, Michael Paquier
> wrote:
>> Per explain.c, this looks inconsistent to me. Shouldn't NULLS LAST be
>> applied only if DESC is used in this ORDER BY clause?
> ... In this case we are constructing a query to be
> sent to the foreign server an
On 3 March 2016 at 11:06, Craig Ringer wrote:
> Hi all
>
> I've prepared a Dockerfile that produces a canned Perl 5.8.8 environment
> based on CentOS 5 on any host with Docker. It has ccache installed and
> enabled, git installed, IPC::Run installed, all the mess required to make
> CPAN work sens
On Mon, Feb 1, 2016 at 12:11 AM, Alvaro Herrera
wrote:
> So we discussed some of this stuff during the developer meeting in
> Brussels and the main conclusion is that we're going to split this up in
> multiple independently useful pieces, and write up the general roadmap
> in the wiki so that we c
Hi,
On 02/03/2016 06:46 AM, Noah Misch wrote:
On Mon, Feb 01, 2016 at 07:03:45PM +0100, Tomas Vondra wrote:
On 12/22/2015 03:49 PM, Noah Misch wrote:
On Mon, Feb 18, 2013 at 06:19:12PM -0300, Alvaro Herrera wrote:
I have pushed it now. Further testing, of course, is always welcome.
While i
David Rowley writes:
> I agree that it would be good to get this in as soon as possible. I'm
> currently very close to being done with writing Parallel Aggregate on
> top of the upper planner changes. So far this version is much cleaner
> as there's less cruft added compared with the other version
On Thu, Mar 3, 2016 at 7:27 AM, Michael Paquier
wrote:
> On Wed, Mar 2, 2016 at 7:04 PM, Rajkumar Raghuwanshi
> wrote:
> > On Wed, Mar 2, 2016 at 2:35 PM, Ashutosh Bapat
> > wrote:
> >>
> >> Thanks Rajkumar for your report. Let me know if the attached patch fixes
> >> the issue.
>
> if
On Wed, Mar 2, 2016 at 3:10 AM, Robert Haas wrote:
> On Wed, Feb 17, 2016 at 3:22 AM, Fabien COELHO wrote:
>> Indeed. My gcc 4.8.4 with --Wall does not show the warning, too bad.
>>
>> Attached is the fixed patch for the array method.
>
> Committed with a few tweaks, including running pgindent ov
On 3 March 2016 at 04:29, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
>> ISTM that we are clearly "going for it"; everybody agrees we should apply
>> the patch now.
>>
>> The longer we hold off on applying it, the longer we wait for dependent
>> changes.
>
> Agreed -- we need this in tree as soon
On Thu, Mar 3, 2016 at 2:07 PM, Kyotaro HORIGUCHI
wrote:
> Hello, thank you for the comments.
>
> At Wed, 2 Mar 2016 10:10:55 +1300, Thomas Munro
> wrote in
>
>> On Wed, Mar 2, 2016 at 7:54 AM, Robert Haas wrote:
>> > On Mon, Feb 29, 2016 at 6:32 PM, Thomas Munro
>> > wrote:
>> >> On Fri, Fe
On Mar 3, 2016 4:47 AM, "Michael Paquier" wrote:
>
> On Wed, Mar 2, 2016 at 6:54 PM, Alexander Korotkov
> wrote:
> > If FDWs existed then Postgres XC/XL were being developed then I believe
they
> > would try to build full-featured prototype of FDW based sharding. If
this
> > prototype succeed the
Hi all
I've prepared a Dockerfile that produces a canned Perl 5.8.8 environment
based on CentOS 5 on any host with Docker. It has ccache installed and
enabled, git installed, IPC::Run installed, all the mess required to make
CPAN work sensibly done, etc.
Once you build the container once you can
On 2/11/16 9:30 PM, Michael Paquier wrote:
>> Well, Yury was saying upthread that some MSVC versions have a problem
>> with the existing coding, which would be a reason to back-patch ...
>> but I'd like to see a failing buildfarm member first. Don't particularly
>> want to promise to support compi
> On Wed, Mar 2, 2016 at 6:54 PM, Alexander Korotkov
> wrote:
>> If FDWs existed then Postgres XC/XL were being developed then I believe they
>> would try to build full-featured prototype of FDW based sharding. If this
>> prototype succeed then we could make a full roadmap.
>
> Speaking here with
On Wed, Mar 2, 2016 at 7:04 PM, Rajkumar Raghuwanshi
wrote:
> On Wed, Mar 2, 2016 at 2:35 PM, Ashutosh Bapat
> wrote:
>>
>> Thanks Rajkumar for your report. Let me know if the attached patch fixes
>> the issue.
if (pathkey->pk_nulls_first)
appendStringInfoString(buf, " NULL
On Wed, Mar 2, 2016 at 6:54 PM, Alexander Korotkov
wrote:
> If FDWs existed then Postgres XC/XL were being developed then I believe they
> would try to build full-featured prototype of FDW based sharding. If this
> prototype succeed then we could make a full roadmap.
Speaking here with my XC hat,
On Thu, Mar 3, 2016 at 12:47 AM, Alvaro Herrera
wrote:
> Well, the CopyData message has an Int32 field for the message length.
> I don't know the FE/BE protocol very well but I suppose each row
> corresponds to one CopyData message, or perhaps each column corresponds
> to one CopyData message. In
On Sun, Feb 28, 2016 at 8:04 AM, Masahiko Sawada wrote:
> Attached latest version patch.
>
> The changes from previous version are,
> - Fix parser, lexer bugs.
> - Add regression test patch based on patch Suraji submitted.
>
> Please review it.
>
> [000_multi_sync_replication_v13.patch]
Hi Masahi
Hello, thank you for the comments.
At Wed, 2 Mar 2016 10:10:55 +1300, Thomas Munro
wrote in
> On Wed, Mar 2, 2016 at 7:54 AM, Robert Haas wrote:
> > On Mon, Feb 29, 2016 at 6:32 PM, Thomas Munro
> > wrote:
> >> On Fri, Feb 26, 2016 at 6:34 PM, Kyotaro HORIGUCHI
> >> wrote:
> >>> Hello, this
Hello,
At Tue, 1 Mar 2016 13:33:02 -0500, Robert Haas wrote in
> On Fri, Feb 26, 2016 at 12:33 AM, Kyotaro HORIGUCHI
> wrote:
> > I divided the last patch into one typo-fix patch and one
> > improvement patch. This is the former one.
>
> Committed.
Thank you.
--
Kyotaro Horiguchi
NTT Open
On 3/2/16 6:24 PM, Tom Lane wrote:
If the patch were proposing a similar amount of new infrastructure to
support some datatype-extensible concept of subscripting, I'd be much
happier about it.
+1
I believe there's been some handwaving in the past about extensible
approaches to subscripting, t
Vitaly Burovoy writes:
> I'd like to be a reviewer for the patch. It does not look big and very
> invasive.
> Is it a final decision or it has a chance? If something there hurts
> committers, it can end up as "Rejected with feedback" (since the patch
> is already in the CF[1])?
Well, it is prett
Teodor Sigaev writes:
> Yep, for now on my notebook (best from 5 tries):
> % pgbench -i -s 3000
> % pgbench -s 3000 -c 4 -j 4 -P 1 -T 60
> HEAD569 tps
> patched 542 tps
> % pgbench -s 3000 -c 4 -j 4 -P 1 -T 60 -S
> HEAD9500 tps
> patched 9458 tps
> Looks close to measurement error, but
On 3/2/16 5:41 PM, Tom Lane wrote:
Jim Nasby writes:
On 3/2/16 4:21 PM, Peter Geoghegan wrote:
I think you should commit this. The chances of anyone other than you
and Masahiko recalling that you developed this tool in 3 years is
essentially nil. I think that the cost of committing a developer
Jim Nasby writes:
> On 3/1/16 5:06 PM, Tom Lane wrote:
>> If we don't do that, I'm at least going to put in a similar #error for
>> Tcl 8.0; but I really think we ought to just say 8.4 is the minimum.
> Just confirmed that should be completely reasonable. I'll take a look at
> it in a few days i
On 1/19/16, Alvaro Herrera wrote:
> Dmitry Dolgov wrote:
>
>> I've cleaned up the code, created a separate JsonbRef node (and there are
>> a
>> lot of small changes because of that), abandoned an idea of "deep
>> nesting"
>> of assignments (because it doesn't relate to jsonb subscription, is more
On 3/2/16 10:48 AM, Julien Rouhaud wrote:
Good point, I don't see a lot of information available with this hooks
that a native system statistics couldn't offer. To have the same amount
of information, I think we'd need a pg_stat_autovacuum view that shows a
realtime insight of the workers, and al
Jim Nasby writes:
> On 3/2/16 4:21 PM, Peter Geoghegan wrote:
>> I think you should commit this. The chances of anyone other than you
>> and Masahiko recalling that you developed this tool in 3 years is
>> essentially nil. I think that the cost of committing a developer-level
>> debugging tool lik
On 3/1/16 5:06 PM, Tom Lane wrote:
If we don't do that, I'm at least going to put in a similar #error for
Tcl 8.0; but I really think we ought to just say 8.4 is the minimum.
Just confirmed that should be completely reasonable. I'll take a look at
it in a few days if you don't beat me to it.
On 3/2/16 12:32 PM, Tom Lane wrote:
Jim Nasby writes:
[ pltcl_objects_2.patch ]
I've pushed this with some minor fixes, as well as the followup work
mentioned in this thread.
Awesome, thanks!
I've asked Karl's opinion on increasing the minimum TCL version, but I
suspect that won't be an i
On 3/2/16 4:21 PM, Peter Geoghegan wrote:
I think you should commit this. The chances of anyone other than you
and Masahiko recalling that you developed this tool in 3 years is
essentially nil. I think that the cost of committing a developer-level
debugging tool like this is very low. Modules lik
Placing this specific message onto -bugs while keeping -hackers and
removing -novice.
Editing subject to include version and remove list identifiers.
There is continuing discussion on -hackers though mostly about how to do
this right in the future. The specific problem stems from an attempted
pe
On 3/2/16 3:52 PM, Pavel Stehule wrote:
Right, and it's arguably dubious that that doesn't already work.
Unfortunately, these % things are just random plpgsql parser hacks, not
real types. Maybe this should be done in the main PostgreSQL parser
with parameter hooks, if we wanted
Alvaro Herrera writes:
> Agreed -- we need this in tree as soon as realistically possible.
> There is a a bit a problem here, because this patch conflicts heavily
> with at least one other patch that's been in the queue for a long time,
> which is Kommi/Rowley's patch for parallel aggregation; th
On Tue, Mar 1, 2016 at 6:51 PM, Robert Haas wrote:
> I removed the pgstat stuff. I'm not sure we want that stuff in that
> form; it doesn't seem to fit with the rest of what's in that view, and
> it wasn't reliable in my testing. I did however throw together a
> little contrib module for testing
* Joe Conway (m...@joeconway.com) wrote:
> On 03/02/2016 12:54 PM, Stephen Frost wrote:
> > * Joe Conway (m...@joeconway.com) wrote:
> >> On 03/01/2016 08:00 AM, Tom Lane wrote:
> >>> Yes, we'd need some way to mark non-null ACLs as being "built-in
> >>> defaults". I do not see the need to have SQ
Hi
2016-02-24 22:18 GMT+01:00 Peter Eisentraut :
> On 1/18/16 4:21 PM, Robert Haas wrote:
> > One idea that occurs to me is: If you can DECLARE BAR FOO%TYPE, but
> > then you want to make BAR an array of that type rather than a scalar,
> > why not write that as DECLARE BAR FOO%TYPE[]? That seems
On Wed, Mar 2, 2016 at 2:44 PM, Joe Conway wrote:
> On 03/02/2016 12:54 PM, Stephen Frost wrote:
> > * Joe Conway (m...@joeconway.com) wrote:
> >> On 03/01/2016 08:00 AM, Tom Lane wrote:
> >>> Yes, we'd need some way to mark non-null ACLs as being "built-in
> >>> defaults". I do not see the need
On 03/02/2016 12:54 PM, Stephen Frost wrote:
> * Joe Conway (m...@joeconway.com) wrote:
>> On 03/01/2016 08:00 AM, Tom Lane wrote:
>>> Yes, we'd need some way to mark non-null ACLs as being "built-in
>>> defaults". I do not see the need to have SQL syntax supporting that
>>> though.
>>
>> I was th
Jeff Janes writes:
> This work (9ff60273e35cad6e9) seems have broken pg_upgrade when
> tsearch2 is installed.
> On an empty 9.4 instance with nothing but tsearch2 installed, using
> HEAD's pg_upgrade gives this error:
> pg_restore: creating OPERATOR CLASS "public.gin_tsvector_ops"
> pg_restore:
Craig Ringer wrote:
> On 2 March 2016 at 07:07, Alvaro Herrera wrote:
>
> > Craig Ringer wrote:
> >
> > > diff --git a/src/test/perl/TestLib.pm b/src/test/perl/TestLib.pm
> > > index 3d11cbb..8c13655 100644
> > > --- a/src/test/perl/TestLib.pm
> > > +++ b/src/test/perl/TestLib.pm
> > > @@ -112,9
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Wed, Mar 2, 2016 at 1:54 PM, Stephen Frost wrote:
> > Rather than have two aclitem[] columns in every catalog, since this
> > information is only used by pg_dump and not during normal operation, we
> > could use the approach that pg_desc
On Wed, Mar 2, 2016 at 1:54 PM, Stephen Frost wrote:
> * Joe Conway (m...@joeconway.com) wrote:
> > On 03/01/2016 08:00 AM, Tom Lane wrote:
> > > Joe Conway writes:
> > >> Would it be a terrible idea to add some attribute to ACLs which can be
> > >> used to indicate they should not be dumped (an
Attached patches add SP-GiST support to the inet datatypes. The operator
class comes with a small change on the SP-GiST framework to allow fixed
number of child nodes.
The index is like prefix tree except that it doesn't bother to split the
addresses into parts as text is split. It also doesn't
* Joe Conway (m...@joeconway.com) wrote:
> On 03/01/2016 08:00 AM, Tom Lane wrote:
> > Joe Conway writes:
> >> Would it be a terrible idea to add some attribute to ACLs which can be
> >> used to indicate they should not be dumped (and supporting syntax)?
> >
> > Yes, we'd need some way to mark no
On Wed, Mar 2, 2016 at 9:53 PM, Josh berkus wrote:
> On 02/24/2016 01:22 AM, Konstantin Knizhnik wrote:
>
>> Sorry, but based on this plan it is possible to make a conclusion that
>> there are only two possible cluster solutions for Postgres:
>> XC/XL and FDW-based. From my point of view there a
On 02/24/2016 01:22 AM, Konstantin Knizhnik wrote:
Sorry, but based on this plan it is possible to make a conclusion that
there are only two possible cluster solutions for Postgres:
XC/XL and FDW-based. From my point of view there are much more
possible alternatives.
Definitely.
Currently we
Shulgin, Oleksandr wrote:
> Alright. I'm attaching the latest version of this patch split in two
> parts: the first one is NULLs-related bugfix and the second is the
> "improvement" part, which applies on top of the first one.
So is this null-related bugfix supposed to be backpatched? (I assume
Jim Nasby writes:
> [ pltcl_objects_2.patch ]
I've pushed this with some minor fixes, as well as the followup work
mentioned in this thread.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
Tom Lane wrote:
> In create_opclass.sgml, not only do we have the list of AMs supporting
> STORAGE, but there is also a paragraph describing which AMs do what
> for input datatypes of FUNCTION members (around line 175).
I placed BRIN together with gist/gin/spgist here, namely that the optype
defa
On Wed, Mar 2, 2016 at 5:41 AM, Magnus Hagander wrote:
> Ok, I've pushed a code that does that.
Thank you.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Mar 2, 2016 at 5:46 PM, David Steele wrote:
> On 3/2/16 11:10 AM, Shulgin, Oleksandr wrote:
> > On Wed, Feb 24, 2016 at 12:30 AM, Tomas Vondra
> > mailto:tomas.von...@2ndquadrant.com>>
> wrote:
> >
> > I think it'd be useful not to have all the changes in one lump, but
> > structu
Hi Magnus,
I've finally found some time to take a look to the patch.
It applies with some fuzziness on master, but the result looks correct.
Unfortunately the OID of the new pg_stop_backup function conflicts with
"pg_blocking_pids()" patch (52f5d578d6c29bf254e93c69043b817d4047ca67).
After changi
On 02/03/2016 07:30, Michael Paquier wrote:
> On Tue, Mar 1, 2016 at 11:37 PM, Julien Rouhaud wrote:
>> I'm not sure what are the fancy things that Michael had in mind with
>> exposing the private structure. Michael, was it something like having
>> the ability to change some of these data through
Tomas Vondra wrote:
> My guess is this is a problem at the protocol level - the 'd' message is
> CopyData, and all the messages use int32 to define length. So if there's
> a 2GB row, it's likely to overflow.
Yes. Besides, the full message includes a negative length:
> postgres=# \copy
Hi,
On 03/02/2016 05:17 PM, Thom Brown wrote:
...
Well, firstly, the patches all apply.
But I have a question (which is coming really late, but I'll ask it
anyway). Is it intended that CREATE STATISTICS will only be for
multivariate statistics? Or do you think we could add support for
express
On 3/2/16 11:10 AM, Shulgin, Oleksandr wrote:
> On Wed, Feb 24, 2016 at 12:30 AM, Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> wrote:
>
> I think it'd be useful not to have all the changes in one lump, but
> structure this as a patch series with related changes in separate
> ch
On 2 March 2016 at 14:56, Tomas Vondra wrote:
>
> Hi,
>
> Attached is v10 of the patch series. There are 9 parts at the moment:
>
> 0001-teach-pull_-varno-varattno-_walker-about-RestrictInf.patch
> 0002-shared-infrastructure-and-functional-dependencies.patch
> 0003-clause-reduction-using-fun
On Wed, Feb 24, 2016 at 12:30 AM, Tomas Vondra wrote:
> Hi,
>
> On 02/08/2016 03:01 PM, Shulgin, Oleksandr wrote:
> >
> ...
>
>>
>> I've incorporated this fix into the v2 of my patch, I think it is
>> related closely enough. Also, added corresponding changes to
>> compute_distinct_stats(), which
On 11/02/16 18:29, Magnus Hagander wrote:
Most of the pl/pgsql functions and variables are prefixed plpgsql_, so they
don't risk conflicting with other shared libraries loaded.
There are a couple that are not prefixed. Attached patch fixes that. It's
mostly a cleanup, but I think it's something
On Tue, Mar 1, 2016 at 7:47 PM, Michael Paquier
wrote:
> 2016-09 has been created then:
> https://commitfest.postgresql.org/10/
> People, feel free to park future patches there.
I think that should be in status "open" rather than "future".
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The
/*
* If at page start, we must skip over the page header. But
we can't
* do that until we've read in the page, since the header
size is
* variable.
*/
i don't know the meaning behind this comments,
if ((RecPtr->xrecoff % X
I wrote:
> Can't use string ("Test::Builder") as a HASH ref while "strict refs" in use
> at /usr/share/perl5/Test/Builder.pm line 1798.
> The referenced line number is the end of the file,
Oh, scratch that; I was looking at the wrong file. Actually,
/usr/share/perl5/Test/Builder.pm has
sub det
Tom Lane wrote:
> I'm inclined to feel that the right answer is to fix all these
> omissions, not to decide that we're not maintaining this documentation
> anymore. Alvaro, I think this one's in your court.
Will fix.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Devel
Daniel Verite wrote:
> The cause of the crash turns out to be, in enlargeStringInfo():
>
> needed += str->len + 1; /* total space required now */
>
> needed is an int and str->len is an int64, so it overflows when the
> size has to grow beyond 2^31 bytes, fails to enlarge the buffer and
>
Simon Riggs wrote:
> ISTM that we are clearly "going for it"; everybody agrees we should apply
> the patch now.
>
> The longer we hold off on applying it, the longer we wait for dependent
> changes.
Agreed -- we need this in tree as soon as realistically possible.
There is a a bit a problem her
On 03/02/2016 04:23 PM, Tom Lane wrote:
Tomas Vondra writes:
On 03/02/2016 03:18 PM, Daniel Verite wrote:
However, getting it to the client with \copy big2 to 'file'
still produces the error in psql:
lost synchronization with server: got message type "d"
and leaves an empty file, so there ar
Tomas Vondra writes:
> On 03/02/2016 03:18 PM, Daniel Verite wrote:
>> However, getting it to the client with \copy big2 to 'file'
>> still produces the error in psql:
>> lost synchronization with server: got message type "d"
>> and leaves an empty file, so there are more problems to solve to
>> g
Hi,
On 03/02/2016 03:18 PM, Daniel Verite wrote:
I wrote:
postgres=# \copy big2 to /dev/null
lost synchronization with server: got message type "d", length -1568669676
The backend aborts with the following backtrace:
Program terminated with signal 6, Aborted.
#0 0x7f82ee68e165 i
The 2016-03 commitfest is officially in progress!
There are currently a lot of patches waiting for review but with no
reviewers:
Needs review: 97
Needs *reviewer*: 58
Please check the "needs reviewer" list
(https://commitfest.postgresql.org/9/?reviewer=-2) for patches to
review. The committers
I wrote:
> postgres=# \copy big2 to /dev/null
> lost synchronization with server: got message type "d", length -1568669676
>
> The backend aborts with the following backtrace:
>
> Program terminated with signal 6, Aborted.
> #0 0x7f82ee68e165 in raise () from /lib/x86_64-linux-gnu/l
Robert Haas writes:
> On Tue, Mar 1, 2016 at 10:22 AM, Tom Lane wrote:
>> I think the default pgbench queries are too simple to have any possible
>> benefit from this patch. It does look like you're seeing some extra
>> planning time, which I think is likely due to redundant construction
>> of P
On 2 March 2016 at 13:47, Robert Haas wrote:
> On Tue, Mar 1, 2016 at 10:22 AM, Tom Lane wrote:
> > Teodor Sigaev writes:
> >>> I do not think the patch will make a lot of performance difference
> as-is;
> >>> its value is more in what it will let us do later. There are a couple
> of
> >
> >>
On Tue, Mar 1, 2016 at 10:22 AM, Tom Lane wrote:
> Teodor Sigaev writes:
>>> I do not think the patch will make a lot of performance difference as-is;
>>> its value is more in what it will let us do later. There are a couple of
>
>> Yep, for now on my notebook (best from 5 tries):
>> % pgbench -
On Wed, Mar 2, 2016 at 7:34 AM, Michael Paquier
wrote:
> On Wed, Mar 2, 2016 at 9:19 PM, Magnus Hagander
> wrote:
> > Needs Review -> Needs Review
> > Waiting on Author -> Refuse moving
> > Ready for committer -> Ready for Committer
> > Committed -> refuse moving
> > Moved to next cf -> refuse m
On Wed, Mar 2, 2016 at 9:19 PM, Magnus Hagander wrote:
> Needs Review -> Needs Review
> Waiting on Author -> Refuse moving
> Ready for committer -> Ready for Committer
> Committed -> refuse moving
> Moved to next cf -> refuse moving (if it's already set like this, it would
> probably be a bug)
> R
On Tue, Mar 1, 2016 at 10:27 AM, Tom Lane wrote:
> Alvaro Herrera writes:
> > Magnus Hagander wrote:
> >> That said, we can certainly reconsider that. Would we always copy the
> value
> >> over? Even if it was, say, rejected? (so it would be copied to the new
> CF
> >> but still marked rejected)
On Wed, Mar 2, 2016 at 5:43 PM, Valery Popov wrote:
>
>>>
>>> db_user_namespace causes the client's and
>>> server's user name representation to differ.
>>> Authentication checks are always done with the server's user name
>>> so authentication methods must
On 1 March 2016 at 20:03, Tom Lane wrote:
> In any event, I am now of the opinion that this patch needs to be reverted
> outright and returned to the authors for redesign. There are too many
> things wrong with it and too little reason to think that we have to have
> it in 9.5.
>
Agreed; I'd a
On 1 March 2016 at 17:22, Jeff Janes wrote:
> On Tue, Mar 1, 2016 at 7:40 AM, Tom Lane wrote:
> > Tobias Florek writes:
> >> When creating an index to use for an ORDER BY clause, a simple query
> >> starts to return more results than expected. See the following detailed
> >> log.
> >
> > Ugh.
On 01.03.2016 22:02, Bruce Momjian wrote:
On Tue, Mar 1, 2016 at 07:56:58PM +0100, Petr Jelinek wrote:
Note that I am not saying that other discussed approaches are any
better, I am saying that we should know approximately what we
actually want and not just beat FDWs with a hammer and hope sh
Thanks Ashutosh. Retested the issue after applying given patch,It is fine
now.
Thanks & Regards,
Rajkumar Raghuwanshi
QMG, EnterpriseDB Corporation
On Wed, Mar 2, 2016 at 2:35 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Thanks Rajkumar for your report. Let me know if the attac
On Tue, Mar 1, 2016 at 10:11 PM, Bruce Momjian wrote:
> On Tue, Mar 1, 2016 at 02:02:44PM -0500, Bruce wrote:
> > On Tue, Mar 1, 2016 at 07:56:58PM +0100, Petr Jelinek wrote:
> > > Note that I am not saying that other discussed approaches are any
> > > better, I am saying that we should know ap
On Tue, Mar 1, 2016 at 7:03 PM, Robert Haas wrote:
> On Tue, Mar 1, 2016 at 10:37 AM, Bruce Momjian wrote:
> > On Tue, Mar 1, 2016 at 10:19:45AM -0500, Robert Haas wrote:
> >> > Two reasons:
> >> > 1. There is no ideal implementation of DTM which will fit all
> possible needs
> >> > and be eff
On Wed, Mar 2, 2016 at 4:36 AM, Tomas Vondra
wrote:
Hi,
>
> On 03/01/2016 08:02 PM, Bruce Momjian wrote:
>
>> On Tue, Mar 1, 2016 at 07:56:58PM +0100, Petr Jelinek wrote:
>>
>>> Note that I am not saying that other discussed approaches are any
>>> better, I am saying that we should know approxim
On Tue, Mar 1, 2016 at 7:03 PM, Robert Haas wrote:
> On Tue, Mar 1, 2016 at 10:37 AM, Bruce Momjian wrote:
> > On Tue, Mar 1, 2016 at 10:19:45AM -0500, Robert Haas wrote:
> >> > Two reasons:
> >> > 1. There is no ideal implementation of DTM which will fit all
> possible needs
> >> > and be eff
Thanks Rajkumar for your report. Let me know if the attached patch fixes
the issue.
The code did not add NULL LAST clause the case when pk_nulls_first is false
in pathkey. PFA the fix for the same. I have also added few tests to
postgres_fdw.sql for few combinations of asc/desc and nulls first/las
1 - 100 of 102 matches
Mail list logo
