On Sat, Sep 14, 2019 at 10:10 AM Michael Paquier wrote:
>
> On Sat, Sep 14, 2019 at 09:25:31AM +0530, Amit Kapila wrote:
> > On Fri, Sep 13, 2019 at 5:31 PM Alvaro Herrera
> > wrote:
> >> A thought I had as I fell asleep last night is to include the derivate
> >> flags in a separate output
On Fri, Sep 13, 2019 at 6:36 PM Alvaro Herrera wrote:
>
> On 2019-Sep-13, Amit Kapila wrote:
>
> > I would like to take inputs from others as well for the display part
> > of this patch. After this patch, for a simple-update pgbench test,
> > the changed output will be as follows (note:
On Sat, Sep 14, 2019 at 09:25:31AM +0530, Amit Kapila wrote:
> On Fri, Sep 13, 2019 at 5:31 PM Alvaro Herrera
> wrote:
>> A thought I had as I fell asleep last night is to include the derivate
>> flags in a separate output column altogether. So
>> heap_tuple_infomask_flags() could be made to
On Sat, Sep 14, 2019 at 09:51:33AM +0530, Amit Kapila wrote:
> Yeah, but I think we should also try to see what we want to do about
> 'decode_combined' flag-related point, maybe we can adapt to what
> Alvaro has purposed?
Thanks, I'll keep note of this patch. I was just going to comment on
the
On Sat, Sep 14, 2019 at 01:06:32PM +0900, Tattsu Yama wrote:
> Thanks! I can review your patch for fix it.
> However, I was starting fixing the problem from the last day of PGConf.Asia
> (11 Sep).
> Attached file is WIP patch.In my patch, I added "command id" to all APIs of
> progress reporting to
Tomas Vondra writes:
> On Wed, Aug 14, 2019 at 05:24:26PM +1200, Thomas Munro wrote:
>> On Wed, Aug 14, 2019 at 5:06 PM Tom Lane wrote:
>>> Oh, hmm --- yeah, that should mean it's safe. Maybe somebody incautiously
>>> changed one of the other tests that run concurrently with "rules"?
>> Looks
On Fri, Sep 13, 2019 at 10:42 AM Michael Paquier wrote:
>
> On Fri, Sep 13, 2019 at 09:59:40AM +0530, Amit Kapila wrote:
> > I think that is what we have not done in one of the cases pointed by me.
>
> Thinking more about it, I see your point now. HEAP_LOCKED_UPGRADED is
> not a direct
On Fri, Sep 13, 2019 at 01:47:03PM -0400, James Coleman wrote:
> So I've attached a patch to summarize more correctly as well as
> document clearly the state of the cluster after the operation and also
> the operation sequencing dangers caused by copying configuration
> files from the source.
+
Hi Alvaro!
> Hello Tatsuro,
> On 2019-Aug-13, Tatsuro Yamada wrote:
> > On 2019/08/02 3:43, Alvaro Herrera wrote:
> > > Hmm, I'm trying this out now and I don't see the index_rebuild_count
> > > ever go up. I think it's because the indexes are built using parallel
> > > index build ... or
On Fri, Sep 13, 2019 at 5:31 PM Alvaro Herrera wrote:
>
> On 2019-Sep-13, Michael Paquier wrote:
>
> > Attached is a patch to fix your suggestions. This also removes the
> > use of HEAP_XMAX_IS_LOCKED_ONLY which did not make completely sense
> > either as a "raw" flag. While on it, the order of
On Fri, Sep 13, 2019 at 12:48:40PM -0400, Robert Haas wrote:
> On Fri, Sep 13, 2019 at 12:03 PM Alvaro Herrera
> wrote:
>> Ummm ... I've been operating --in this thread-- under the assumption
>> that it is REINDEX to blame for this problem, not CREATE INDEX, because
>> my recollection is that I
On Fri, Sep 13, 2019 at 11:09:52AM -0400, Tom Lane wrote:
> I think that's a useful function, but it's a different function from
> the one first proposed, which was to tell you the properties of a
> collation you already installed (which might not be ICU, even).
> Perhaps we should have both.
On 2019-09-10 12:05:25 +0900, Michael Paquier wrote:
> On Mon, Sep 09, 2019 at 05:27:04AM -0700, Andres Freund wrote:
> > On 2019-09-09 20:57:46 +0900, Michael Paquier wrote:
> > But ISTM all of them ought to just use the C types, rather than the SQL
> > types however. Since in the above proposal
Hi,
On 2019-09-13 16:42:47 -0300, Alvaro Herrera wrote:
> On 2019-Sep-10, Alvaro Herrera from 2ndQuadrant wrote:
>
> > Here's a couple of patches.
> >
> > always_decode_assignment.patch is Masahiko Sawada's patch, which has
> > been confirmed to fix the assertion failure.
>
> I pushed this one
On 2019-Jun-28, Peter Eisentraut wrote:
> Here is a new patch after the discussion.
>
> - Rename allow_system_table_mods to allow_system_table_ddl.
>
> (This makes room for a new allow_system_table_dml, but it's not
> implemented here.)
>
> - Make allow_system_table_ddl SUSET.
>
> - Add
On 2019-Aug-06, Alexander Korotkov wrote:
> Revised patch is attached. Changes to \dA+ command are reverted. It
> also contains some minor improvements.
>
> Second patch looks problematic for me, because it provides index
> description alternative to \d+. IMHO, if there is something really
>
On 2019-Sep-13, Nikolay Shaplov wrote:
> I've played with it around, and did some googling, but without much success.
> If we are moving this way (an this way seems to be good one), I need you
> help,
> because this thing is beyond my C knowledge, I will not manage it myself.
Well, you need to
On 2019-Aug-22, Juan José Santamaría Flecha wrote:
> On Sun, Aug 18, 2019 at 10:42 AM Juan José Santamaría Flecha
> wrote:
> >
> > Going through the current items in the wiki's todo list, I have been
> > looking into: "Allow to_date () and to_timestamp () to accept
> > localized month names".
>
> On Thu, Sep 12, 2019 at 3:58 AM Alvaro Herrera
> wrote:
> Can you please send an updated version?
Sure, I'll send it in a few days.
On 2019-Sep-13, Robert Haas wrote:
> On Fri, Sep 13, 2019 at 2:49 AM Michael Paquier wrote:
> > On Fri, Sep 06, 2019 at 08:10:58AM -0400, Robert Haas wrote:
> > > It's fine if things are updated as well -- it's just you need to make
> > > sure that those places know whether or not they are
Martijn van Oosterhout writes:
> Here is the rebased second patch.
This throws multiple compiler warnings for me:
async.c: In function 'asyncQueueUnregister':
async.c:1293: warning: unused variable 'advanceTail'
async.c: In function 'asyncQueueAdvanceTail':
async.c:2153: warning:
Dne pá 13. 9. 2019 16:43 uživatel Tom Lane napsal:
> It struck me that the real reason that we keep getting gripes about
> the weird behavior of CHAR(n) is that these functions (and, hence,
> their corresponding operators) fail to obey the "trailing blanks
> aren't significant" rule:
>
>
On 2019-Sep-10, Alvaro Herrera from 2ndQuadrant wrote:
> Here's a couple of patches.
>
> always_decode_assignment.patch is Masahiko Sawada's patch, which has
> been confirmed to fix the assertion failure.
I pushed this one to all branches. Thanks Ildar for reporting and
Sawada-san for fixing,
On Thu, Sep 12, 2019 at 4:55 PM Alexander Korotkov
wrote:
> On Wed, Sep 11, 2019 at 3:30 PM Amit Kapila wrote:
> > On Sun, Sep 1, 2019 at 1:37 PM Alexander Korotkov
> > wrote:
> > > I found it weird that CLUSTER/VACUUM FULL don't write visibility map.
> > > Attached patch implements writing
Hello,
I noticed the tests for range types do this:
create table numrange_test2(nr numrange);
create index numrange_test2_hash_idx on numrange_test2 (nr);
Does that need a `using hash`? It seems like that's the intention. We
only use that table for equality comparisions. The script already
On Sat, Aug 31, 2019 at 10:51 PM Amit Kapila wrote:
>
> On Fri, Jul 26, 2019 at 1:45 AM James Coleman wrote:
> >
> > We've discussed this internally many times, but today finally decided
> > to write up a doc patch.
> >
>
> Thanks, I think something on the lines of what you have written can
>
The pg_rewind docs assert that the state of the target's data directory
after rewind is equivalent to the source's data directory. But that
isn't true both because the base state is further back in time and
because the target's data directory will include the current state on
the source of any
Hello Tatsuro,
On 2019-Aug-13, Tatsuro Yamada wrote:
> On 2019/08/02 3:43, Alvaro Herrera wrote:
> > Hmm, I'm trying this out now and I don't see the index_rebuild_count
> > ever go up. I think it's because the indexes are built using parallel
> > index build ... or maybe it was the table AM
Hello Alvaro,
I think the TestLib.pm changes should be done separately, not together
with the rest of the hacking in this patch.
Mostly, because I think they're going to cause trouble. Adding a
parameter in the middle of the list may cause trouble for third-party
users of TestLib.
That is
Hello Amit,
+ res = PQexec(con,
+ "select p.partstrat, count(*) "
+ "from pg_catalog.pg_class as c "
+ "left join pg_catalog.pg_partitioned_table as p on (p.partrelid = c.oid) "
+ "left join pg_catalog.pg_inherits as i on (c.oid = i.inhparent) "
+ "where c.relname = 'pgbench_accounts' "
+
On Fri, Sep 13, 2019 at 5:23 PM Nikita Glukhov wrote:
> I have moved handling of NULL ordering keys from opclasses to the common
> SP-GiST code, but really I don't like how it is implemented now. Maybe it's
> worth to move handling of NULL order-by keys to the even more higher
> level so,
> that
On Mon, Sep 9, 2019 at 4:51 PM Jeevan Chalke
wrote:
>
>
>
> On Tue, Aug 27, 2019 at 4:46 PM vignesh C wrote:
>>
>> Few comments:
>> Comment:
>> + buf = (char *) malloc(statbuf->st_size);
>> + if (buf == NULL)
>> + ereport(ERROR,
>> + (errcode(ERRCODE_OUT_OF_MEMORY),
>> + errmsg("out of
On Fri, Sep 13, 2019 at 11:12 AM Tom Lane wrote:
> That argument presupposes (a) manual execution of the creation query,
> and (b) that the user pays close attention to the NOTICE output.
> Unfortunately, I think our past over-use of notices has trained
> people to ignore them.
Our past overuse
On Fri, Sep 13, 2019 at 12:03 PM Alvaro Herrera
wrote:
> Ummm ... I've been operating --in this thread-- under the assumption
> that it is REINDEX to blame for this problem, not CREATE INDEX, because
> my recollection is that I tested CREATE INDEX together with CLUSTER and
> it worked fine. Has
On Fri, Sep 13, 2019 at 12:14 PM Tom Lane wrote:
> Amit Khandekar writes:
> > You mean tracking excess kernel fds right ? Yeah, we can use VFDs so
> > that excess fds are automatically closed. But Alvaro seems to be
> > talking in context of tracking of file seek position. VFD does not
> > have
On 2019-Aug-20, Peter Eisentraut wrote:
> The memory management of that seems too complicated. The "extra"
> mechanism of the check/assign hooks only supports one level of malloc.
> Using a List seems impossible. I don't know if you can safely do a
> malloc-ed array of malloc-ed strings either.
Amit Khandekar writes:
> You mean tracking excess kernel fds right ? Yeah, we can use VFDs so
> that excess fds are automatically closed. But Alvaro seems to be
> talking in context of tracking of file seek position. VFD does not
> have a mechanism to track file offsets if one of the vfd cached
On Thu, 12 Sep 2019 at 19:11, Robert Haas wrote:
>
> On Thu, Sep 12, 2019 at 5:31 AM Tomas Vondra
> wrote:
> > I don't see how the current API could do that transparently - it does
> > track the files, but the user only gets a file descriptor. With just a
> > file descriptor, how could the code
On Fri, Sep 13, 2019 at 10:54 AM Tomas Vondra
wrote:
>
> On Thu, Sep 12, 2019 at 11:54:06AM -0400, James Coleman wrote:
> >> OK, so we have that now. I suppose this spreadsheet now tells us which
> >> places are useful and which aren't, at least for the queries that you've
> >> tested. Dowe
"Daniel Verite" writes:
> This output tend to reveal mistakes with tags, which is why I thought
> to expose it as a NOTICE. It addresses the case of a user
> who wouldn't suspect an error, so the "in-your-face" effect is
> intentional. With the function approach, the user must be
> proactive.
Robert Haas writes:
> On Fri, Sep 13, 2019 at 9:57 AM Daniel Verite wrote:
>> An advantage of this approach is that you may execute the
>> function before creating the collation, instead of creating the
>> collation, realizing there was something wrong in your
>> locale/lc_collate argument,
On Thu, Sep 12, 2019 at 11:54:06AM -0400, James Coleman wrote:
OK, so we have that now. I suppose this spreadsheet now tells us which
places are useful and which aren't, at least for the queries that you've
tested. Dowe that mean that we want to get the patch to consider adding
paths only the
On Fri, Sep 13, 2019 at 9:57 AM Daniel Verite wrote:
> An advantage of this approach is that you may execute the
> function before creating the collation, instead of creating the
> collation, realizing there was something wrong in your
> locale/lc_collate argument, dropping the collation and
On Thu, Sep 12, 2019 at 12:49:29PM -0300, Alvaro Herrera wrote:
On 2019-Jul-30, Tomas Vondra wrote:
On Sun, Jul 21, 2019 at 01:34:22PM +0200, Tomas Vondra wrote:
>
> I wonder if we're approaching this wrong. Maybe we should not reverse
> engineer queries for the various places, but just start
It struck me that the real reason that we keep getting gripes about
the weird behavior of CHAR(n) is that these functions (and, hence,
their corresponding operators) fail to obey the "trailing blanks
aren't significant" rule:
regprocedure|prosrc
On 12.09.2019 16:45, Alexander Korotkov wrote:
On Wed, Sep 11, 2019 at 3:34 AM Nikita Glukhov wrote:
On 09.09.2019 22:47, Alexander Korotkov wrote:
On Mon, Sep 9, 2019 at 8:32 PM Nikita Glukhov wrote:
On 08.09.2019 22:32, Alexander Korotkov wrote:
On Fri, Sep 6, 2019 at 5:44 PM Alexander
Michael Paquier wrote:
> Or could it make sense to provide a system function which returns a
> collation description for at least an ICU-provided one? We could make
> use of that in psql for example.
If we prefer having a function over the instant feedback effect of
the NOTICE, the
On Fri, Sep 13, 2019 at 9:51 PM Alvaro Herrera wrote:
>
> On 2019-Sep-13, Fujii Masao wrote:
>
> > On Mon, Sep 9, 2019 at 3:52 PM Jamison, Kirk
> > wrote:
>
> > > > Please add a preliminary patch that removes the function. Dead code is
> > > > good,
> > > > as long as it is gone. We can get
Implemented the Logical Streaming Replication thing are working fine I see
the XLogData message appearing and I'm able to parse them.
But I haven't see any "Primary Keepalive message" yet. I had tried setting
the *tcp_keepalive_interval*, *tcp_keepalives_idle* both from client
runtime paramter
On 2019-Sep-13, Amit Kapila wrote:
> I would like to take inputs from others as well for the display part
> of this patch. After this patch, for a simple-update pgbench test,
> the changed output will be as follows (note: partition method and
> partitions):
> pgbench.exe -c 4 -j 4 -T 10 -N
On 2019-Sep-13, Amit Kapila wrote:
> On Fri, Sep 13, 2019 at 1:50 PM Fabien COELHO wrote:
> > >>> Is there a reason why we treat "partitions = 0" as a valid value?
> > >>
> > >> Yes. It is an explicit "do not create partitioned tables", which differ
> > >> from 1 which says "create a
On 2019-Sep-13, Fujii Masao wrote:
> On Mon, Sep 9, 2019 at 3:52 PM Jamison, Kirk wrote:
> > > Please add a preliminary patch that removes the function. Dead code is
> > > good,
> > > as long as it is gone. We can get it pushed ahead of the rest of this.
> >
> > Alright. I've attached a
On 2019-Sep-13, Fabien COELHO wrote:
> Hello Alvaro,
>
> > I think the TestLib.pm changes should be done separately, not together
> > with the rest of the hacking in this patch.
> >
> > Mostly, because I think they're going to cause trouble. Adding a
> > parameter in the middle of the list may
On Mon, Sep 9, 2019 at 3:52 PM Jamison, Kirk wrote:
>
> On Friday, September 6, 2019 11:51 PM (GMT+9), Alvaro Herrera wrote:
>
> Hi Alvaro,
> Thank you very much for the review!
>
> > On 2019-Sep-05, Jamison, Kirk wrote:
> >
> > > I also mentioned it from my first post if we can just remove this
On Thu, Sep 12, 2019 at 5:19 PM Tom Lane wrote:
> However, if there is some character C that makes ICU misbehave like
> that, we are going to have problems with indexing strings containing C,
> whether we think varstr_cmp is leaky or not. So I'm not sure that
> focusing our attention on
On Fri, Sep 13, 2019 at 2:49 AM Michael Paquier wrote:
> On Fri, Sep 06, 2019 at 08:10:58AM -0400, Robert Haas wrote:
> > It's fine if things are updated as well -- it's just you need to make
> > sure that those places know whether or not they are supposed to be
> > doing those updates. Again,
On Thu, Sep 5, 2019 at 5:53 PM Jamison, Kirk wrote:
>
> On Tuesday, September 3, 2019 9:44 PM (GMT+9), Fujii Masao wrote:
> > Thanks for the patch!
>
> Thank you as well for the review!
>
> > -smgrdounlinkfork(SMgrRelation reln, ForkNumber forknum, bool isRedo)
> > +smgrdounlinkfork(SMgrRelation
On 2019-Sep-13, Michael Paquier wrote:
> Attached is a patch to fix your suggestions. This also removes the
> use of HEAP_XMAX_IS_LOCKED_ONLY which did not make completely sense
> either as a "raw" flag. While on it, the order of the flags can be
> improved to match more the order of
On Mon, 9 Sep 2019 at 16:06, Amit Khandekar wrote:
>
> On Tue, 3 Sep 2019 at 23:10, Alvaro Herrera wrote:
> >
> > On 2019-Jul-19, Amit Khandekar wrote:
> >
> > > Attached are the split patches. Included is an additional patch that
> > > has doc changes. Here is what I have added in the docs.
On Fri, Sep 13, 2019 at 1:50 PM Fabien COELHO wrote:
> >>> Is there a reason why we treat "partitions = 0" as a valid value?
> >>
> >> Yes. It is an explicit "do not create partitioned tables", which differ
> >> from 1 which says "create a partitionned table with just one partition".
> >
> > Why
Hi
I testing very simple function
create or replace function f1(int) returns int as $$ declare i int = 0;
begin while i < $1 loop i = i + 1; end loop; return i; end $$ language
plpgsql immutable;
profile - when function is marked as immutable
8,65% postgres[.] ExecInterpExpr
On Tue, Sep 3, 2019 at 11:04 PM Fujii Masao wrote:
>
> On Thu, Aug 22, 2019 at 3:06 PM Wang, Shenhao
> wrote:
> >
> > Hello, hackers:
> >
> > I created a patch about tab completion for command CREATE OR REPLACE in psql
> > includes:
> > CREATE [ OR REPLACE ] FUNCTION
> > CREATE [
On Fri, Sep 13, 2019 at 2:05 PM Fabien COELHO wrote:
>
>
> Hello Dilip,
>
> > + /* For RANGE, we use open-ended partitions at the beginning and end */
> > + if (p == 1)
> > + sprintf(minvalue, "minvalue");
> > + else
> > + sprintf(minvalue, INT64_FORMAT, (p-1) * part_size + 1);
> > +
> > + if (p
On 13.09.2019 10:16, Pavel Stehule wrote:
pá 13. 9. 2019 v 9:09 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 24.08.2019 19:13, Pavel Stehule wrote:
so 24. 8. 2019 v 18:01 odesílatel David Fetter mailto:da...@fetter.org>> napsal:
On
Hello Dilip,
+ /* For RANGE, we use open-ended partitions at the beginning and end */
+ if (p == 1)
+ sprintf(minvalue, "minvalue");
+ else
+ sprintf(minvalue, INT64_FORMAT, (p-1) * part_size + 1);
+
+ if (p < partitions)
+ sprintf(maxvalue, INT64_FORMAT, p * part_size + 1);
+ else
+
On Fri, Sep 13, 2019 at 10:16:30AM +0300, Nikolay Shaplov wrote:
> I also attached a diff of what I have done to get these warnings. It should
> be
> applied to latest version of patch we are discussing.
If you do that I think that the CF bot is not going to appreciate and
will result in
On Fri, Sep 13, 2019 at 1:35 PM Fabien COELHO wrote:
Thanks for the updated version of the patch.
> > Generally, we give one blank line between the variable declaration and
> > the first statement of the block.
>
> Ok.
>
> > (p-1) -> (p - 1)
>
> Ok.
>
> > I am just wondering will it be a good
Hello Amit,
Is there a reason why we treat "partitions = 0" as a valid value?
Yes. It is an explicit "do not create partitioned tables", which differ
from 1 which says "create a partitionned table with just one partition".
Why would anyone want to use --partitions option in the first case
pá 13. 9. 2019 v 9:35 odesílatel Pavel Stehule
napsal:
>
>
> čt 12. 9. 2019 v 0:01 odesílatel Alvaro Herrera from 2ndQuadrant <
> alvhe...@alvh.no-ip.org> napsal:
>
>> On 2019-Jul-31, Rafia Sabih wrote:
>>
>> > I had a look at this patch, seems like a useful thing to have.
>>
>> So the two
Hello Dilip,
Generally, we give one blank line between the variable declaration and
the first statement of the block.
Ok.
(p-1) -> (p - 1)
Ok.
I am just wondering will it be a good idea to expand it to support
multi-level partitioning?
ISTM that how the user could specify multi-level
čt 12. 9. 2019 v 0:01 odesílatel Alvaro Herrera from 2ndQuadrant <
alvhe...@alvh.no-ip.org> napsal:
> On 2019-Jul-31, Rafia Sabih wrote:
>
> > I had a look at this patch, seems like a useful thing to have.
>
> So the two initial questions for this patch are
>
> 1. Is this a feature we want?
> 2.
pá 13. 9. 2019 v 9:09 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 24.08.2019 19:13, Pavel Stehule wrote:
>
>
>
> so 24. 8. 2019 v 18:01 odesílatel David Fetter napsal:
>
>> On Fri, Aug 23, 2019 at 11:10:28AM +0200, Pavel Stehule wrote:
>> > pá 23. 8. 2019 v 11:05
В письме от четверг, 5 сентября 2019 г. 11:42:27 MSK пользователь Alvaro
Herrera from 2ndQuadrant написал:
> After looking closer once again, I don't like this patch.
>
> I think the FOOBAR_ENUM_DEF defines serve no purpose, other than
> source-code placement next to the enum value definitions.
On Wed, Sep 11, 2019 at 6:08 PM Fabien COELHO wrote:
>
>
I would like to take inputs from others as well for the display part
of this patch. After this patch, for a simple-update pgbench test,
the changed output will be as follows (note: partition method and
partitions):
pgbench.exe -c 4 -j 4
Dear all
While developing MobilityDB we needed to extend the range type operators so
they cope with elements. In the same way that currently the range types
support both
- @> contains range/element
- <@ element/range is contained by
we extended the left (<<), overleft (&<), right (>>), and
On Fri, Sep 06, 2019 at 08:10:58AM -0400, Robert Haas wrote:
> It's fine if things are updated as well -- it's just you need to make
> sure that those places know whether or not they are supposed to be
> doing those updates. Again, why can't we just pass down a value
> telling them "do
Hi Tom, Thank you for quick reply. > I'm quite certain that the current behavior is intentional, if only> because closing the syslogger's stderr would make it impossible to> debug problems inside the syslogger.Developer who debugs syslogger, probably, can remove fclose() calls.Maybe we can have a
On Sun, Sep 08, 2019 at 05:54:12PM -0400, Andrew Dunstan wrote:
> I'm going to disable this test (src/test/recovery/t/017_shm.pl) on
> Windows on the back branches too unless there's a violent objection. The
> reason is that the script runs "postgres --single" and that fails on
> Windows when run
78 matches
Mail list logo
