>
> 7. I think it is not your bug, but probably a bug in Hash index
> itself; page flag is set to 66 (for below test); So the page is both
> LH_BUCKET_PAGE and LH_BITMAP_PAGE. Is not this a bug in hash index?
>
> I have inserted 3000 records. Hash index is on integer column.
> select hasho_flag FRO
On Sat, Jan 14, 2017 at 12:58 AM, Dilip Kumar wrote:
> On Wed, Jan 11, 2017 at 7:47 PM, Dilip Kumar wrote:
>> +void
>> +pgstat_count_sqlstmt(const char *commandTag)
>> +{
>> + PgStat_SqlstmtEntry *htabent;
>> + bool found;
>> +
>> + if (!pgstat_track_sql)
>> + return
>>
>> Callers of pgstat_count
On Fri, Jan 13, 2017 at 9:15 PM, Fabien COELHO wrote:
>
>>> Could it be related to transformations operated when the file is
>>> downloaded
>>> and saved, because it is a text file?
>>
>>
>> I think this is delaying the patch unnecessarily, I have attached a
>> version, please see if you can apply
On Tue, Nov 29, 2016 at 1:35 PM, Michael Paquier
wrote:
> On Tue, Nov 22, 2016 at 8:35 PM, Haribabu Kommi
> wrote:
>> Hi Craig,
>>
>> This is a gentle reminder.
>>
>> you assigned as reviewer to the current patch in the 11-2016 commitfest.
>> But you haven't shared your review yet. Please share y
On Sun, Dec 18, 2016 at 1:27 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Speaking about implementation of `jsonb_delete_array` - it's fine, but I
> would like to suggest two modifications:
>
> * create a separate helper function for jsonb delete operation, to use it in
> both `jsonb_delete`
On Tue, Jan 17, 2017 at 12:38 PM, Michael Paquier wrote:
> On Tue, Jan 17, 2017 at 4:06 PM, Beena Emerson
> wrote:
> > I have already made patch for the generic SHOW replication command
> > (attached) and am working on the new initdb patch based on that.
> > I have not yet fixed the pg_standby i
On Tue, Jan 17, 2017 at 4:06 PM, Beena Emerson wrote:
> I have already made patch for the generic SHOW replication command
> (attached) and am working on the new initdb patch based on that.
> I have not yet fixed the pg_standby issue. I am trying to address all the
> comments and bugs still.
Havi
On Tue, Jan 17, 2017 at 12:18 PM, Michael Paquier wrote:
> On Sun, Jan 8, 2017 at 9:52 AM, Jim Nasby
> wrote:
> >> I agree pretty_print_kb would have been a better for this function.
> >> However, I have realised that using the show hook and this function is
> >> not suitable and have found a be
On Wed, Jan 11, 2017 at 4:50 PM, Michael Paquier
wrote:
> Looking at this patch, I am not sure that it is worth worrying about.
> This is a receipt to make back-patching a bit more complicated, and it
> makes the code more complicated to understand. So I would vote for
> rejecting it and move on.
On Sun, Jan 8, 2017 at 9:52 AM, Jim Nasby wrote:
>> I agree pretty_print_kb would have been a better for this function.
>> However, I have realised that using the show hook and this function is
>> not suitable and have found a better way of handling the removal of
>> GUC_UNIT_XSEGS which no longer
On Thu, Dec 22, 2016 at 6:14 AM, Thomas Munro
wrote:
> On Thu, Dec 22, 2016 at 2:14 AM, Fujii Masao wrote:
>> I agree that the capability to measure the remote_apply lag is very useful.
>> Also I want to measure the remote_write and remote_flush lags, for example,
>> in order to diagnose the caus
On Tue, Jan 10, 2017 at 8:49 AM, Tsunakawa, Takayuki
wrote:
> Hello, Amit, Magnus,
>
> I'm sorry for my late reply. Yesterday was a national holiday in Japan.
>
>
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila
>> PGSharedMemoryRe
On Tue, Jan 17, 2017 at 10:19 AM, Haribabu Kommi
wrote:
> On Tue, Jan 10, 2017 at 6:35 PM, Michael Paquier
> wrote:
>> +/* LDAP supports 10 currently, keep this well above the most any
>> method needs */
>> +#define MAX_OPTIONS 12
>> Er, why? There is an assert already, that should be enough.
>
>
On Wed, Jan 11, 2017 at 10:55 AM, Dilip Kumar wrote:
> I have reviewed the latest patch and I don't have any more comments.
> So if there is no objection from other reviewers I can move it to
> "Ready For Committer"?
Seeing no objections, I have moved it to Ready For Committer.
--
Regards,
Dil
Hi Amit,
On 2016/12/23 14:21, Amit Khandekar wrote:
> Currently an Append plan node does not execute its subplans in
> parallel. There is no distribution of workers across its subplans. The
> second subplan starts running only after the first subplan finishes,
> although the individual subplans ma
On 17 January 2017 at 16:30, Tomas Vondra wrote:
> Let's instead use an example similar to what Antonin mentioned in the
> initial post - two tables, with two columns each.
>
> CREATE TABLE t1 (a INT, b INT);
> CREATE TABLE t2 (c INT, d INT);
>
> And let's assume each table has 100.000 row
Thanks, Josh, for everything. I especially enjoyed your monthly updates at
SFPUG.
Cheers,
Steve
On Thu, Jan 12, 2017 at 1:59 PM, Merlin Moncure wrote:
> On Wed, Jan 11, 2017 at 6:29 PM, Josh Berkus wrote:
> > Hackers:
> >
> > You will have noticed that I haven't been very active for the past y
On 16 January 2017 at 15:54, Masahiko Sawada wrote:
> Since autovacuum worker wakes up autovacuum launcher after launched
> the autovacuum launcher could try to spawn worker process at high
> frequently if you have database with very large table in it that has
> just passed autovacuum_freeze_max_a
On Fri, Jan 13, 2017 at 9:58 AM, Mithun Cy wrote:
> On Fri, Jan 6, 2017 at 11:43 AM, Amit Kapila wrote:
Below are review comments on latest version of patch.
1.
/*
- * Read the metapage to fetch original bucket and tuple counts. Also, we
- * keep a copy of the last-seen metapage so that we c
On Sun, Jan 8, 2017 at 2:01 PM, Jim Nasby wrote:
> On 12/29/16 9:55 PM, Haribabu Kommi wrote:
>
>> The tuples which don't have multiple copies or frozen data will be moved
>> from WOS to ROS periodically by the background worker process or autovauum
>> process. Every column data is stored separat
On Sat, Jan 14, 2017 at 3:10 AM, Vladimir Rusinov wrote:
> Attached are two new version of the patch: one keeps aliases, one don't.
> Also, remove stray reference to xlog function in one of the tests.
>
> I've lost vote count. Should we create a form to calculate which one of the
> patches should
On Sun, Jan 8, 2017 at 4:20 AM, Bruce Momjian wrote:
> On Fri, Dec 30, 2016 at 02:55:39PM +1100, Haribabu Kommi wrote:
> >
> > Hi All,
> >
> > Fujitsu was interested in developing a columnar storage extension with
> minimal
> > changes the server backend.
> >
> > The columnar store is implemented
On 01/17/2017 12:42 AM, David Rowley wrote:
On 10 January 2017 at 06:56, Antonin Houska wrote:
Before performing the final aggregation, we need to multiply sum(a.x) by
count(j.*) because w/o the aggregation at base relation level the input
of the query-level aggregation would look like
a.i |
On 1/13/17 3:09 PM, Peter van Hardenberg wrote:
A new data type, and/or a new index type could both be nicely scoped
bits of work.
Did you have any particular data/index types in mind?
Personally I'd love something that worked like a python dictionary, but
I'm not sure how that'd work without
On 1/13/17 4:08 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
On 1/10/17 1:53 AM, Alexander Korotkov wrote:
1. What project ideas we have?
Perhaps allowing SQL-only extensions without requiring filesystem files
would be a good project.
Don't we already have that in patch form? Dimitri submitt
On 1/13/17 11:22 PM, Tom Lane wrote:
I wonder what depth of include-file nesting
psql can support, or whether we'll be able to fix it to optimize tail
recursion of an include file. Because somebody will be asking for that
if this is the toolset you give them.
I think the solution to that is st
On 1/13/17 10:56 PM, Serge Rielau wrote:
But what irks me in this debate is that any reasoned and detailed
argumentation of value of the principle itself is shut down with
un-reasoned and un-detailed one-liners.
“I’m not convinced” is not an argument.
Counterpoints require content. Something star
On Tue, Jan 17, 2017 at 2:21 AM, Karl O. Pinc wrote:
> On January 15, 2017 11:47:51 PM CST, Michael Paquier
> wrote:
>>On Mon, Jan 16, 2017 at 1:14 PM, Karl O. Pinc wrote:
>>With all those issues fixed, I finish with the attached, that I am
>>fine to pass down to a committer. I still think that
On Wed, Oct 12, 2016 at 10:16 AM, Heikki Linnakangas wrote:
> The number of *input* tapes we can use in each merge pass is still limited,
> by the memory needed for the tape buffers and the merge heap, but only one
> output tape is active at any time. The inactive output tapes consume very
> few r
On Tue, Jan 10, 2017 at 6:35 PM, Michael Paquier
wrote:
> On Thu, Jan 5, 2017 at 1:58 PM, Michael Paquier
> wrote:
> > Could you hold on a bit to commit that? I'd like to look at it in more
> > details. At quick glance, there is for example no need to use
> > CreateTemplateTupleDesc and list the
On 10 January 2017 at 06:56, Antonin Houska wrote:
> Before performing the final aggregation, we need to multiply sum(a.x) by
> count(j.*) because w/o the aggregation at base relation level the input
> of the query-level aggregation would look like
>
> a.i | a.x | b.j
>
> 1 |
In case this still matters, I think GetValue should look more or less
like this (untested):
/*
* Return the value for column number 'colnum' for the current row. If column
* -1 is requested, return representation of the whole row.
*
* This leaks memory, so be sure to reset often the context
Given
https://www.postgresql.org/message-id/20170116210019.a3glfwspg5lnf...@alap3.anarazel.de
which is going to heavily change how the executor works in this area, I
am returning this patch to you again. I would like a few rather minor
changes:
1. to_xmlstr can be replaced with calls to xmlCharSt
Alvaro Herrera writes:
> Permit dump/reload of not-too-large >1GB tuples
I noticed that this commit has created an overflow hazard on 64-bit
hardware: it's not difficult to attempt to make a tuple exceeding 4GB.
You just need a few GB-sized input values. But that's uncool for
a couple of reasons
Andres Freund wrote:
> On 2017-01-16 16:04:34 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > On 2017-01-16 12:17:46 -0300, Alvaro Herrera wrote:
> > > > Hmm. I wonder if your stuff could be used as support code for
> > > > XMLTABLE[1].
> > >
> > > I don't immediately see what functio
On 2017-01-16 14:34:58 -0500, Tom Lane wrote:
> Will go fix these things.
Thanks!
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-01-16 16:04:34 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2017-01-16 12:17:46 -0300, Alvaro Herrera wrote:
> > > Hmm. I wonder if your stuff could be used as support code for
> > > XMLTABLE[1].
> >
> > I don't immediately see what functionality overlaps, could you expand o
Hi,
On 2017-01-16 14:13:18 -0500, Tom Lane wrote:
> Andres Freund writes:
> > That worked quite well. So we have a few questions, before I clean this
> > up:
>
> > - For now the node is named 'Srf' both internally and in explain - not
> > sure if we want to make that something longer/easier to
I wrote:
> Andres Freund writes:
>> I wonder if there should be a seperate expression type for
>> the INSERT ... VALUES(exactly-one-row); since that behaves quite
>> differently.
> Perhaps. Or maybe we should just use EXPR_KIND_SELECT_TARGET for that?
After looking around, I think we probably b
I just realized that your new xml_xmlnodetostr is line-by-line identical
to the existing xml_xmlnodetoxmltype except for two or three lines.
I think that's wrong. I'm going to patch the existing function so that
they can share code.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
P
Andres Freund writes:
> That worked quite well. So we have a few questions, before I clean this
> up:
> - For now the node is named 'Srf' both internally and in explain - not
> sure if we want to make that something longer/easier to understand for
> others? Proposals? TargetFunctionScan? Set
Andres Freund writes:
> Is there a reason not to just set p_hasTargetSRFs once towards the end
> of the function, instead of doing so for all the non-error cases?
Yes: it's not supposed to get set when the SRF is in FROM.
> I wonder if there should be a seperate expression type for
> the INSERT
Andres Freund wrote:
> On 2017-01-16 12:17:46 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> >
> > > That worked quite well. So we have a few questions, before I clean this
> > > up:
> > >
> > > - For now the node is named 'Srf' both internally and in explain - not
> > > sure if we wa
2017-01-16 19:43 GMT+01:00 Peter Geoghegan :
> On Mon, Jan 16, 2017 at 10:38 AM, Pavel Stehule
> wrote:
> > Should not be enhanced regress tests too?
>
> We already have coverage of multi-pass external tuplesorts, as of a
> few months back. That didn't catch this bug only because it was a
> pass-
Peter Geoghegan writes:
> The problem was that one particular call to the macro
> RELEASE_SLAB_SLOT() happened to lack a test-for-NULL-argument needed
> by pass-by-value datum cases. The other two RELEASE_SLAB_SLOT() calls
> already have such a check.
> Attached patch fixes the bug.
Pushed, than
On 2017-01-16 12:17:46 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > That worked quite well. So we have a few questions, before I clean this
> > up:
> >
> > - For now the node is named 'Srf' both internally and in explain - not
> > sure if we want to make that something longer/easi
On Mon, Jan 16, 2017 at 10:38 AM, Pavel Stehule wrote:
> Should not be enhanced regress tests too?
We already have coverage of multi-pass external tuplesorts, as of a
few months back. That didn't catch this bug only because it was a
pass-by-value datum tuplesort. The relevant RELEASE_SLAB_SLOT()
Karl O. Pinc wrote:
> I do have a question here regards code formatting.
> The patch now contains:
>
> if (log_filepath == NULL)
> {
> /* Bad data. Avoid segfaults etc. and return NULL to caller. */
> break;
> }
>
> I'm not sure how this fits in with PG coding style,
2017-01-16 19:24 GMT+01:00 Peter Geoghegan :
> On Mon, Jan 16, 2017 at 3:48 AM, Michael Paquier
> wrote:
> > Indeed. It crashes for me immediately by adding an ORDER BY:
> > select count(distinct t) from seq_tab order by 1;
>
> The problem was that one particular call to the macro
> RELEASE_SLAB_
On Mon, Jan 16, 2017 at 3:48 AM, Michael Paquier
wrote:
> Indeed. It crashes for me immediately by adding an ORDER BY:
> select count(distinct t) from seq_tab order by 1;
The problem was that one particular call to the macro
RELEASE_SLAB_SLOT() happened to lack a test-for-NULL-argument needed
by
On Mon, Jan 16, 2017 at 4:33 PM, Fujii Masao wrote:
> On Mon, Jan 16, 2017 at 10:00 PM, Magnus Hagander
> wrote:
> >
> >
> > On Wed, Jan 4, 2017 at 3:32 PM, Peter Eisentraut
> > wrote:
> >>
> >> This patch looks reasonable to me.
> >>
> >> Attached is a top-up patch with a few small fixups.
> >
On January 15, 2017 11:47:51 PM CST, Michael Paquier
wrote:
>On Mon, Jan 16, 2017 at 1:14 PM, Karl O. Pinc wrote:
>
>
>> Attached also are 2 patches which abstract some hardcoded
>> constants into symbols. Whether to apply them is a matter
>> of style and left to the maintainers, which is why
"Daniel Verite" writes:
> Tom Lane wrote:
>> Also, why aren't you using ParseVariableBool's existing ability to report
>> errors?
> Its' because there are two cases:
> - either only a boolean can be given to the command or variable,
> in which we let ParseVariableBool() tell:
>unrecogni
Tom Lane wrote:
> "Daniel Verite" writes:
> > [ psql-var-hooks-v6.patch ]
>
> I took a quick look through this. It seems to be going in generally
> the right direction, but here's a couple of thoughts:
Thanks for looking into this!
> I'm inclined to think that the best choice is for
On January 15, 2017 11:47:51 PM CST, Michael Paquier
wrote:
>On Mon, Jan 16, 2017 at 1:14 PM, Karl O. Pinc wrote:
>> I do have a question here regards code formatting.
>> The patch now contains:
>>
>> if (log_filepath == NULL)
>> {
>> /* Bad data. Avoid segfaults etc. and retur
The ability to exploit hashed aggregation within sorted groups, when the order
of the input stream can be exploited this way, is potentially a useful way to
improve aggregation performance more generally. This would potentially be
beneficial when the input size is expected to be larger than the
On Thu, Jan 12, 2017 at 7:56 PM, Amit Kapila wrote:
> On Thu, Jan 12, 2017 at 8:51 AM, Robert Haas wrote:
>> On Wed, Jan 11, 2017 at 9:58 PM, Amit Kapila wrote:
>>> The other alternative is to remember this information in SubPlan. We
>>> can retrieve parallel_safe information from best_path and
On Mon, Jan 16, 2017 at 10:00 PM, Magnus Hagander wrote:
>
>
> On Wed, Jan 4, 2017 at 3:32 PM, Peter Eisentraut
> wrote:
>>
>> This patch looks reasonable to me.
>>
>> Attached is a top-up patch with a few small fixups.
>>
>> I suggest to wait for the resolution of the "Replication/backup
>> defa
Andres Freund wrote:
> That worked quite well. So we have a few questions, before I clean this
> up:
>
> - For now the node is named 'Srf' both internally and in explain - not
> sure if we want to make that something longer/easier to understand for
> others? Proposals? TargetFunctionScan? Se
On Wed, Jan 4, 2017 at 3:32 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> This patch looks reasonable to me.
>
> Attached is a top-up patch with a few small fixups.
>
> I suggest to wait for the resolution of the "Replication/backup
> defaults" thread. I would not want to be i
On Mon, Jan 16, 2017 at 9:12 PM, Magnus Hagander wrote:
> Where did your research point to then? :) I just read the gzip rfc
> (http://www.zlib.org/rfc-gzip.html) which seems to call it that at least?
Well, OK. I was not aware of this RFC. I guessed it by looking at the
code of gzip, that uses th
On Sun, Jan 15, 2017 at 6:44 AM, Michael Paquier
wrote:
> On Sun, Jan 15, 2017 at 1:31 AM, Magnus Hagander
> wrote:
> >
> >
> > On Tue, Jan 10, 2017 at 3:01 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >> Based on some analysis, it is enough to look at the last 4 bytes of
> >>
On Fri, Jan 13, 2017 at 11:06 PM, Robert Haas wrote:
> On Fri, Jan 13, 2017 at 9:28 AM, Anastasia Lubennikova
> wrote:
>> I didn't find any case of noticeable performance degradation,
>> so set status to "Ready for committer".
>
> The very first hunk of doc changes looks like it makes the whitesp
(Adding Peter in CC who also worked on that)
On Mon, Jan 16, 2017 at 7:14 PM, Mithun Cy wrote:
> Test:
> --
> create table seq_tab(t int);
> insert into seq_tab select generate_series(1, 1000);
> select count(distinct t) from seq_tab;
>
> #0 0x0094a9ad in pfree (pointer=0x0) at m
On Mon, Jan 16, 2017 at 10:37 PM, Craig Ringer
wrote:
> On 16 Jan. 2017 17:09, "Michael Paquier" wrote:
>
> On Mon, Jan 16, 2017 at 9:40 AM, Thomas Munro
> wrote:
>> I also have longer term plans to show the first and third of them
>> running with the read-only transaction moved to a standby ser
On Mon, Jan 16, 2017 at 1:50 PM, Amit Khandekar wrote:
> On 13 January 2017 at 19:15, Alvaro Herrera wrote:
>> I think this is the same problem as reported in
>> https://www.postgresql.org/message-id/CAMkU=1yE4YyCC00W_GcNoOZ4X2qxF7x5DUAR_kMt-Ta=ypy...@mail.gmail.com
>
> Ah yes, this is the same p
Test:
--
create table seq_tab(t int);
insert into seq_tab select generate_series(1, 1000);
select count(distinct t) from seq_tab;
#0 0x0094a9ad in pfree (pointer=0x0) at mcxt.c:1007
#1 0x00953be3 in mergeonerun (state=0x1611450) at tuplesort.c:2803
#2 0x00953824
On Mon, Jan 16, 2017 at 6:34 PM, Masahiko Sawada wrote:
> On Mon, Jan 16, 2017 at 6:27 PM, Fujii Masao wrote:
>> On Mon, Jan 16, 2017 at 5:42 PM, Masahiko Sawada
>> wrote:
>>> Hi,
>>>
>>> Attached patch fixes comment typos in condition_variable.c
>>
>> Seems the patch still has the typo. "initi
On 16 Jan. 2017 17:09, "Michael Paquier" wrote:
On Mon, Jan 16, 2017 at 9:40 AM, Thomas Munro
wrote:
> I also have longer term plans to show the first and third of them
> running with the read-only transaction moved to a standby server.
> Kevin Grittner gave me the idea of multi-server isolation
On Mon, Jan 16, 2017 at 6:27 PM, Fujii Masao wrote:
> On Mon, Jan 16, 2017 at 5:42 PM, Masahiko Sawada
> wrote:
>> Hi,
>>
>> Attached patch fixes comment typos in condition_variable.c
>
> Seems the patch still has the typo. "initiailly" should be "initially"?
>
Yes, it should be "initially".
R
On Mon, Jan 16, 2017 at 5:42 PM, Masahiko Sawada wrote:
> Hi,
>
> Attached patch fixes comment typos in condition_variable.c
Seems the patch still has the typo. "initiailly" should be "initially"?
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 2017/01/14 6:24, Robert Haas wrote:
> On Tue, Jan 10, 2017 at 6:06 AM, Amit Langote wrote:
>>
>> Thanks! I realized however that the approach I used in 0002 of passing
>> the original slot to ExecConstraints() fails in certain situations. For
>> example, if a BR trigger changes the tuple, the
Hi,
Attached patch fixes comment typos in condition_variable.c
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
fix_type_in_condition_variable_c.patch
Description: binary/octet-stream
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On 2017-01-15 19:29:52 -0800, Andres Freund wrote:
> On 2016-10-31 09:06:39 -0700, Andres Freund wrote:
> > On 2016-09-14 19:28:25 -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > > On 2016-09-12 19:35:22 -0400, Tom Lane wrote:
> > > Here's a draft patch that is just meant to investigate w
Hi,
while working on [1] (works, harmless regression check failures aside,
needs cleanup), I noticed $subject. Without fixing EXPR_KIND_VALUES to
set p_hasTargetSRFs the query has Query->hasTargetSRF wrongly set.
Which in turn breaks your planner code, as it's not being triggered
anymore.
Is the
75 matches
Mail list logo
