On Mon, Oct 30, 2017 at 8:57 PM, Kyotaro HORIGUCHI
wrote:
> At Thu, 26 Oct 2017 15:06:30 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20171026.150630.115694437.horiguchi.kyot...@lab.ntt.co.jp>
>> At Fri, 20 Oct 2017 19:15:16 +0900, Masahiko Sawada
>> wrote in
>> > > n_mod_s
Hello David,
Thank you for reviewing.
On Wed, Nov 15, 2017 at 4:43 AM, David Rowley
wrote:
> On 15 November 2017 at 01:57, David Rowley
> wrote:
>> I think to do this you're going to have to store some sort of array
>> that maps the partition index to the subpath in the Append node so you
>> c
Hello Rajkumar,
On Tue, Nov 14, 2017 at 2:22 PM, Rajkumar Raghuwanshi
wrote:
> On Tue, Nov 14, 2017 at 11:46 AM, Beena Emerson
> wrote:
>>
>> PFA the updated patches.
>
>
> Hi,
>
> I have started testing this along with fast pruning. It is crashing for sql
> with subqueries.
> one to test case i
I initially assumed that as well, but I found some somewhat confusing
documentation about implementing this as a plain GiST tree. Mostly, the
BK-Tree is a inherently unbalanced tree, and some of the documentation for
plain GiST indexes claims that GiST indexes can only be created on balanced
tree s
Hello Steve,
Here is the hopefully right version, which passes tests here.
This version seems fine.
I think it is ready for a committer
Ok, thanks for the debug!
--
Fabien.
On Wed, Nov 15, 2017 at 12:12 PM, Masahiko Sawada wrote:
> I think we need to check only sessionBackupState and don't need to
> check XLogCtl->Insert.exclusiveBackupState in do_pg_abort_backup(). We
> can quickly return if sessionBackupState !=
> SESSION_BACKUP_NON_EXCLUSIVE. In your suggestion, I
On Mon, 13 Nov 2017, Fabien COELHO wrote:
Hello Steve,
printf("number of transactions actually processed: "
INT64_FORMAT "/%d\n",
- total->cnt - total->skipped, nxacts * nclients);
+ total->cnt, nxacts * nclients);
I think you
On Wed, Nov 15, 2017 at 10:05 AM, Michael Paquier
wrote:
> On Wed, Nov 15, 2017 at 9:06 AM, Masahiko Sawada
> wrote:
>>> On Nov 15, 2017 2:59 AM, "Fujii Masao" wrote:
>>> + /* Quick exit if we have done the backup */
>>> + if (XLogCtl->Insert.exclusiveBackupState == EXCLUSIVE_BACKUP_NONE)
>>> +
Hi David.
On 2017/11/14 13:00, David Rowley wrote:
> On 13 November 2017 at 22:46, Amit Langote wrote:
>> On 2017/11/10 12:30, Kyotaro HORIGUCHI wrote:
>>> The following uses a bit tricky bitmap operation but
>>> is straightforward as a whole.
>>>
>>> =
>>> /* fill the bits upper from BITNUM(l
On Wed, Nov 15, 2017 at 9:06 AM, Masahiko Sawada wrote:
>> On Nov 15, 2017 2:59 AM, "Fujii Masao" wrote:
>> + /* Quick exit if we have done the backup */
>> + if (XLogCtl->Insert.exclusiveBackupState == EXCLUSIVE_BACKUP_NONE)
>> + return;
>>
>> This quick exit seems to cause another problem. Plea
On 2017/11/15 2:09, Alvaro Herrera wrote:
> Amit Langote wrote:
>
>> Since that 0001 patch was committed [1], here is the rebased patch. Will
>> add this to the November commit-fest.
>
> Please rebase once more -- 1aba8e651ac3 seems to have broken things
> in this area pretty thoroughly.
Thanks
On 2017/11/15 8:13, David Rowley wrote:
> So some sort of hierarchical structure of the partition hierarchy
> would need to be stored in the Append node and then you'd need to
> search at each level, and then somehow match the results up to the
> subpaths that you have in the Append. Although, I'm
Thank you for the reviewing!
On Nov 15, 2017 2:59 AM, "Fujii Masao" wrote:
On Fri, Sep 22, 2017 at 4:42 PM, Masahiko Sawada
wrote:
> On Fri, Sep 22, 2017 at 3:46 PM, Michael Paquier
> wrote:
>> On Fri, Sep 22, 2017 at 3:24 PM, Masahiko Sawada
wrote:
>>> I have a question. Since WALInsertLockR
On 10/31/17 15:38, Peter Eisentraut wrote:
> Here is a patch that implements transaction control in PL/Python
> procedures. (This patch goes on top of "SQL procedures" patch v1.)
Here is an updated patch, now on top of "SQL procedures" v2.
Relative to the previous patch v1 I added transaction co
On 11/14/17 16:33, Merlin Moncure wrote:
>> One detail in your example is that when you enter the procedure, you are
>> already in a transaction, so you would have to run either COMMIT or
>> ROLLBACK before the START TRANSACTION.
>
> Ok, that's good, but it seems a little wonky to me to have to is
will that kind of statement (that is permitted with Oracle but gives errors
ora-1555 snapshot too old) be permitted ?
begin
for c in (select id from tab where cond='blabla')
loop
update tab set x=1 where id=c.id;
commit;
end loop;
end;
--
Sent from: http://www.postgresql-archive.o
Peter Eisentraut writes:
> On 11/14/17 11:14, Tom Lane wrote:
>> ... Do we really want the existence of
>> a function foo(int) to mean that you can't create a SQL procedure named
>> foo and taking one int argument?
> Yes, that is defined that way by the SQL standard.
Meh. OK, then it has to be
On 15 November 2017 at 01:57, David Rowley wrote:
> I think to do this you're going to have to store some sort of array
> that maps the partition index to the subpath in the Append node so you
> can correctly identify the subpath based on what you're getting back
> from get_partitions_for_keys().
Hi hackers,
EXPLAIN can show per-worker information and aggregated information,
but doesn't show the leader's information individually. Should it?
Example:
Partial Aggregate [...]
Output: PARTIAL count(*)
Buffers: shared hit=476
Worker 0: actual time=5.110..5.110 rows=1 loops=1
On Wed, Nov 15, 2017 at 7:28 AM, Ashwin Agrawal wrote:
>
> https://commitfest.postgresql.org/15/1297/
>
> Am I missing something or not looking at right place, this is marked as
> committed but don't see the change in latest master ?
Good thing you double-checked. This has been marked as committe
On 11/14/17 11:14, Tom Lane wrote:
>> The common functionality between functions and procedures is like 98%
>> [citation needed], so they definitely belong there, even more so than
>> aggregates, for example.
> No, I don't think so. The core reason why not is that in
>
> SELECT foo(...) FRO
https://commitfest.postgresql.org/15/1297/
Am I missing something or not looking at right place, this is marked as
committed but don't see the change in latest master ?
On 15 November 2017 at 04:23, Alvaro Herrera wrote:
> David Rowley wrote:
>> I'd have thought some sort of: ALTER INDEX name_of_partitioned_index
>> REPLACE INDEX FOR partitioned_tablename WITH
>> name_of_new_matching_bloat_free_index;
>>
>> ... or something along those lines, and just have an ato
Hi Jesper,
Thanks for reviewing.
Jesper Pedersen wrote:
> I have been looking at the "CREATE INDEX ... ONLY" syntax, and I think it
> could cause some confusion due to the "Note" described in create_index.sgml.
>
> An alternative, maybe crazy, could be to treat a partitioned index as one;
> e.g
On Tue, Nov 14, 2017 at 12:09 PM, Peter Eisentraut
wrote:
> On 11/14/17 09:27, Merlin Moncure wrote:
>> *) Will it be possible to do operations like this in pl/pgsql?
>>
>> BEGIN
>> SELECT INTO r * FROM foo;
>>
>> START TRANSACTION; -- perhaps we ought to have a special function
>> for this i
> On 13 November 2017 at 14:11, Arthur Zakirov
wrote:
> > I have a little complain about how ExprEvalStep gets resvalue. resvalue
is
> > assigned in one place (within ExecEvalSubscriptingRefFetch(),
> > ExecEvalSubscriptingRefAssign()), resnull is assigned in another place
> > (within jsonb_subscr
Hi,
On 2017-11-14 01:30:30 +1300, Thomas Munro wrote:
> > +-- The "good" case: batches required, but we plan the right number; we
> > +-- plan for 16 batches, and we stick to that number, and peak memory
> > +-- usage says within our work_mem budget
> > +-- non-parallel
> > +set max_parallel_worke
On Tue, Nov 14, 2017 at 1:43 PM, Simon Riggs wrote:
> I don't see any comments from you or Tom about patch 0001, which was
> simple refactoring and not much to complain about.
We both commented that getting rid of copy_partition_data could
introduce memory leaks.
> Perhaps there is some confusio
Ok Stephen, thanks for the clarification.
On Tue, Nov 14, 2017 at 2:27 PM, Stephen Frost wrote:
> Greetings,
>
> * Ryan Murphy (ryanfmur...@gmail.com) wrote:
> > Sorry, this is off topic, but since we've switched the mailing list to
> > PGLister my inbox is getting every single message as a sepa
Greetings,
* Ryan Murphy (ryanfmur...@gmail.com) wrote:
> Sorry, this is off topic, but since we've switched the mailing list to
> PGLister my inbox is getting every single message as a separate email. I
> used to get a digest once a day. Is there a way for me to change my
> subscription setting
Sorry, this is off topic, but since we've switched the mailing list to
PGLister my inbox is getting every single message as a separate email. I
used to get a digest once a day. Is there a way for me to change my
subscription settings to something like that?
Best,
Ryan
On Tue, Nov 14, 2017 at 11:02 AM, Simon Riggs wrote:
> That's a good place to leave this for now - we're OK to make progress
> with the main feature, and we have some questions to be addressed once
> we have a cake to decorate.
>
> Thanks for your input.
Thanks for listening. I regret that it bec
Hi,
On 11/14/2017 12:49 PM, Alvaro Herrera wrote:
Thanks, pushed.
Here's the remaining bits, rebased.
First of all, thanks for working on this.
I have been looking at the "CREATE INDEX ... ONLY" syntax, and I think
it could cause some confusion due to the "Note" described in
create_index
On 6 November 2017 at 16:50, Peter Geoghegan wrote:
>> Where hides the problem?
>
>
> The problem is violating MVCC is something that can be done in different
> ways, and by meaningful degrees:
>
> * EPQ semantics are believed to be fine because we don't get complaints
> about it. I think that t
On Tue, Nov 14, 2017 at 11:00 AM, Tom Lane wrote:
> Yeah, I'm sure it is. I have a vague recollection that there might be
> existing regression test cases exercising such things, though I won't
> swear to that. The "orderstest" bit in subselect.sql looks like it
> might be meant to do that...
H
On 14 November 2017 at 12:56, Daniel Verite wrote:
> Tom Lane wrote:
>
>> Do we really want the existence of a function foo(int) to mean
>> that you can't create a SQL procedure named
>> foo and taking one int argument?
>
> Isn't it pretty much implied by the
> ALTER | DROP ROUTINE foo(...
On 14 November 2017 at 13:12, Robert Haas wrote:
> On Tue, Nov 14, 2017 at 12:49 PM, Alvaro Herrera
> wrote:
>> Here's the remaining bits, rebased.
>
> It's true that Tom and I reviewed patch 0001, as your proposed commit
> message states. But it's also true that we both said that it probably
>
On Tue, Nov 14, 2017 at 12:49 PM, Alvaro Herrera
wrote:
> Here's the remaining bits, rebased.
It's true that Tom and I reviewed patch 0001, as your proposed commit
message states. But it's also true that we both said that it probably
wasn't a good idea.
--
Robert Haas
EnterpriseDB: http://www.
On 11/14/17 09:27, Merlin Moncure wrote:
> *) Will it be possible to do operations like this in pl/pgsql?
>
> BEGIN
> SELECT INTO r * FROM foo;
>
> START TRANSACTION; -- perhaps we ought to have a special function
> for this instead (BEGIN is reserved, etc).
> SET transaction_isololation T
On Tue, Nov 14, 2017 at 1:41 AM, Rushabh Lathia
wrote:
> Thanks Peter and Thomas for the review comments.
No problem. More feedback:
* I don't really see much need for this:
+ elog(LOG, "Worker for create index %d", parallel_workers);
You can just use trace_sort, and observe the actual behavio
On Fri, Sep 22, 2017 at 4:42 PM, Masahiko Sawada wrote:
> On Fri, Sep 22, 2017 at 3:46 PM, Michael Paquier
> wrote:
>> On Fri, Sep 22, 2017 at 3:24 PM, Masahiko Sawada
>> wrote:
>>> I have a question. Since WALInsertLockRelease seems not to call
>>> LWLockWaitForVar I thought you wanted to mean
Tom Lane wrote:
> Do we really want the existence of a function foo(int) to mean
> that you can't create a SQL procedure named
> foo and taking one int argument?
Isn't it pretty much implied by the
ALTER | DROP ROUTINE foo(...)
commands where foo(...) may be either a procedure
or a functi
On 11/13/2017 09:09 PM, Andrea Adami wrote:
> As suggested from Joe i changed the db definition as enclosed.
> Now when i do:
>
> select * fom schools
>
> all works fine
>
> but when i do:
[SELECT from VIEW]
> always i get the error:
>
> permission denied for relation schools
> SQL state:
Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On 13 November 2017 at 12:55, Alvaro Herrera
> > wrote:
> > > Somehow I managed to include an unrelated patch as attachment. Here's
> > > another attempt (on which I also lightly touched ddl.sgml with relevant
> > > changes).
> >
> > Looks good. So
Peter Moser writes:
> 2017-11-11 13:19 GMT+01:00 Robert Haas :
>> Overall, I think that the whole approach here probably needs to be
>> scrapped and rethought. The stuff this patch is doing really belongs
>> in the optimizer, not the parser, I think. It could possibly happen
>> at a relatively e
David Rowley wrote:
> 5. Triggers. Do we need a new "TG_" tag to allow trigger functions to
> do something special when the DELETE/INSERT is a partition move? I
> have audit tables in mind here it may appear as though a user
> performed a DELETE when they actually performed an UPDATE giving
> visi
Amit Langote wrote:
> Since that 0001 patch was committed [1], here is the rebased patch. Will
> add this to the November commit-fest.
Please rebase once more -- 1aba8e651ac3 seems to have broken things
in this area pretty thoroughly.
--
Álvaro Herrerahttps://www.2ndQuadrant.co
David Rowley wrote:
> But if you can DETACH a partition from requiring an index to back up
> this partitioned index, then the partitioned index is not valid while
> the leaf table's index is missing.
Yeah. I don't see this as too much of a problem myself. At present,
from the planner's POV each
On 09/12/2017 12:11 PM, Simon Riggs wrote:
>
>> OK, so table-level option for "toast_tuple_target", not attribute-level
>> option
>>
>> The attached patch and test shows this concept is useful and doesn't
>> affect existing data.
>>
>> For 4x 4000 byte rows:
>> * by default we use 1 heap block a
2017-11-14 17:18 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> Something that has been bothering me for a while, while we have neatly
> organized test files for plperl, plpython, pltcl, the plpgsql tests are
> all in one giant file in the main test suite, which makes developmen
2017-11-14 17:14 GMT+01:00 Tom Lane :
> Peter Eisentraut writes:
> > On 11/8/17 09:54, Tom Lane wrote:
> >> Do procedures of this ilk belong in pg_proc at all? It seems like a
> large
> >> fraction of the attributes tracked in pg_proc are senseless for this
> >> purpose. A new catalog might be
2017-11-11 13:19 GMT+01:00 Robert Haas :
> This is really good input. If the feature weren't useful, then it
> wouldn't make sense to try to figure out how to integrate it, but if
> it is, then we should try.
We are happy to hear this and will do the implementation. Any input
regarding the imple
2017-10-06 19:22 GMT+02:00 Paul A Jungwirth :
> I just wanted to chime in and say that the work these people have done
> is *amazing*. I read two of their papers yesterday [1, 2], and if you
> are interested in temporal data, I encourage you to read them too. The
> first one is only 12 pages and qu
Something that has been bothering me for a while, while we have neatly
organized test files for plperl, plpython, pltcl, the plpgsql tests are
all in one giant file in the main test suite, which makes development
and testing of plpgsql cumbersome. It is by far the largest test file
after numeric_b
Peter Eisentraut writes:
> On 11/8/17 09:54, Tom Lane wrote:
>> Do procedures of this ilk belong in pg_proc at all? It seems like a large
>> fraction of the attributes tracked in pg_proc are senseless for this
>> purpose. A new catalog might be a better approach.
> The common functionality betw
Robert Haas writes:
> On Tue, Nov 14, 2017 at 12:00 AM, Amit Kapila wrote:
>> Am I missing something? Do you have some test or shape of the plan in
>> mind which can cause a problem?
> The problem would happen if the plan for InitPlan $1 in the above
> example itself referenced a parameter from
On Tue, Nov 14, 2017 at 10:37 AM, Robert Haas wrote:
> The problem would happen if the plan for InitPlan $1 in the above
> example itself referenced a parameter from an upper query level, and
> the value of that parameter changed, and then this section of the plan
> tree was rescanned. I'm not su
Alexander Korotkov wrote:
> Patch rebased to current master is attached. I'm going to improve my testing
> script and post new results.
I wanted to review this patch but incremental-sort-8.patch fails to apply. Can
you please rebase it again?
--
Antonin Houska
Cybertec Schönig & Schönig GmbH
On 11/8/17 09:54, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 10/31/17 14:23, Tom Lane wrote:
>>> Why not use VOIDOID for the prorettype value?
>
>> We need a way to distinguish functions that are callable by SELECT and
>> procedures that are callable by CALL.
>
> Do procedures of this ilk
On Tue, Nov 14, 2017 at 12:00 AM, Amit Kapila wrote:
> I think this would have been a matter of concern if we use initplans
> below Gather/Gather Merge. The patch uses initplans which are between
> current query level and root. So, I think we don't need to reevaluate
> such parameters. Let us t
On Sun, Sep 10, 2017 at 5:29 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> average latency:
>
> clients patch master
> 10 0.321 0.286
> 20 0.669 0.602
> 30 1.016 0.942
> 40 1.358 1.280
> 50 1.727 1.637
That's
On 11/8/17 12:15, Merlin Moncure wrote:
> On Wed, Nov 8, 2017 at 11:03 AM, Peter Eisentraut
> wrote:
>> On 11/8/17 11:11, Merlin Moncure wrote:
>>> On Wed, Nov 8, 2017 at 9:13 AM, Peter Eisentraut
>>> wrote:
I have already submitted a separate patch that addresses these questions.
>>>
>>> Ma
Simon Riggs wrote:
> On 13 November 2017 at 12:55, Alvaro Herrera wrote:
> > Somehow I managed to include an unrelated patch as attachment. Here's
> > another attempt (on which I also lightly touched ddl.sgml with relevant
> > changes).
>
> Looks good. Some minor comments below.
>
> 0001- Simpl
On Wed, Nov 8, 2017 at 5:48 PM, Simon Riggs wrote:
> On 31 October 2017 at 15:38, Peter Eisentraut
> wrote:
>> Here is a patch that implements transaction control in PL/Python
>> procedures. (This patch goes on top of "SQL procedures" patch v1.)
>
> The patch is incredibly short for such a featu
Hello, Magnus.
You wrote:
MH> On Tue, Nov 14, 2017 at 9:58 AM, Pavel Golub wrote:
MH> Hello, Tom.
MH> You wrote:
TL>> Geoff Winkless writes:
>>> The removal of the [HACKERS] (etc) header will be frustrating for me: I do
>>> not sort mailing lists into folders (I simply scan the "Forums" a
On Tue, Nov 14, 2017 at 4:12 PM, Alvaro Herrera wrote:
> Hmm. Am I reading it right that this discussion led to moving
> essentially all code from tqual.c to heapam? Given the hard time we've
> had to get tqual.c right, it seems fundamentally misguided to me to
> require that every single storag
On 14 November 2017 at 19:16, Beena Emerson wrote:
> PFA the updated patches.
Hi Beena,
Thanks for working on this. I've had a look at the patch to try to
understand how it is working. I found it a bit surprising that the
code assumes it can rely on the order of Append->appendplans matching
what
On 15 November 2017 at 01:30, Alvaro Herrera wrote:
> David Rowley wrote:
>> hmm, but surely the all those indexes must already exist if the
>> partitioned index exists. Won't we be disallowing DROP INDEX of the
>> leaf partition indexes if that index is marked as being part of the
>> partitioned
David Rowley wrote:
> On 15 November 2017 at 01:09, Alvaro Herrera wrote:
> > if a
> > partition exists which *doesn't* have the index, restoring things this
> > way would create the index in that partition too, which is unwanted
> > because the end state is different to what was in the dumped dat
On Mon, Nov 13, 2017 at 3:17 PM, Dean Rasheed
wrote:
> On 28 October 2017 at 13:46, Pavel Stehule
> wrote:
> > I though about Alexander proposal, and I am thinking so it can be
> probably
> > best if we respect psql design. I implemented two command suffixes
> > (supported only when it has sense
On 15 November 2017 at 01:09, Alvaro Herrera wrote:
> if a
> partition exists which *doesn't* have the index, restoring things this
> way would create the index in that partition too, which is unwanted
> because the end state is different to what was in the dumped database.
hmm, but surely the al
Thanks for looking.
David Rowley wrote:
> So, if that works for ATTACH, then can't pg_dump just
> create each of the partition's indexes first, then create the
> partitioned table's partition index, and that command would just go
> through checking each partition similar to how ATTACH would work.
On Tue, Nov 14, 2017 at 9:58 AM, Pavel Golub wrote:
> Hello, Tom.
>
> You wrote:
>
> TL> Geoff Winkless writes:
> >> The removal of the [HACKERS] (etc) header will be frustrating for me: I
> do
> >> not sort mailing lists into folders (I simply scan the "Forums"
> autofilter
> >> in gmail) and h
Hmm. Am I reading it right that this discussion led to moving
essentially all code from tqual.c to heapam? Given the hard time we've
had to get tqual.c right, it seems fundamentally misguided to me to
require that every single storage AM reimplements all the visibility
routines.
I think that cha
On Tue, Nov 14, 2017 at 6:08 AM, Connor Wolf <
conn...@imaginaryindustries.com> wrote:
>
> On Mon, Nov 13, 2017 at 2:09 AM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> Hi!
>>
>> On Mon, Nov 13, 2017 at 6:47 AM, Connor Wolf <
>> conn...@imaginaryindustries.com> wrote:
>>
>>> Ok, I
On 8 October 2017 at 02:34, Robert Haas wrote:
> However, when
> you dump-and-restore (including but not limited to the pg_upgrade
> case) you've got to preserve those names. If you just generate a new
> name that may or may not be the same as the old one, then it may
> collide with a user-specif
# I add [hacker] to the mail subject.
Dear Andres Freund.
Thank you for review!
> I'm disinclined to exposing state that way. It's an internal representation
> that's not unlikely to change. Sure,
> pg_buffercache is more of a debugging / investigatory tool, but I
> nevertheless see no reason t
On Fri, Nov 10, 2017 at 10:32:23AM -0300, Martín Marqués wrote:
> An example where using isatty() might fail is if you run pg_basebackup
> from a tty but redirect the output to a file, I believe that in that
> case isatty() will return true, but it's very likely that the user
> might want batch mod
Hi,
On 2017-11-14 17:57:00 +0900, Moon Insung wrote:
> So I add a state column to pg_buffercache view so that I could print a value
> indicating the state of the buffer.
> This is outpu as an unit32 type, and examples are shown below.
> -
> postgres=# select * from pg_buffercache where buffe
Dear Hackers.
I'm studied PostgreSQL buffers for the development of new patches.
In particular, using pg_buffercache, is can easily check the status of actual
buffer.
Bur there was one inconvenience.
Pg_buffercache was also to check only the dirty state of the buffer.
State of the buffer curren
Hello, Tom.
You wrote:
TL> Geoff Winkless writes:
>> The removal of the [HACKERS] (etc) header will be frustrating for me: I do
>> not sort mailing lists into folders (I simply scan the "Forums" autofilter
>> in gmail) and have no wish to do so, and there is no way to make such a
>> machine-read
Hello, Geoff.
You wrote:
GW> The removal of the [HACKERS] (etc) header will be frustrating for
GW> me: I do not sort mailing lists into folders (I simply scan the
GW> "Forums" autofilter in gmail) and have no wish to do so, and there
GW> is no way to make such a machine-readable header visible in
On Tue, Oct 10, 2017 at 10:12 PM, Michael Paquier
wrote:
> Attached is a new patch set with the comments from above. On top of
> that, I have changed a couple of things:
> - 0001 is unchanged, still the same refactoring for the SSL tests.
> - 0002 implements tls-unique, now including tests using t
On Tue, Nov 14, 2017 at 11:46 AM, Beena Emerson
wrote:
> PFA the updated patches.
>
Hi,
I have started testing this along with fast pruning. It is crashing for sql
with subqueries.
one to test case is given below.
CREATE TABLE prun_test_part (empno int, sal int, deptno int) PARTITION BY
RANGE(
On Fri, 10 Nov 2017 14:40:21 +0100
Pavel Stehule wrote:
> Hi
>
> 2017-10-24 14:27 GMT+02:00 Anthony Bykov :
>
> > There are some moments I should mention:
> > 1. {"1":1}::jsonb is transformed into HV {"1"=>"1"}, while
> > ["1","2"]::jsonb is transformed into AV ["1", "2"]
> >
> > 2. If there is
On 2017-11-13 19:03:41 -0800, Andres Freund wrote:
> > Staring at the vacuumlazy hunk I think I might have found a related bug:
> > heap_update_tuple() just copies the old xmax to the new tuple's xmax if
> > a multixact and still running. It does so without verifying liveliness
> > of members. Is
On Tue, Nov 7, 2017 at 6:34 PM, Haribabu Kommi wrote:
> On Tue, Oct 31, 2017 at 8:59 PM, Haribabu Kommi
> wrote:
>> Additional changes that are done in the patches compared to earlier
>> patches apart from rebase.
>
> Rebased patches are attached.
This set of patches needs again a... Rebase.
--
87 matches
Mail list logo
