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,
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
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
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.
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
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
> 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
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
> >>
* 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
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
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
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
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.
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
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.
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
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
>
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
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
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
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
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
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
>>
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
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
>
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
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
>
> * 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
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
> 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
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
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
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
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
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 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
>>
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
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
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
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
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,
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
>
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
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 ...
>
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
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
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
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,
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
$ 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
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
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
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
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
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
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,
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 &
>
> 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
> >
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
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
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
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
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
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.
>
> ***
>
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
>>
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
>
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
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
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
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
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
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
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
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
>>>
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.
>>
>>
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$", "");
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
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.
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,
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
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
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
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
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
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
> =#
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
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.
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
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.
>
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
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.
>>
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
* 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
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
* 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
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
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
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
>
99 matches
Mail list logo