On 2016/06/10 2:07, Robert Haas wrote:
> On Thu, Jun 9, 2016 at 5:50 AM, Amit Langote wrote:
>> I adjusted some comments per off-list suggestion from Ashutosh. Please
>> find attached the new version.
>
> Are PlaceHolderVars the only problem we need to worry about here?
I
On 2016/06/08 23:16, Amit Langote wrote:
> On Wed, Jun 8, 2016 at 9:27 PM, Robert Haas wrote:
>> On Tue, Jun 7, 2016 at 10:41 PM, Noah Misch wrote:
>>> [Action required within 72 hours. This is a generic notification.]
>>>
>>> The above-described topic is
On Wed, Jun 8, 2016 at 9:27 PM, Robert Haas wrote:
> On Tue, Jun 7, 2016 at 10:41 PM, Noah Misch wrote:
>> [Action required within 72 hours. This is a generic notification.]
>>
>> The above-described topic is currently a PostgreSQL 9.6 open item. Robert,
>> since you committed the patch believe
On 2016/06/08 14:13, Ashutosh Bapat wrote:
> On Tue, Jun 7, 2016 at 6:19 PM, Amit Langote wrote:
>> On Tue, Jun 7, 2016 at 7:47 PM, Ashutosh Bapat wrote:
>>> Looks good to me. If we add a column from the outer relation, the
>> "NULL"ness
>>> of inner c
On 2016/06/08 9:38, Amit Langote wrote:
> Attached fixes a typo:
>
> s/PG_ALL_VISIBLE/PD_ALL_VISIBLE/g
Oops. Made a couple of mistakes there:
Subject: Typo in pg_visibility documentation
Patch: Really attached this time.
Thanks,
Amit
diff --git a/doc/src/sgml/pgvisibility.sgml b/doc
Attached fixes a typo:
s/PG_ALL_VISIBLE/PD_ALL_VISIBLE/g
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jun 7, 2016 at 7:47 PM, Ashutosh Bapat wrote:
> On Tue, Jun 7, 2016 at 4:07 PM, Amit Langote wrote:
>> On 2016/06/07 19:13, Ashutosh Bapat wrote:
>> > So, your patch looks to be the correct approach (even after we support
>> > deparsing subqueries). Can y
On 2016/06/07 19:13, Ashutosh Bapat wrote:
> I thought, columns of inner relation will be set to null during projection
> from ForeignScan for joins. But I was wrong. If we want to push-down joins
> in this case, we have two solutions
> 1. Build queries with subqueries at the time of deparsing. Thu
Hi Ashutosh,
On 2016/06/07 17:02, Ashutosh Bapat wrote:
> On Tue, Jun 7, 2016 at 11:36 AM, Amit Langote wrote:
>> On 2016/06/05 23:01, Andreas Seltenreich wrote:
...
>>> --8<---cut here---start->8---
>>> create extensio
On 2016/06/05 23:01, Andreas Seltenreich wrote:
> Creating some foreign tables via postgres_fdw in the regression db of
> master as of de33af8, sqlsmith triggers the following assertion:
>
> TRAP: FailedAssertion("!(const Node*)(var))->type) == T_Var))", File:
> "deparse.c", Line: 1116)
>
On 2016/06/07 14:41, Michael Paquier wrote:
> On Fri, Apr 22, 2016 at 1:25 AM, David G. Johnston
> wrote:
>> On Wed, Apr 20, 2016 at 9:18 PM, Amit Langote
>> wrote:
>>> I agree it's unclear. Does the following make it any better (updated
>>> patch atta
On 2016/06/01 13:07, sri harsha wrote:
> Hi,
>
> In PostgreSQL , does the order in which the criteria is given matter ??
> For example
>
> Query 1 : Select * from TABLE where a > 5 and b < 10;
>
> Query 2 : Select * from TABLE where b <10 and a > 5;
>
> Are query 1 and query 2 the same in P
On 2016/05/30 22:59, Craig Ringer wrote:
> On 30 May 2016 at 16:17, Etsuro Fujita wrote:
>>
>> That's a good point, but the basic idea is to send the local query
>> almost-as-is to the remote server if possible. For example, if the local
>> query is "INSERT INTO foreign_table(a,b,c) VALUES (1, 2,
On 2016/05/19 2:48, Tom Lane wrote:
> Amit Langote writes:
>> On 2016/05/18 2:22, Tom Lane wrote:
>>> The two ways that we've dealt with this type of hazard are to copy data
>>> out of the relcache before using it; or to give the relcache the
>>> responsi
Currently in HEAD and 9.6, one can issue a non-exclusive backup on
standby, so this is OK:
select pg_is_in_recovery();
pg_is_in_recovery
---
t
(1 row)
select pg_start_backup('sby-bkp-test', 'f', 'f');
pg_start_backup
-
0/5000220
(1 row)
However the following h
On 2016/05/18 2:22, Tom Lane wrote:
> Amit Langote writes:
>> On 2016/05/16 22:12, Ildar Musin wrote:
>>> Could you please tell is
>>> it possible that relcache invalidation occurs during SELECT/UPDATE/DELETE
>>> query?
>
>> Hmm, I think invalidation
Hi Ildar,
On 2016/05/16 22:12, Ildar Musin wrote:
> Hi Amit,
>
> I'm running some experiments based on your infrastructure trying to
> optimize SELECT queries. At some point I need to get PartitionDesc for
> relation and to do it I'm using RelationGetPartitionDesc() function.
> Problem is that t
Hi,
Attached patch adds missing "is" in a sentence in backup.sgml.
Thanks,
Amit
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index b036183..96fc9a0 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -906,8 +906,8 @@ SELECT * FROM pg_stop_backup(false);
Hi,
On 2016/05/12 17:42, Sameer Thakur-2 wrote:
> Hello Amit,
> In the example
>> create table part201606week4 partition of parted
>> for values start (2016, 6, 2) end (2016, 6, 29);
>
> seems to be a typo
Oops, there indeed is.
create table part201606week4 partition of parted
for values sta
Hi Ashutosh,
On 2016/05/09 20:21, Ashutosh Bapat wrote:
> Hi Amit,
> I am trying multi-column/expression partitions.
Thanks for the tests.
> create table t1_multi_col (a int, b int) partition by range (a, b);
> create table t1_mc_p1 partition of t1_multi_col for values start (1, 200)
> end (100
Attached fixes a minor typo comment in _readExtensibleNode().
s/skip: extnodename/skip :extnodename/g
I was confused at first as to why there is a skip extnodename on one line
and get extnodename right on the next line as the comments say, :)
Thanks,
Amit
diff --git a/src/backend/nodes/readfuncs
On Fri, Apr 29, 2016 at 2:42 PM, sri harsha wrote:
>
> Its not an OpExpr . It is a VAR , got it from "reltargetlist" in base
> relation ( RelOptInfo) . Can you shed some light on where the conversion
> from 141 to "original" attribute number takes place ??
As Tom said, you must be looking at an O
Horiguchi-san,
On 2016/04/22 14:21, Kyotaro HORIGUCHI wrote:
> I came to think that both of you are misunderstanding how
> synchronous standbys are choosed so I'd like to clarify the
> behavior.
I certainly had a different (and/or wrong) idea in mind about how this
works. Thanks a lot for clari
On 2016/04/15 12:02, Robert Haas wrote:
> As previously threatened, I have written some user documentation for
> parallel query. I put it up here:
>
> https://wiki.postgresql.org/wiki/Parallel_Query
>
> This is not totally comprehensive and I can think of a few more
> details that could be added
On Fri, Apr 22, 2016 at 2:32 AM, Robert Haas wrote:
> On Wed, Apr 20, 2016 at 3:37 AM, Amit Langote wrote:
>>> I think it'd be better to match the comment with that for
>>> create_foreignscan_path(). So how about "ForeignPath represents a
>>> potential s
On 2016/04/21 12:25, Kyotaro HORIGUCHI wrote:
> At Wed, 20 Apr 2016 23:07:41 -0400, Robert Haas wrote:
>> On Sun, Apr 17, 2016 at 11:56 PM, Kyotaro HORIGUCHI wrote:
>>>
There is no mechanism to enforce uniqueness. In case of
duplicates one of the matching standbys will be considered as
>>
Hi Ildar,
On Wed, Apr 20, 2016 at 11:46 PM, Ildar Musin wrote:
> Thanks for clarification! I tried the updated patch, now it works correctly.
Great, thanks!
> I encountered another problem that concerns expressions as partitioning key.
> Probably there is still some work in progress. But if it
Fujita-san,
On 2016/04/20 16:20, Etsuro Fujita wrote:
> On 2016/04/18 17:31, Amit Langote wrote:
>> Is the following description now outdated:
>>
>> "ForeignPath represents a potential scan of a foreign table"
>>
>> Considering that there now ex
Hi Idlar, Alexander,
On Tue, Apr 19, 2016 at 11:26 PM, Alexander Korotkov
wrote:
> On Tue, Apr 19, 2016 at 4:57 PM, Ildar Musin wrote:
>>
>> Thanks for your new patch! I've tried it and discovered some strange
>> behavior for partitioning by composite key. Here is an example of my setup:
>>
>> c
On 2016/04/18 15:33, Ashutosh Bapat wrote:
>> For time being, I will leave this as yet unaddressed (I am thinking about
>> what is reasonable to do for this also considering Robert's comment). Is
>> that OK?
>>
>
> Right now EXPLAIN of select * from t1, where t1 is partitioned table shows
> Appen
Is the following description now outdated:
"ForeignPath represents a potential scan of a foreign table"
Considering that there now exists FdwRoutine.GetForeignJoinPaths() whose
product is nothing else but a ForeignPath, should it now say (patch attached):
"ForeignPath represents a potential scan
On 2016/04/18 15:38, Ashutosh Bapat wrote:
>> There was no KeyTypeCollInfo in early days of the patch and then I found
>> myself doing a lot of:
>>
>> partexprs_item = list_head(key->partexprs);
>> for (attr in key->partattrs)
>> {
>> if (attr->attnum != 0)
>> {
>> // simple column
Hi,
On 2016/04/15 18:46, Ashutosh Bapat wrote:
>
> 3. PartitionKeyData contains KeyTypeCollInfo, whose contents can be
> obtained by calling functions exprType, exprTypemod on partexprs. Why do we
> need to store that information as a separate member?
There was no KeyTypeCollInfo in early days
Hi Ashutosh,
On 2016/04/15 18:48, Ashutosh Bapat wrote:
> With the new set of patches, I am getting following warnings but no
> compilation failures. Patches apply smoothly.
> partition.c:1216:21: warning: variable ‘form’ set but not used
> [-Wunused-but-set-variable]
> partition.c:1637:20: warni
On 2016/04/05 14:24, Amit Langote wrote:
> On 2016/04/05 0:23, Tom Lane wrote:
>> Amit Langote writes:
>>> Hm, some kind of PlanInvalItem-based solution could work maybe?
>>
>> Hm, so we'd expect that whenever an FDW consulted the options while
>>
Hi Stephen,
On 2016/04/14 9:24, Stephen Frost wrote:
> Amit,
>
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>> Currently in CreateUserMapping():
>>
>> /* Additional check to protect reserved role names */
>> check_rolespec_name(stmt->user
Hi Stephen,
On 2016/04/14 2:10, Stephen Frost wrote:
>> Amit Langote > writes:
>>> I observe this:
>>
>>> postgres=# SET ROLE TO NONE;
>>> SET
>>> postgres=# SET ROLE TO nonexistent;
>>> ERROR: role "nonexistent" does not e
Hi,
Currently in CreateUserMapping():
/* Additional check to protect reserved role names */
check_rolespec_name(stmt->user,
"Cannot specify reserved role as mapping user.");
User mapping terminology is not that clear to me really but how does the
following sound a
Hi,
I observe this:
postgres=# SET ROLE TO NONE;
SET
postgres=# SET ROLE TO nonexistent;
ERROR: role "nonexistent" does not exist
postgres=# SET ROLE TO pg_signal_backend;
ERROR: invalid value for parameter "role": "pg_signal_backend"
Is that behavior deliberate? Might it be better to handle
Hi,
Attached fixes copyright in file mentioned in $subject.
Thanks,
Amit
diff --git a/src/backend/access/rmgrdesc/genericdesc.c b/src/backend/access/rmgrdesc/genericdesc.c
index caa9a03..0796bb8 100644
--- a/src/backend/access/rmgrdesc/genericdesc.c
+++ b/src/backend/access/rmgrdesc/genericdesc.c
On 2016/04/07 15:26, Fujii Masao wrote:
> On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila wrote:
>> On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao wrote:
>>> Yes if the variable that we'd like to pass to a backend is BOOL, INT,
>>> REAL, STRING or ENUM. But SyncRepConfig variable is a bit more
>>> comp
On 2016/04/06 8:48, David Fetter wrote:
> On Tue, Apr 05, 2016 at 07:10:56PM -0400, Robert Haas wrote:
>> On Tue, Apr 5, 2016 at 6:50 PM, David Fetter wrote:
>>> Is there a reason other than lack of tuits for this restriction?
>>
>> "this" lacks an antecedent.
>
> Try to put a primary key on a ma
On 2016/04/05 18:44, Kyotaro HORIGUCHI wrote:
> At Tue, 5 Apr 2016 14:24:52 +0900, Amit Langote wrote:
>> On 2016/04/05 0:23, Tom Lane wrote:
>>> Amit Langote writes:
>>>> Hm, some kind of PlanInvalItem-based solution could work maybe?
>>>
>>> Hm, s
On 2016/04/05 16:35, Simon Riggs wrote:
> 6. Meaning of k (n1, n2, n3) with N servers
>
> It's clearly documented that this means k replies IN SEQUENCE. I believe
> the typical meaning of would be “any k out of N”, which would be faster
> than what we have, e.g.
>3 (n1, n2, n3) would release a
On 2016/04/05 0:23, Tom Lane wrote:
> Amit Langote writes:
>> On Mon, Apr 4, 2016 at 11:24 PM, Tom Lane wrote:
>>> A related issue, now that I've seen this example, is that altering
>>> FDW-level or server-level options won't cause a replan either. I'm
On Mon, Apr 4, 2016 at 11:24 PM, Tom Lane wrote:
> Amit Langote writes:
>> On 2016/04/04 15:17, Rajkumar Raghuwanshi wrote:
>>> * .Observation: *Prepare statement execution plan is not getting changed
>>> even after altering foreign table to point to new schema.
On 2016/04/04 17:25, Simon Riggs wrote:
> The rel cache code you're adding uses a flag called "rd_fkeyvalid" which
> indicates that the relcache is correctly filled. That is confusing, since
> it has nothing to do with the concept of constraint validity. We should
> rename that to rd_fkeycachefille
Hi,
Thanks for the report.
On 2016/04/04 15:17, Rajkumar Raghuwanshi wrote:
> Hi,
>
> I observed below in postgres_fdw
>
> * .Observation: *Prepare statement execution plan is not getting changed
> even after altering foreign table to point to new schema.
>
[ ... ]
> PREPARE stmt_ft AS sele
On Thu, Mar 31, 2016 at 1:00 AM, Tom Lane wrote:
> I wrote:
>> Amit Langote writes:
>>> destdb=# ALTER TABLE c ADD CONSTRAINT p_a_check CHECK (a IN ('a', 'b',
>>> 'c'));
>>> destdb=# \d c
>>> ...
>>> Check con
On 2016/03/30 15:16, Harshal Dhumal wrote:
> Hi Team,
>
> While I was working on constraints node in pgadmin4 I came across this
> scenario. Please let me know if it's correct behaviour or a bug.
>
> *Scenario:*
>
> If we create two different type of constrains (lets say primary key and
> forei
Hi,
On 2016/03/25 23:49, Onder Kalaci wrote:
> Hi hackers,
>
> As it's documented in the source code, systable_beginscan() could be used
> to on non-system tables as well. My question is that, is it possible to
> write a C code with systable_beginscan(), systable_getnext() and ScanKeys
> which i
On 2016/03/28 17:50, Kyotaro HORIGUCHI wrote:
>
> # LISPers don't hesitate to dive into Sea of Parens.
Sorry in advance to be off-topic: https://xkcd.com/297 :)
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On 2016/03/24 22:01, Robert Haas wrote:
> On Thu, Mar 24, 2016 at 8:45 AM, Rahila Syed wrote:
>>
>> - values[i+3] =
>> UInt32GetDatum(beentry->st_progress_param[i]);
>> + values[i+3] =
>> Int64GetDatum(beentry->st_progress_param[i]);
>>
>
On 2016/03/23 9:19, Álvaro Hernández Tortosa wrote:
> - Regarding GSoC: it looks to me that we failed to submit in time. Is this
> what happened, or we weren't selected? If the former (and no criticism
> here, just realizing a fact) what can we do next year to avoid this
> happening again? Is anyon
On 2016/03/22 4:55, Robert Haas wrote:
> So, the last patch on this thread was posted on February 17th, and the
> CF entry was marked Waiting on Author on March 2nd. Even if we had a
> new patch in hand at this point, I don't think there's any real chance
> of being able to get this done for 9.6;
Hi Alexander,
Thanks a lot for taking a look!
On Wed, Mar 16, 2016 at 10:56 PM, Alexander Korotkov
wrote:
> I tried to apply your patch. It still applies, but has some duplicate oids.
Actually, a reworked version I will post hopefully early next week
will have fixed this.
> After fixing dupli
Attached fixes a minor typo as follows:
s/index vacuums cycles/index vacuum cycles/g
Thanks,
Amit
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 7055c37..cb22afb 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -2594,7 +2594,7 @@ SELE
On 2016/03/16 2:33, Robert Haas wrote:
> On Tue, Mar 15, 2016 at 1:16 AM, Amit Langote
> wrote:
>> On 2016/03/15 3:41, Robert Haas wrote:
>>> Well, I think you need to study the index AMs and figure this out.
>>
>> OK. I tried to put calls to the callback in ap
On 2016/03/15 16:42, Peter Geoghegan wrote:
> On Tue, Mar 15, 2016 at 12:31 AM, Amit Langote
> wrote:
>> By the way, one request (as a non-native speaker of English language, who
>> ends up looking up quite a few words regularly) -
>>
>> Could we use "conform&q
Hi Peter,
On 2016/03/15 16:11, Peter Geoghegan wrote:
> On Mon, Mar 14, 2016 at 11:48 PM, Amit Langote
> wrote:
>>> Dunno about that. It's defining characteristic is that it checks child
>>> pages against their parent IMV. Things are not often defined in terms
>
On 2016/03/12 6:31, Peter Geoghegan wrote:
> On Thu, Mar 10, 2016 at 9:18 AM, Tomas Vondra
> wrote:
>> I've looked at this patch today, mostly to educate myself, so this
>> probably should not count as a full review. Anyway, the patch seems in
>> excellent shape - it'd be great if all patches (inc
On 2016/03/15 3:41, Robert Haas wrote:
> On Sat, Mar 12, 2016 at 7:49 AM, Amit Langote wrote:
>> Instead, the attached patch adds a IndexBulkDeleteProgressCallback
>> which AMs should call for every block that's read (say, right before a
>> call to ReadBufferExtended)
Hi,
Thanks for taking a look at the patch.
On Mon, Mar 14, 2016 at 6:55 PM, Rahila Syed wrote:
> Hello,
>
> While I am still looking at this WIP patch, I had one suggestion.
>
> Instead of making changes in the index AM API can we have a call to update
> the shared state using pgstat_progress* A
On 2016/03/14 10:54, Thomas Munro wrote:
> Hi
>
> I guess pg_stat_get_progress_info should either be strict (see
> attached) or check for NULL.
Thanks a lot for reporting and the patch. I think that's an oversight.
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On Fri, Mar 11, 2016 at 2:31 PM, Amit Langote
wrote:
> On 2016/03/11 13:16, Robert Haas wrote:
>> On Thu, Mar 10, 2016 at 9:04 PM, Amit Langote
>> wrote:
>>> So, from what I understand here, we should not put total count of index
>>> pages into st_progress_param;
On 2016/03/11 13:16, Robert Haas wrote:
> On Thu, Mar 10, 2016 at 9:04 PM, Amit Langote
> wrote:
>> So, from what I understand here, we should not put total count of index
>> pages into st_progress_param; rather, have the client (reading
>> pg_stat_progress_vacuum) derive
On 2016/03/10 23:29, Robert Haas wrote:
> On Thu, Mar 10, 2016 at 3:08 AM, Amit Langote
> wrote:
>> Hi Vinayak,
>>
>> Thanks for the quick review!
>
> Committed 0001 earlier this morning.
Thanks!
> On 0002:
>
> + /* total_index_blks */
>
On Thu, Mar 10, 2016 at 10:55 PM, Robert Haas wrote:
> On Thu, Mar 10, 2016 at 6:42 AM, David Rowley
> wrote:
>> The one reason that I asked about force_parallel_mode was that I
>> assumed there was some buildfarm member running somewhere that
>> switches this on and runs the regression tests. I
Hi,
Thanks for the report.
On 2016/03/10 18:05, Aleksander Alekseev wrote:
> Hello
>
> I noticed:
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b6fb6471f6afaf649e52f38269fd8c5c60647669
>
> ... that comments for procedures pgstat_progress_update_param and
> pgstat_progr
Hi Vinayak,
Thanks for the quick review!
On 2016/03/10 16:22, poku...@pm.nttdata.co.jp wrote:
>> On 2016/03/10 14:29, Amit Langote wrote:
>> Updated patches attached.
> In 0002-
[ snip ]
> I think we need to use datid instead of datname.
> Robert added datid in pg_stat_ge
On 2016/03/10 14:29, Amit Langote wrote:
> I rebased remainder patches (attached).
>
> 0001 is a small patch to fix issues reported by Tomas and Vinayak. 0002
> and 0003 are WIP patches to implement progress reporting for vacuum.
Oops, in 0002, I wrongly joined with pg_class in th
On 2016/03/10 2:16, Robert Haas wrote:
> On Wed, Mar 9, 2016 at 2:37 AM, Amit Langote
> wrote:
>> On 2016/03/09 10:11, Amit Langote wrote:
>>> The attached revision addresses above and one of Horiguchi-san's comments
>>> in his email yesterday.
>>
>&g
On 2016/03/09 10:11, Amit Langote wrote:
> The attached revision addresses above and one of Horiguchi-san's comments
> in his email yesterday.
I fixed one more issue in 0002 per Horiguchi-san's comment. Sorry about
so many versions.
Thanks,
Amit
>From 9473230af72e0a0e3b60a
> On 2016/03/08 18:19, Kyotaro HORIGUCHI wrote:
>> + WHEN 0 THEN 100::numeric(5, 2)
>> + ELSE ((S.param3 + 1)::numeric / S.param2 *
>> 100)::numeric(5, 2)
>>
>> This usage of numeric seems overkill to me.
>
> Hmm, how could this rather be written?
OK, ag
Horiguchi-san,
Thanks for the review!
On 2016/03/08 18:19, Kyotaro HORIGUCHI wrote:
>> Updated versions attached.
>>
>> * changed st_progress_param to int64 and so did the argument of
>> pgstat_progress_update_param(). Likewise changed param1..param10 of
>> pg_stat_get_progress_info()'s output
and, ah, I forgot to add myself as a
> reviewer. I have also reviewed this for last few CFs.
>
> So, as looking into CF app, it seems not so inconsistent with the
> persons who appears in this thread for thses three CFs.
>
> Authors: Vinayak Pokale, Rahila Syed, Amit Langote
&g
On 2016/03/09 0:24, Robert Haas wrote:
> On Tue, Mar 8, 2016 at 3:02 AM, Amit Langote
> wrote:
>> Updated versions attached.
>>
>> * changed st_progress_param to int64 and so did the argument of
>> pgstat_progress_update_param(). Likewise changed param1..param10 o
Hi,
On 2016/03/09 9:17, Corey Huinker wrote:
>>
>> Sorry for replying so late.
> No worries! We have jobs to do aside from this.
Thanks!
>> Everything seemed to go dandy until I tried FOR VALUES (blah , blah],
>> where psql wouldn't send the command string without accepting the closing
>> paren
On Wed, Mar 9, 2016 at 12:24 AM, Robert Haas wrote:
> This patch has been worked on by so many people and reviewed by so
> many people that I can't keep track of who should be credited when it
> gets committed. Could someone provide a list of author(s) and
> reviewer(s)?
Original authors are Rah
On 2016/03/07 23:48, Robert Haas wrote:
> On Sun, Mar 6, 2016 at 11:02 PM, Kyotaro HORIGUCHI
> wrote:
>> The 0001-P.. adds the following interface functions.
>>
>> +extern void pgstat_progress_set_command(BackendCommandType cmdtype);
>> +extern void pgstat_progress_set_command_target(Oid objid);
>
Hi Corey,
Sorry for replying so late.
On 2016/02/25 3:31, Corey Huinker wrote:
>
[ ... ]
> So I would assume that we'd use a syntax that presumed the columns were in
> a composite range type.
>
> Which means your creates would look like (following Robert Haas's implied
> suggestion that we l
On 2016/03/07 19:11, Amit Langote wrote:
> we should re-introduce[1] a fixed-size char st_progress_message[] field.
Sorry, that [1] does not refer to anything, just a leftover from my draft.
I thought I had a link handy for an email where some sort of
justification was given as to
Horiguchi-san,
Thanks for a quick reply, :)
On 2016/03/07 18:18, Kyotaro HORIGUCHI wrote:
> At Mon, 7 Mar 2016 16:16:30 +0900, Amit Langote wrote:
>> On 2016/03/07 13:02, Kyotaro HORIGUCHI wrote:
>>> The 0001-P.. adds the following interface functions.
>>>
>>&
Horiguchi-san,
Thanks a lot for taking a look!
On 2016/03/07 13:02, Kyotaro HORIGUCHI wrote:
> At Sat, 5 Mar 2016 16:41:29 +0900, Amit Langote wrote:
>> On Sat, Mar 5, 2016 at 4:24 PM, Amit Langote wrote:
>>> So, I took the Vinayak's latest patch and rewrote it a littl
On Sat, Mar 5, 2016 at 4:24 PM, Amit Langote wrote:
> So, I took the Vinayak's latest patch and rewrote it a little
...
> I broke it into two:
>
> 0001-Provide-a-way-for-utility-commands-to-report-progres.patch
> 0002-Implement-progress-reporting-for-VACUUM-command.patch
Oo
On Sat, Mar 5, 2016 at 7:11 AM, Robert Haas wrote:
> On Fri, Feb 26, 2016 at 3:28 AM, wrote:
>> Thank you for your comments.
>> Please find attached patch addressing following comments.
>
> I'm positive I've said this at least once before while reviewing this
> patch, and I think more than once:
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 set
>> + to on is guaranteed either to see the effects of all
>> + completed tran
Hi Thomas,
On 2016/02/29 15:20, Thomas Munro wrote:
> Thanks for looking at the patch! Here is a new version with the
> following changes:
>
> 1. Some draft user documentation has been added, as requested.
Just to clarify, in:
+ servers. A transaction that is run with
causal_reads s
Hi Ildar,
On 2016/02/29 7:14, Ildar Musin wrote:
> 16/02/16 07:46, Amit Langote wrote:
>> On 2016/02/16 11:41, Josh berkus wrote:
>>> We're not going to use CE for the new partitioning long-term, are we? This
>>> is just the first version, right?
>> Ye
Attached fixes a typo:
/* the extra unit accounts for the autovacuum launcher */
MaxBackends = MaxConnections + autovacuum_max_workers + 1 +
- +max_worker_processes;
+ max_worker_processes;
Thanks,
Amit
typo.patch
Description: Binary data
--
Sent via pgsql-hackers maili
Hi Vinayak,
Thanks for updating the patch! A quick comment:
On 2016/02/26 17:28, poku...@pm.nttdata.co.jp wrote:
>> CREATE VIEW pg_stat_vacuum_progress AS
>> SELECT S.s[1] as pid,
>> S.s[2] as relid,
>> CASE S.s[3]
>>WHEN 1 THEN 'Scanning Heap'
>>
Hi,
Thanks for your feedback.
On 2016/02/26 0:43, Jean-Pierre Pelletier wrote:
> Why not based it on "Exclusion Constraint" ?
>
> Most discussions as of late seems to focus on Range overlaps which appeal
> (I would think) is that it supports both "equality" and "overlaps", two
> popular partiti
On 2016/02/23 22:51, Robert Haas wrote:
> On Thu, Feb 18, 2016 at 11:11 AM, Amit Langote wrote:
>> Some might think that writing potentially the same PARTITION BY clause 100
>> times for 100 level-1 partitions could be cumbersome. That is what
>> SUBPARTITION BY notation may b
On 2016/02/20 5:06, Corey Huinker wrote:
> On Thu, Feb 18, 2016 at 12:41 AM, Amit Langote wrote:
>
>> START [ EXCL ] (startval) END [ INCL ] (endval)
>>
>> That is, in range type notation, '[startval, endval)' is the default
>> behavior. So for each pa
On Sat, Feb 20, 2016 at 1:41 PM, Peter Eisentraut wrote:
> On 2/16/16 9:56 PM, Amit Langote wrote:
>> From now on, instead of attaching multiple files like in the previous
>> message, I will send a single tar.gz which will contain patches created by
>> git-format-patch.
>
On 2016/02/18 22:44, Alexander Korotkov wrote:
> On Wed, Feb 17, 2016 at 10:40 AM, Amit Langote wrote:
>> I didn't find for 2016 but here is the PostgreSQL wiki page for the last
>> year's GSoC page: https://wiki.postgresql.org/wiki/GSoC_2015#Project_Ideas
>
>
&g
On 2016/02/18 16:38, Craig Ringer wrote:
> I should resurrect Abhijit's patch to allow the isolationtester to talk to
> multiple servers. We'll want that when we're doing tests like "assert that
> this change isn't visible on the replica before it becomes visible on the
> master". (Well, except we
On 2016/02/16 21:57, Robert Haas wrote:
> On Fri, Jan 15, 2016 at 5:48 AM, Amit Langote
> wrote:
>> If we have a CREATE statement for each partition, how do we generalize
>> that to partitions at different levels? For example, if we use something
>> like the following
Hi,
On 2016/02/16 18:25, Kyotaro HORIGUCHI wrote:
> At Tue, 16 Feb 2016 10:39:27 +0900, Amit Langote wrote:
>> On 2016/02/15 20:21, Kyotaro HORIGUCHI wrote:
>>> CREATE FUNCTION
>>> pg_stat_get_command_progress(IN cmdtype integer)
>>> RETURNS SETOF integ
Hi Shubham,
On 2016/02/17 16:27, Shubham Barai wrote:
> Hello everyone,
>
> I am currently pursuing my bachelor of engineering in computer science
> at Maharashtra
> Institute of Technology, Pune ,India. I am very excited about contributing
> to postgres through google summer of code program.
>
801 - 900 of 1334 matches
Mail list logo
