On Mon, Jan 9, 2017 at 1:45 PM, Haribabu Kommi wrote:
> Updated patch is attached.
>
I've a few comments about the patch.
+ This type can accept both 6 and 8 bytes length MAC addresses.
A 6 bytes length MAC address is internally converted to 8 bytes. We
should include this in the docs. Becaus
On Fri, Jan 13, 2017 at 10:29 PM, Tom Lane wrote:
> Michael Paquier writes:
>> And actually, contrary to what is mentioned upthread, the planner is
>> not able to avoid a sort phase if other data types are used, say:
>> =# create table foo (a int, b int);
>> CREATE TABLE
>> =# create index on foo
$ cat loop.sql
\if :x < 1000
\echo :x
\set x :x + 1
\include loop.sql
\fi
$ psql --set x=0 -f loop.sql
Nice one! CPP does not have arithmetic, so it is harder to do that because
one must reimplement arithmetic with #if...
Somebody is going to think of that workaround for not having loop
Pavel Stehule writes:
> 2017-01-14 0:20 GMT+01:00 Corey Huinker :
>> - leaving loops out for now?
> +1
I'm just going to say one thing about that: some people will remember
that you can build a Turing machine with either conditionals+iteration
or conditionals+recursion. I wonder what depth of i
2017-01-13 22:44 GMT+01:00 Alvaro Herrera :
> Pavel Stehule wrote:
> > Hi
> >
> > I would to do import without RI check - so I disable RI triggers.
> >
> > I would to invalidate constraint on Foreign Keys and then I would to use
> > ALTER TABLE VALIDATE CONSTRAINT ...
> >
> > I didn't find how to
On Fri, Jan 13, 2017 at 4:24 PM, Peter Geoghegan wrote:
On Fri, Jan 13, 2017 at 3:44 PM, Serge Rielau wrote:
> And sometimes the community DOES go its own way rather than implementing the
> standard. For example by rejecting the MERGE statement in favor of another
> syntax and semantic.
That's
Hi
2017-01-14 0:20 GMT+01:00 Corey Huinker :
> Ok, so activity on this thread has died down. I'm not sure if that's
> consensus or exhaustion.
>
the original idea \quit_if is leaved? It is pity - it is common use case -
and because we cannot to implement macros in psql, then can be very useful
On Sat, Jan 14, 2017 at 6:10 AM, Robert Haas wrote:
> On Fri, Jan 13, 2017 at 3:09 PM, Alvaro Herrera
> wrote:
>>
>> I'm just saying that the problem at hand is already solved for a related
>> feature, so ISTM this new code should use the recently added routine
>> rather than doing the same thin
On 01/14/2017 12:06 AM, Andres Freund wrote:
Hi,
On 2017-01-13 17:58:41 -0500, Tom Lane wrote:
But, again, the catcache isn't the only source of per-process bloat
and I'm not even sure it's the main one. A more holistic approach
might be called for.
It'd be helpful if we'd find a way to mak
On Fri, Jan 13, 2017 at 3:44 PM, Serge Rielau wrote:
> And sometimes the community DOES go its own way rather than implementing the
> standard. For example by rejecting the MERGE statement in favor of another
> syntax and semantic.
That's total nonsense.
MERGE isn't UPSERT, and isn't even in c
On Fri, Jan 13, 2017 at 2:46 PM, Kevin Grittner wrote:
On Fri, Jan 13, 2017 at 12:35 PM, Serge Rielau wrote:
> Yes my proposal to nest schemata is “radical” and this community
> is not falling into that camp.
> But there is nothing holy about database.schema.object.attribute
It is mandated by t
Ok, so activity on this thread has died down. I'm not sure if that's
consensus or exhaustion.
Are we good with:
- implementing basic \if EXPR \elseif EXPR \else \endif, where the EXPR is
an expression but is currently limited to a simple string that will be
evaluated for truth via ParseVariableBoo
Hi,
On 2017-01-13 17:58:41 -0500, Tom Lane wrote:
> But, again, the catcache isn't the only source of per-process bloat
> and I'm not even sure it's the main one. A more holistic approach
> might be called for.
It'd be helpful if we'd find a way to make it easy to get statistics
about the size
On Sat, Jan 7, 2017 at 4:15 AM, Daniel Verite wrote:
> The defaults comes from these definitions, in include/pg_config_manual.h
>
> /*
> * Set the upper and lower bounds of sequence values.
> */
> #define SEQ_MAXVALUEPG_INT64_MAX
> #define SEQ_MINVALUE(-SEQ_MAXVALUE)
>
> with no comment
Michael Paquier writes:
> ... There are even some apps that do not use pgbouncer, but drop
> sessions after a timeout of inactivity to avoid a memory bloat because
> of the problem of this thread.
Yeah, a certain company I used to work for had to do that, though their
problem had more to do with
On Fri, Jan 13, 2017 at 12:35 PM, Serge Rielau wrote:
> Yes my proposal to nest schemata is “radical” and this community
> is not falling into that camp.
> But there is nothing holy about database.schema.object.attribute
It is mandated by the U.S. and international SQL standard documents.
--
Ke
On Sat, Jan 14, 2017 at 1:43 AM, Kevin Grittner wrote:
> On Fri, Jan 13, 2017 at 7:09 AM, Michael Paquier
> wrote:
>> There is no real harm in including current_logfiles in base
>> backups, but that's really in the same bag as postmaster.opts or
>> postmaster.pid, particularly if the log file nam
On Sat, Jan 14, 2017 at 12:32 AM, Robert Haas wrote:
> On Fri, Jan 13, 2017 at 8:58 AM, Tom Lane wrote:
>> Michael Paquier writes:
>>> Have there been ever discussions about having catcache entries in a
>>> shared memory area? This does not sound much performance-wise, I am
>>> just wondering ab
Here's a v2 that does it like that.
Applies, compiles, overall & pgss make check are both ok.
Personnally I find having RawStmt only for the top parsed statement
cleaner, and it significantly reduces changes in the parser, as expected,
without inducing too much changes elsewhere.
Same com
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 submitted it as I
recall.
--
Álvaro Herre
Pavel Stehule wrote:
> Hi
>
> I would to do import without RI check - so I disable RI triggers.
>
> I would to invalidate constraint on Foreign Keys and then I would to use
> ALTER TABLE VALIDATE CONSTRAINT ...
>
> I didn't find how to invalidate constraint without direct update
> pg_constraint.
On Fri, Jan 13, 2017 at 3:22 AM, Etsuro Fujita
wrote:
> On 2017/01/13 0:43, Robert Haas wrote:
>
>> On Wed, Jan 11, 2017 at 2:45 AM, Etsuro Fujita
>> wrote:
>>
>>> As I said before, that might be fine for 9.6, but I don't think it's a
>>> good
>>> idea to search the pathlist because once we supp
2017-01-13 22:16 GMT+01:00 Serge Rielau :
> On Fri, Jan 13, 2017 at 12:45 PM, Pavel Stehule
> wrote:
>
> show patch and show a advantages against schema, please.
>
> I have tried to describe the advantage.
> If the community doesn’t agree, that’s fine.
> I do not see how expending the effort of b
On Tue, Jan 10, 2017 at 6:06 AM, Amit Langote
wrote:
> On 2017/01/05 5:50, Robert Haas wrote:
>> On Tue, Dec 27, 2016 at 3:59 AM, Amit Langote
>> wrote:
>>> Patches 0001 to 0006 unchanged.
>>
>> Committed 0001 earlier, as mentioned in a separate email. Committed
>> 0002 and part of 0003.
>
> Tha
On 1/13/17 9:45 AM, Peter Eisentraut wrote:
> On 1/12/17 9:43 PM, Bruce Momjian wrote:
>> On Thu, Jan 12, 2017 at 10:17:52AM -0500, Tom Lane wrote:
>>> Peter Eisentraut writes:
In 9.5, the default pg_ctl stop mode was changed from "smart" to "fast".
In pg_upgrade, there is this code:
>>>
On Fri, Jan 13, 2017 at 12:45 PM, Pavel Stehule
wrote: show patch and show a advantages against schema, please. I have tried to
describe the advantage. If the community doesn’t agree, that’s fine. I do not
see how expending the effort of back porting a patch (and getting clearance for
that fro
A new data type, and/or a new index type could both be nicely scoped bits
of work.
On Thu, Jan 12, 2017 at 12:27 PM, Pavel Stehule
wrote:
>
>
> 2017-01-12 21:21 GMT+01:00 Jim Nasby :
>
>> On 1/10/17 1:53 AM, Alexander Korotkov wrote:
>>
>>> 1. What project ideas we have?
>>>
>>
>> Perhaps allowi
On Fri, Jan 13, 2017 at 3:09 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Fri, Jan 13, 2017 at 2:31 PM, Robert Haas wrote:
>> > On Fri, Jan 13, 2017 at 2:18 PM, Alvaro Herrera
>> > wrote:
>
>> >> Hmm, we were discussing this stuff a few days ago, see
>> >> https://www.postgresql.org/mess
Florian Weimer writes:
> glibc has some test cases which fail because clock_gettime gives
> inconsistent results. This has been fixed in current kernels, but I
> don't know if everyone uses them.
hmm, for which clock IDs?
regards, tom lane
--
Sent via pgsql-hackers ma
* Tom Lane:
> Florian Weimer writes:
>> * Tom Lane:
>>> On Linux (RHEL6, 2.4GHz x86_64), I find that gettimeofday(),
>>> clock_gettime(CLOCK_MONOTONIC), and clock_gettime(CLOCK_REALTIME)
>>> all take about 40ns. Of course gettimeofday() only has 1us resolution,
>>> but the other two have perhaps
2017-01-13 20:38 GMT+01:00 Serge Rielau :
>
> > On Jan 13, 2017, at 11:11 AM, Pavel Stehule
> wrote:
> >
> > With Postgres we should to think much more about other PL - there is not
> only PL/pgSQL. So any what we create should be available for any PL. Our
> PLpgSQL is based on total different te
Robert Haas wrote:
> On Fri, Jan 13, 2017 at 2:31 PM, Robert Haas wrote:
> > On Fri, Jan 13, 2017 at 2:18 PM, Alvaro Herrera
> > wrote:
> >> Hmm, we were discussing this stuff a few days ago, see
> >> https://www.postgresql.org/message-id/20170109182800.qrkae62kmur3gfeg@alvherre.pgsql
> >> and c
> On Jan 13, 2017, at 11:11 AM, Pavel Stehule wrote:
>
> With Postgres we should to think much more about other PL - there is not only
> PL/pgSQL. So any what we create should be available for any PL. Our PLpgSQL
> is based on total different technology design - so some benefits of sharing
>
On Fri, Jan 13, 2017 at 2:31 PM, Robert Haas wrote:
> On Fri, Jan 13, 2017 at 2:18 PM, Alvaro Herrera
> wrote:
>> Robert Haas wrote:
>>> Fix a bug in how we generate partition constraints.
>>>
>>> Move the code for doing parent attnos to child attnos mapping for Vars
>>> in partition constraint e
On Fri, Jan 13, 2017 at 2:18 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> Fix a bug in how we generate partition constraints.
>>
>> Move the code for doing parent attnos to child attnos mapping for Vars
>> in partition constraint expressions to a separate function
>> map_partition_varattnos()
Robert Haas wrote:
> Fix a bug in how we generate partition constraints.
>
> Move the code for doing parent attnos to child attnos mapping for Vars
> in partition constraint expressions to a separate function
> map_partition_varattnos() and call it from the appropriate places.
Hmm, we were discus
Robert Haas wrote:
> From a technical point of view, that is pretty much true. But from a
> user perspective, I don't think it is. If the old names live in an
> extension, then they will not be there by default. Tools and scripts
> will break. If that's a problem for a particular user, they an
2017-01-13 19:35 GMT+01:00 Serge Rielau :
>
> > On Jan 13, 2017, at 10:23 AM, Pavel Stehule
> wrote:
> >
> > I have not clean feeling from this - I am pretty sure so I am afraid
> schizophrenic between MODULES, SCHEMAS. Nested schemas increase complexity
> of searching complexity and breaks a lo
Fabien COELHO writes:
>> One thing that I'm not quite satisfied with is the business with
>> non-top-level RawStmt nodes in some utility statements.
>> ...
>> So I'm now thinking that it might be better if the grammar produced
>> RawStmt only at top level, and anybody who calls pg_analyze_and_rew
On Wed, Jan 11, 2017 at 4:05 PM, Robert Haas wrote:
>> While investigating why Rushabh Lathia's Gather Merge patch sometimes
>> fails to pick a Gather Merge plan even when it really ought to do so,
>> I ran smack into this problem. I discovered that this is more than a
>> cosmetic issue. The cos
> On Jan 13, 2017, at 10:23 AM, Pavel Stehule wrote:
>
> I have not clean feeling from this - I am pretty sure so I am afraid
> schizophrenic between MODULES, SCHEMAS. Nested schemas increase complexity
> of searching complexity and breaks a logic database.schema.object
Yes my proposal to nes
2017-01-13 18:35 GMT+01:00 Serge Rielau :
>
>> * A design that can fit in with PostgreSQL
>> * Solid benefits beyond "makes life easier for Oracle users" to
>> justify each feature/change
>> * Funding/time to make it happen
>>
>> So far, I haven't seen anyone with one of those, let alone all three
On Fri, Jan 13, 2017 at 5:57 AM, Amit Kapila wrote:
> Sure, we can do that way and I agree that it is worth considering.
> Few cases where it can be really costly is when undo chain overflows
> to multiple pages and those pages doesn't exist in cache. I think the
> reason why it is probable is th
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 whitespace
totally wrong - surely it can't be right to have 0-space in
>
> * A design that can fit in with PostgreSQL
> * Solid benefits beyond "makes life easier for Oracle users" to
> justify each feature/change
> * Funding/time to make it happen
>
> So far, I haven't seen anyone with one of those, let alone all three.
OK, I’ll bite…
* In SFDC’s extension of Post
Tom Lane wrote:
> AFAICS, what Ryan is after would be better served by a separate tool that
> would produce a "diff" of the two tables' schemas. Even if we were
> willing to overload this error message with everything we know about the
> parent column, do you really want to fix discrepancies one
One thing that I'm not quite satisfied with is the business with
non-top-level RawStmt nodes in some utility statements.
a wart from gram.y's perspective, and it's mostly a wart from analyze.c's
perspective as well --- the parse analyze routines mostly just throw away
the non-top-level RawStmt
On Thu, Jan 12, 2017 at 1:12 PM, Tom Lane wrote:
> Vladimir Rusinov writes:
>> On Thu, Jan 12, 2017 at 4:57 PM, Euler Taveira wrote:
>>> As Robert suggested in the other email: extension to create old names.
>
>> I don't follow the reasoning for the extension. It seem to have downsides
>> of bot
On Fri, Jan 13, 2017 at 7:09 AM, Michael Paquier
wrote:
> There is no real harm in including current_logfiles in base
> backups, but that's really in the same bag as postmaster.opts or
> postmaster.pid, particularly if the log file name has a
> timestamp.
I'm going to dispute that -- if postmast
Peter Eisentraut wrote:
> So in order to correctly answer the question, is the sequence about to
> run out, you need to look not only at
> the sequence but also any columns it is associated with. check_postgres
> figures this out, but it's complicated and slow, and not easy to do
> manual
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_sqlstmt are always ensuring that
> pgstat_track_sql is true, seem
Michael Paquier wrote:
> Hm. Is symmetry an important properly for sequences? It seems to me
> that if we map with the data types we had better use the MIN values
> instead for consistency. So the concept of this patch is rather weird
> and would introduce an exception with the rest of the
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 it successfully, we can proceed
with that safely then...
This is the same
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 1/12/17 2:22 PM, Stephen Frost wrote:
> > The point I was making above is that the only reason to not make such
> > changes is if they really are entirely arbitrary, but I don't think
> > we'd even be having this discussion if that w
On Fri, Jan 13, 2017 at 8:58 AM, Tom Lane wrote:
> Michael Paquier writes:
>> Have there been ever discussions about having catcache entries in a
>> shared memory area? This does not sound much performance-wise, I am
>> just wondering about the concept and I cannot find references to such
>> disc
On Fri, Jan 13, 2017 at 4:57 PM, Fabien COELHO wrote:
>
> Hello Rafia,
>
>>> sh> git apply ~/pgbench-continuation-3.patch
>>> # ok
>>
>>
>> It still gives me whitespace errors with git apply,
>
>
> Strange.
>
Yes, quite strange.
>> /Users/edb/Downloads/pgbench-continuation-3.patch:31: trailin
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 1/12/17 1:40 PM, Stephen Frost wrote:
> > I just don't buy this argument, at all. These functions names are
> > certainly not the only things we're changing with PG10 and serious
> > monitoring/backup/administration tools are almost
Peter Eisentraut writes:
> On 1/12/17 9:43 PM, Bruce Momjian wrote:
>> On Thu, Jan 12, 2017 at 10:17:52AM -0500, Tom Lane wrote:
>>> Peter Eisentraut writes:
I think the last line should be changed to something like
fast ? "-m fast" : "-m smart");
>>> There is maybe room for a separate
On 1/12/17 2:22 PM, Stephen Frost wrote:
> The point I was making above is that the only reason to not make such
> changes is if they really are entirely arbitrary, but I don't think
> we'd even be having this discussion if that was the case or that we'd
> be split about the question. We already m
Craig Ringer writes:
> Sounds like it'd be better as a separate change so as not to block this one.
Yeah, if we do that at all it should be a separate patch IMO. The
concerns are largely different.
> I really like what you have done Tom, though I'm about to travel so I
> haven't read it in full
On 1/12/17 1:50 PM, Stephen Frost wrote:
> When they're changes that are primairly going to affect
> monitoring/backup/administration tools, yes, I do think we can make just
> about arbitrary backward-incompatible changes.
I don't agree with that.
--
Peter Eisentraut http://www.2ndQ
On 1/12/17 1:40 PM, Stephen Frost wrote:
> I just don't buy this argument, at all. These functions names are
> certainly not the only things we're changing with PG10 and serious
> monitoring/backup/administration tools are almost certainly going to
> have quite a bit to adjust to with the new rele
On 1/12/17 9:43 PM, Bruce Momjian wrote:
> On Thu, Jan 12, 2017 at 10:17:52AM -0500, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> In 9.5, the default pg_ctl stop mode was changed from "smart" to "fast".
>>> In pg_upgrade, there is this code:
>>> ...
>>> I think the last line should be chang
27.12.2016 17:33, Amit Kapila:
On Fri, Dec 23, 2016 at 6:42 PM, Anastasia Lubennikova
wrote:
22.12.2016 07:19, Amit Kapila:
On Wed, Dec 21, 2016 at 8:46 PM, Anastasia Lubennikova
wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested,
> What this patch does is to add two new clauses for FROM-list items,
> NORMALIZE and ALIGN, which reshuffle a set of ranges into a new list
> that can then be aggregated more easily. From the original message:
>
> > For NORMALIZE the tuples' ranges need to be split into all sub-ranges
> > accordi
On 13 Jan. 2017 19:16, "Thomas Kellerer" <
Which is a bit cumbersome given Oracle's limit on 30 characters for
identifiers - but it still increases maintainability. And one of the
advantages given for packages was the increase in namespace availability
which is much easier with Postgres anyway.
On 13 Jan. 2017 16:35, "Kyotaro HORIGUCHI"
wrote:
Hello,
At Thu, 12 Jan 2017 20:08:54 +0100 (CET), Fabien COELHO
wrote in
>
> About having a pointer to the initial string from RawStmt, Query &
> PlannedStmt:
>
> > I remembered one reason why we haven't done this: it's unclear how
> > we'd hand
Kyotaro HORIGUCHI writes:
> I found an inconsistency (in style, not function:) between
> copyfuncs and equalfuncs. The patch handles the three members
> utilityStmt, stmt_location and stmt_len of Query at once and
> copyfuncs seems to be edited to follow the rule, but in
> equalfuncs the position
Michael Paquier writes:
> Have there been ever discussions about having catcache entries in a
> shared memory area? This does not sound much performance-wise, I am
> just wondering about the concept and I cannot find references to such
> discussions.
I'm sure it's been discussed. Offhand I remem
Amit Khandekar wrote:
> In a server where autovacuum is disabled and its databases reach
> autovacuum_freeze_max_age limit, an autovacuum is forced to prevent
> xid wraparound issues. At this stage, when the server is loaded with a
> lot of DML operations, an exceedingly high number of autovacuum
>
Dilip Kumar writes:
> ERROR: did not find '}' at end of input node at character 762
I've not looked at the patches, but just seeing this error message,
this looks like somebody's fat-fingered the correspondence between
outfuncs.c and readfuncs.c processing.
regards, tom
On Thu, Jan 12, 2017 at 7:56 PM, Amit Kapila wrote:
> Okay, done that way. I have fixed the review comments raised by Dilip
> as well and added the test case in attached patch.
I have tested with pq_pushdown_subplan_v2.patch +
pq_pushdown_correl_subplan_v1.patch
sqlsmith. is reporting below err
I implemented IF NOT EXISTS option for CREATE SERVER and CREATE USER
MAPPING statements
for one of our customers.
I think other users can also find it useful for scripting and automated
tasks.
The patches themselves are small and simple. Documentation is updated as
well.
--
Anastasia Lubennik
Alvaro Herrera writes:
> Tom Lane wrote:
>> Somebody failed to grasp the point of having the #ifdef CATCACHE_STATS
>> fields at the end of the struct. Put that back the way it should be,
>> and add a comment making it more explicit why it should be that way.
> Actually, the CATCACHE_STATS was ad
Tom Lane wrote:
> Fix field order in struct catcache.
>
> Somebody failed to grasp the point of having the #ifdef CATCACHE_STATS
> fields at the end of the struct. Put that back the way it should be,
> and add a comment making it more explicit why it should be that way.
Actually, the CATCACHE_ST
Michael Paquier writes:
> And actually, contrary to what is mentioned upthread, the planner is
> not able to avoid a sort phase if other data types are used, say:
> =# create table foo (a int, b int);
> CREATE TABLE
> =# create index on foo (a, b);
> CREATE INDEX
> =# explain (costs off) select *
Hi
I would to do import without RI check - so I disable RI triggers.
I would to invalidate constraint on Foreign Keys and then I would to use
ALTER TABLE VALIDATE CONSTRAINT ...
I didn't find how to invalidate constraint without direct update
pg_constraint.
Is there some clean way?
Regards
Pa
Ashutosh Bapat writes:
> On Thu, Jan 12, 2017 at 6:39 PM, Tom Lane wrote:
>> I think you'd just end up putting it back at some point. It's the only
>> means that foreign_expr_walker() has for getting at the root pointer,
>> and nearly all planner code needs that. Seems to me it's just chance
>>
On Fri, Jan 13, 2017 at 2:46 AM, Jim Nasby wrote:
> On 1/11/17 5:54 AM, Pavel Stehule wrote:
>
>> +too_many_rows
>> +
>> +
>> + When result is assigned to a variable by INTO
>> clause,
>> + checks if query returns more than one row. In this case the
>> assignment
>> +
On Thu, Jan 12, 2017 at 5:47 PM, Dilip Kumar wrote:
>> Hello Dilip,
>> I was trying to test the performance of all the parallel query related
>> patches on TPC-H queries, I found that when parallel hash [1 ]and your
>> patch are applied then Q10 and Q14 were hanged, however, without any
>> one of
On Fri, Jan 13, 2017 at 5:48 PM, Gilles Darold wrote:
> Le 13/01/2017 à 05:26, Michael Paquier a écrit :
>> Surely the temporary file of current_logfiles should not be included
>> in base backups (look at basebackup.c). Documentation needs to reflect
>> that as well. Also, should we have current_l
On 2017/01/13 0:43, Robert Haas wrote:
On Wed, Jan 11, 2017 at 2:45 AM, Etsuro Fujita
wrote:
As I said before, that might be fine for 9.6, but I don't think it's a good
idea to search the pathlist because once we support parameterized foreign
join paths, which is on my TODOs, we would have to t
Hello Rafia,
sh> git apply ~/pgbench-continuation-3.patch
# ok
It still gives me whitespace errors with git apply,
Strange.
/Users/edb/Downloads/pgbench-continuation-3.patch:31: trailing whitespace.
continuation \\{newline}
Looks like an editor issue, I used awk '{ sub("\r$", "");
Wolfgang Wilhelm wrote
> - The more difficult a database change including rewriting of code will
> get the less likely you'll find something paying for it. In my case there
> is a list of reasons from the customer _not_ to switch from Oracle to
> PostgreSQL. Besides more obvious reasons like APEX a
On Thu, Jan 12, 2017 at 8:56 PM, Robert Haas wrote:
> On Wed, Jan 11, 2017 at 5:18 AM, Amit Kapila wrote:
>> Moving further, I have thought about consistent reads and different
>> formats for storing undo with pros and cons of each format.
>>
>> Consistent Reads
>>
>>
On Thu, Jan 12, 2017 at 6:24 PM, Robert Haas wrote:
> On Wed, Jan 11, 2017 at 11:12 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Wed, Jan 11, 2017 at 6:36 PM, Tom Lane wrote:
That would work, if you had a way to get at the active QueryDesc ...
but we don't pass that down to execu
On 5 Jan 2017 2:54 a.m., "Craig Ringer" wrote:
> Ants, do you think you'll have a chance to convert your shell script
> test into a TAP test in src/test/recovery?
>
> Simon has said he would like to commit this fix. I'd personally be
> happier if it had a test to go with it.
>
> You could probably
Hello again,
well, I didn't want to tell you to match in PostgreSQL the technical debt. If I
made it look so, sorry for my bad english.
No, a "free clone of Oracle" isn't my intention. I don't want to convince
Oracle evangelists to use PostgreSQL. This is time wasted. But I'd prefer a
project wh
On Wed, Jan 11, 2017 at 5:39 PM, Fabien COELHO wrote:
>
> Hello,
>
>>> The attached patch adds backslash-return (well newline really)
>>> continuations
>>> to all pgbench backslash-commands.
>>>
>>> The attached test uses continuations on all such commands (sleep set
>>> setshell and shell).
>>>
>
2017-01-13 10:11 GMT+01:00 Craig Ringer :
> On 13 January 2017 at 16:49, Wolfgang Wilhelm
> wrote:
> > - Devs just don't want to change (some) code. Everybody seems to have
> code
> > with huge technical debt which is best not to be touched. This code
> should
> > have an easy "move code from Ora
There is a typo in comments of function _hash_first(); Adding a fix for same.
--
Thanks and Regards
Mithun C Y
EnterpriseDB: http://www.enterprisedb.com
hashsearch_typo01.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
2017-01-13 2:46 GMT+01:00 Jim Nasby :
> On 1/11/17 5:54 AM, Pavel Stehule wrote:
>
>> +too_many_rows
>> +
>> +
>> + When result is assigned to a variable by INTO
>> clause,
>> + checks if query returns more than one row. In this case the
>> assignment
>> + is not determ
On 13 January 2017 at 16:49, Wolfgang Wilhelm wrote:
> - Devs just don't want to change (some) code. Everybody seems to have code
> with huge technical debt which is best not to be touched. This code should
> have an easy "move code from Oracle to PostgreSQL", best case by not forcing
> the devs t
Hello,
just my 2c on the topic.I work for an IT service provider as developer. Our
customers are big international companies and they use Oracle a lot. My main
work is with Oracle enterprise edition. I don't have to care about limitations
of the smaller versions and don't have experience wi
Le 13/01/2017 à 05:26, Michael Paquier a écrit :
> OK. I have been looking at this patch.
>
> git diff --check is very unhappy, particularly because of
> update_metainfo_datafile().
Sorry, fixed.
> +
> +When logs are written to the file-system their paths, names, and
> +types are recor
On Thu, Jan 12, 2017 at 5:39 PM, Rahila Syed wrote:
> Hello,
>
> On applying the patch on latest master branch and running regression tests
> following failure occurs.
> I applied it on latest parallel index scan patches as given in the link
> above.
>
> ***
> /home/rahila/postgres/postgres/src/te
Hello,
It is big, but I think quite reasonable. The refactoring makes
many things clearer and I like it. No objection for the
patch. The affect of changing some API's are not a problem.
At Thu, 12 Jan 2017 19:00:47 +0100 (CET), Fabien COELHO
wrote in
> Patch applies (with "patch", "git apply"
Hello,
At Thu, 12 Jan 2017 20:08:54 +0100 (CET), Fabien COELHO
wrote in
>
> About having a pointer to the initial string from RawStmt, Query &
> PlannedStmt:
>
> > I remembered one reason why we haven't done this: it's unclear how
> > we'd handle copying if we do it. If, say, Query contains a
On Wed, Dec 21, 2016 at 5:10 AM, Tom Lane wrote:
> If I thought that "every ten minutes" was an ideal way to manage this,
> I might worry about that, but it doesn't really sound promising at all.
> Every so many queries would likely work better, or better yet make it
> self-adaptive depending on h
99 matches
Mail list logo
