On Thu, Feb 23, 2017 at 1:08 PM, Amit Langote
wrote:
> Thanks for the review.
>
> On 2017/02/23 15:44, Ashutosh Bapat wrote:
>> On Thu, Feb 23, 2017 at 11:19 AM, Amit Langote wrote:
>>> Rewrote that comment block as:
>>>
>>> *
>>> * If the parent is a partitioned table, we already set th
Hi
I propose a schema private functions as analogy to Oracle package functions.
My target of this proposal is better isolation generally available top
level callable functions from other auxiliary functions. A execution of
functions can be little bit more robust due less dependency on SEARCH_PATH
Thanks for the review.
On 2017/02/23 15:44, Ashutosh Bapat wrote:
> On Thu, Feb 23, 2017 at 11:19 AM, Amit Langote wrote:
>> Rewrote that comment block as:
>>
>> *
>> * If the parent is a partitioned table, we already set the nominal
>> * relation.
>> */
>>
>
> I reworded thos
Nagata-san,
On 2017/02/23 16:17, Yugo Nagata wrote:
> Hi,
>
> I found that a comment for PartitionRoot in ResultRelInfo is missing.
> Although this is trivial, since all other members have comments, I
> think it is needed. Attached is the patch to fix it.
Thanks for taking care of that.
+ *
From: Amit Kapila [mailto:amit.kapil...@gmail.com]
> > Hmm, the large-page requires contiguous memory for each page, so this
> error could occur on a long-running system where the memory is heavily
> fragmented. For example, please see the following page and check the memory
> with RAMMap program
On Wed, Feb 22, 2017 at 2:17 AM, Masahiko Sawada wrote:
> On Wed, Feb 22, 2017 at 1:52 AM, Fujii Masao wrote:
>> On Tue, Feb 21, 2017 at 7:52 PM, Masahiko Sawada
>> wrote:
>>> On Tue, Feb 21, 2017 at 3:42 AM, Fujii Masao wrote:
On Thu, Feb 16, 2017 at 11:40 AM, Masahiko Sawada
wrot
On Thu, Feb 2, 2017 at 3:07 PM, Nikhil Sontakke wrote:
>>> Yeah. Was thinking about this yesterday. How about adding entries in
>>> TwoPhaseState itself (which become valid later)? Only if it does not
>>> cause a lot of code churn.
>>
>> That's possible as well, yes.
>
> PFA a patch which does the
Hi,
I found that a comment for PartitionRoot in ResultRelInfo is missing.
Although this is trivial, since all other members have comments, I
think it is needed. Attached is the patch to fix it.
Regards,
Yugo Nagata
On Tue, 27 Dec 2016 17:59:05 +0900
Amit Langote wrote:
> On 2016/12/26 19:46, A
On Mon, Feb 20, 2017 at 3:06 PM, Joel Jacobson wrote:
> On Mon, Feb 20, 2017 at 1:45 AM, Tom Lane wrote:
>> The versions of autocommit that have actually stood the test of time were
>> implemented on the client side (in psql and JDBC, and I think ODBC as
>> well), where the scope of affected code
On 2/20/17 3:30 AM, Joel Jacobson wrote:
Also, I think the --lowercase-uniqueness feature would be useful by
itself even without the --case-preserving feature,
since that might be a good way to enforce a good design of new databases,
as a mix of "users" and "Users" is probably considered ugly by
On Thu, Feb 23, 2017 at 11:19 AM, Amit Langote
wrote:
> Thanks for the review.
>
> On 2017/02/22 21:58, Ashutosh Bapat wrote:
Also we should add tests to make sure the scans on partitioned tables
without any partitions do not get into problems. PFA patch which adds
those tests.
>>>
Welcome to v15, highlights:
Files "conditional.h" and "conditional.c" are missing from the patch.
Also, is there a particular reason why tap test have been removed?
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
On Wed, Feb 22, 2017 at 10:22 PM, Dilip Kumar wrote:
>
> Some initial comments.
>
> --
> if (numberTuples || dest->mydest == DestIntoRel)
> use_parallel_mode = false;
>
> if (use_parallel_mode)
> EnterParallelMode();
> + else if (estate->es_plannedstmt->parallelModeNeeded &&
> + (dest->myd
On 2/20/17 11:22 AM, David Christensen wrote:
- If an entire cluster is going to be considered as checksummed, then even
databases that don't allow connections would need to get enabled.
Yeah, the workaround for now would be to require “datallowconn" to be set to
’t' for all databases before p
I think this is ready for committer.
On Thu, Feb 23, 2017 at 12:02 PM, Amit Langote
wrote:
> On 2017/02/22 21:24, Ashutosh Bapat wrote:
>> On Wed, Feb 22, 2017 at 11:11 AM, Amit Langote wrote:
>>> + /*
>>> +* Unlike inheritance children, partition tables are expected to be
>>> drop
Hi all,
When storing WAL segments on a dedicated partition with
pg_receivexlog, for some deployments, the removal of past WAL segments
depends on the frequency of base backups happening on the server. In
short, once a new base backup is taken, it may not be necessary to
keep around those past WAL
On 2017/02/22 21:24, Ashutosh Bapat wrote:
> On Wed, Feb 22, 2017 at 11:11 AM, Amit Langote wrote:
>> + /*
>> +* Unlike inheritance children, partition tables are expected to be
>> dropped
>> +* when the parent partitioned table gets dropped.
>> +*/
>>
>> Hmm. Partit
On Thu, Feb 23, 2017 at 11:52 AM, Thomas Munro
wrote:
> The overall graph looks pretty similar, but it is more likely to short
> hiccups caused by occasional slow WAL fsyncs in walreceiver. See the
I meant to write "more likely to *miss* short hiccups".
--
Thomas Munro
http://www.enterprisedb
On Tue, Feb 21, 2017 at 6:21 PM, Simon Riggs wrote:
> I think what we need to show some test results with the graph of lag
> over time for these cases:
> 1. steady state - pgbench on master, so we can see how that responds
> 2. blocked apply on standby - so we can see how the lag increases but
> a
Thanks for the review.
On 2017/02/22 21:58, Ashutosh Bapat wrote:
>>> Also we should add tests to make sure the scans on partitioned tables
>>> without any partitions do not get into problems. PFA patch which adds
>>> those tests.
>>
>> I added the test case you suggest, but kept just the first on
On Wed, Feb 22, 2017 at 6:15 PM, Corey Huinker
wrote:
> On Wed, Feb 22, 2017 at 5:59 PM, Tom Lane wrote:
>
>> Ah, I see why *that* wants to know about it ... I think. I suppose you're
>> arguing that variable expansion shouldn't be able to insert, say, an \else
>> in a non-active branch? Maybe
On 2017/02/23 0:54, David Fetter wrote:
> On Wed, Feb 22, 2017 at 04:51:46PM +0900, Amit Langote wrote:
>> Attached patch fixes an oversight that tablesample cannot be used with
>> partitioned tables:
>>
>> create table p (a int) partition by list (a);
>> select * from p tablesample bernoulli (50);
Hi,
On 2017/02/23 11:55, Venkata B Nagothi wrote:
> Hi Hackers,
>
> I have noticed the following behaviour in range partitioning which i felt
> is not quite correct (i missed reporting this) -
>
> I have tested by creating a date ranged partition.
>
> I created the following table.
>
> db03=#
Robert Haas writes:
> On Wed, Feb 22, 2017 at 10:33 PM, Nico Williams wrote:
>> I suspect most users, like me, just roll their eyes, grumble, and put up
>> with it rather than complain. It's a pain point, but tolerable enough
>> that no one bothers to demand a change. Now that it's been done th
On Wed, Feb 22, 2017 at 8:05 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> There is support for COMMENT ON RULE without specifying a table
>> name, for upgrading from pre-7.3 instances. I think it might be time
>> for that workaround to go.
>
> No objection here.
Yeah, probably so.
--
Ro
On 2017-02-23 08:21:41 +0530, Robert Haas wrote:
> On Wed, Feb 22, 2017 at 10:33 PM, Nico Williams wrote:
> > On Wed, Feb 22, 2017 at 10:08:38AM -0500, Tom Lane wrote:
> >> Bernd Helmle writes:
> >> >> From time to time, especially during migration projects from Oracle to
> >> > PostgreSQL, i'm f
Hi Hackers,
I have noticed the following behaviour in range partitioning which i felt
is not quite correct (i missed reporting this) -
I have tested by creating a date ranged partition.
I created the following table.
db03=# CREATE TABLE orders (
o_orderkey INTEGER,
o_custkey INT
On Wed, Feb 22, 2017 at 10:33 PM, Nico Williams wrote:
> On Wed, Feb 22, 2017 at 10:08:38AM -0500, Tom Lane wrote:
>> Bernd Helmle writes:
>> >> From time to time, especially during migration projects from Oracle to
>> > PostgreSQL, i'm faced with people questioning why the alias in the FROM
>> >
On 22 Feb. 2017 14:14, "Vaishnavi Prabakaran"
wrote:
Thanks for reviewing the patch.
>
Thanks for picking it up! I've wanted to see this process for some time,
but just haven't had the bandwidth for it.
On Wed, Jan 11, 2017 at 04:38:10PM -0500, Robert Haas wrote:
> More broadly, I don't share Bruce's negativity about indirect indexes.
> My estimate of what needs to be done for them to be really useful is -
> I think - higher than your estimate of what needs to be done, but I
> think the concept is
On 23/02/17 01:02, Erik Rijkers wrote:
> On 2017-02-22 18:13, Erik Rijkers wrote:
>> On 2017-02-22 14:48, Erik Rijkers wrote:
>>> On 2017-02-22 13:03, Petr Jelinek wrote:
>>>
0001-Skip-unnecessary-snapshot-builds.patch
0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch
0
pg_get_object_address() currently returns a field called subobjid, while
pg_depend calls that objsubid. I'm guessing that wasn't on purpose
(especially because internally the function uses objsubid), and it'd be
nice to fix it.
Attached does that, as well as updating the input naming on the ot
On 2/22/17 5:38 PM, Michael Banck wrote:
diff --git a/src/bin/pg_dump/pg_dump_sort.c b/src/bin/pg_dump/pg_dump_sort.c
index ea643397ba..708a47f3cb 100644
--- a/src/bin/pg_dump/pg_dump_sort.c
+++ b/src/bin/pg_dump/pg_dump_sort.c
@@ -26,6 +26,9 @@ static const char *modulename = gettext_noop("sorte
On 2017-02-22 18:13, Erik Rijkers wrote:
On 2017-02-22 14:48, Erik Rijkers wrote:
On 2017-02-22 13:03, Petr Jelinek wrote:
0001-Skip-unnecessary-snapshot-builds.patch
0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch
0003-Fix-xl_running_xacts-usage-in-snapshot-builder.patch
0001-
On Fri, Feb 3, 2017 at 07:59:26AM +0100, Pavel Stehule wrote:
> It should be documented and presented (who is read a documentation? :-))
>
> It is not only PostgreSQL issue, same issue has to have any other databases.
> The Oracle architecture is very specific and often question is, how to map
>
On 2/21/17 2:05 PM, Stephen Frost wrote:
As for $SUBJECT, I feel like it really depends, doesn't it? If the
extension creates the matview w/ no data in it, and doesn't mark it as a
config table, should we really refresh it? On the other hand, if the
extension creates the matview and either refr
Hi,
On Wed, Feb 22, 2017 at 05:24:49PM -0600, Jim Nasby wrote:
> On 2/22/17 12:29 PM, Peter Eisentraut wrote:
> >On 2/22/17 10:14, Jim Nasby wrote:
> >>CREATE MATERIALIZED VIEW tmv AS SELECT * FROM pg_subscription;
> >>SELECT 0
> >>
> >>IOW, you can create matviews that depend on any other
> >>tab
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 2/22/17 12:29 PM, Peter Eisentraut wrote:
> >On 2/22/17 10:14, Jim Nasby wrote:
> >>CREATE MATERIALIZED VIEW tmv AS SELECT * FROM pg_subscription;
> >>SELECT 0
> >>
> >>IOW, you can create matviews that depend on any other
> >>table/view/matv
On 2/22/17 12:29 PM, Peter Eisentraut wrote:
On 2/22/17 10:14, Jim Nasby wrote:
CREATE MATERIALIZED VIEW tmv AS SELECT * FROM pg_subscription;
SELECT 0
IOW, you can create matviews that depend on any other
table/view/matview, but right now if the matview includes certain items
it will mysteriou
The topic has been previously discussed[0] on the -performance mailing list,
about four years ago.
In that thread, Tom suggested[0] the planner could be made to "expand
"intcol <@
'x,y'::int4range" into "intcol between x and y", using something similar
to the
index LIKE optimization (ie, the "spec
On Wed, Feb 22, 2017 at 5:59 PM, Tom Lane wrote:
> Ah, I see why *that* wants to know about it ... I think. I suppose you're
> arguing that variable expansion shouldn't be able to insert, say, an \else
> in a non-active branch? Maybe, but if it can insert an \else in an active
> branch, then wh
Corey Huinker writes:
> After some research, GetVariable is called by psql_get_variable, which is
> one of the callback functions passed to psql_scan_create(). So passing a
> state variable around probably isn't going to work and PsqlFileState now
> looks like the best option.
Ah, I see why *that
On Wed, Feb 22, 2017 at 5:11 PM, Corey Huinker
wrote:
> Dunno, that sounds a lot like an "if the only tool I have is a hammer,
>> then this must be a nail" argument.
>
>
> More of a "don't rock the boat more than absolutely necessary", but
> knowing that adding another global struct might be welc
Andres Freund writes:
> On 2017-02-22 08:43:28 -0500, Tom Lane wrote:
>> (To be concrete, I'm suggesting dropping --disable-integer-datetimes
>> in HEAD, and just agreeing that in the back branches, use of replication
>> protocol with float-timestamp servers is not supported and we're not
>> going
On Fri, Feb 3, 2017 at 05:21:28AM -0500, Stephen Frost wrote:
> > Also googling for pg_wal, I'm finding food for thought like this
> > IBM technote:
> > http://www-01.ibm.com/support/docview.wss?uid=isg3T1015637
> > which recommends to
> > "Remove all files under /var/lib/pgsql/9.0/data/pg_wal/"
>
>
> Dunno, that sounds a lot like an "if the only tool I have is a hammer,
> then this must be a nail" argument.
More of a "don't rock the boat more than absolutely necessary", but knowing
that adding another global struct might be welcomed is good to know.
> reasonable interpretation of what
Corey Huinker writes:
> On Wed, Feb 22, 2017 at 4:00 PM, Tom Lane wrote:
>> One thing I'm wondering is why the "active_branch" bool is in "pset"
>> and not in the conditional stack. That seems, at best, pretty grotty.
>> _psqlSettings is meant for reasonably persistent state.
> With the if-stac
On Wed, Feb 22, 2017 at 4:00 PM, Tom Lane wrote:
> Corey Huinker writes:
> >> but if you think that it should be somewhere else, please advise Corey
> >> about where to put it.
>
> > Just a reminder that I'm standing by for advice.
>
> Sorry, I'd lost track of this thread.
>
Judging by the volu
I wonder if this "perf c2c" tool with Linux 4.10 might be useful in
studying this problem.
https://joemario.github.io/blog/2016/09/01/c2c-blog/
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-
Corey Huinker writes:
>> but if you think that it should be somewhere else, please advise Corey
>> about where to put it.
> Just a reminder that I'm standing by for advice.
Sorry, I'd lost track of this thread.
> The issue at hand is whether the if-state should be a part of the
> PsqlScanState,
On Tue, Feb 21, 2017 at 6:14 PM, Robert Haas wrote:
> On Tue, Feb 21, 2017 at 2:03 AM, Bruce Momjian wrote:
>> I have to admit my reaction was similar to Simon's, meaning that the
>> lack of docs is a problem, and that the limitations are kind of a
>> surprise, and I wonder what other surprises t
On 2/16/17 07:41, Robert Haas wrote:
> Also, it sounds like all of this is intended to work with ranges that
> are stored in different columns rather than with PostgreSQL's built-in
> range types.
Yeah, that should certainly be changed.
--
Peter Eisentraut http://www.2ndQuadrant.com
On 2/22/17 10:14, Jim Nasby wrote:
> CREATE MATERIALIZED VIEW tmv AS SELECT * FROM pg_subscription;
> SELECT 0
>
> IOW, you can create matviews that depend on any other
> table/view/matview, but right now if the matview includes certain items
> it will mysteriously end up empty post-restore.
Ye
I looked into the report in bug #14563 about pg_trgm giving wrong
answers for regexp searches. There is a whole lot of complex mechanism
in trgm_regexp.c for extracting trigram patterns out of regexps, and
so I was afraid that it might be a very subtle bug, but actually the
problem seems to be in
Hi all thanks,
I have tried to fix all of the comments given above with some more
code cleanups.
On Wed, Feb 22, 2017 at 6:28 AM, Robert Haas wrote:
> I think it's OK to treat that as something of a corner case. There's
> nothing to keep you from doing that today: just use pg_buffercache to
> du
Dave, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Dave Page (dp...@pgadmin.org) wrote:
> > What modules should be included?
>
> On a quick review of all of the modules, excluding those that are just
> testing or examples or which can already be used by non-superusers by
> default, and ex
Dave,
* Dave Page (dp...@pgadmin.org) wrote:
> On Wed, Feb 22, 2017 at 4:52 PM, Stephen Frost wrote:
> >> > > And what about the diagnostic tools such as pageinspect and
> >> > > pgstattuple?
> >> >
> >> > I think external/contrib modules should not be included. To install
> >> > them you need a
On Mon, Feb 20, 2017 at 11:58:12AM +0100, Petr Jelinek wrote:
> On 20/02/17 08:03, Andres Freund wrote:
> > On 2017-02-19 10:49:29 -0500, Tom Lane wrote:
> >> Robert Haas writes:
> >>> On Sun, Feb 19, 2017 at 3:31 AM, Tom Lane wrote:
> Thoughts? Should we double down on trying to make this
Hi
On Wed, Feb 22, 2017 at 4:52 PM, Stephen Frost wrote:
>> > > What about granting to the role to read other statistic views such as
>> > > pg_stat_replication and pg_stat_wal_receiver? Since these informations
>> > > can only be seen by superuser the for example monitoring and
>> > > clustering
On Wed, 2017-02-22 at 08:13 -0700, David G. Johnston wrote:
> I'll contribute to the popular demand aspect but given that the error
> is
> good and the fix is very simple its not exactly a strong desire.
In one project i've recently seen, for some reasons, they need to
maintain an application twic
On Wed, Feb 22, 2017 at 10:08:38AM -0500, Tom Lane wrote:
> Bernd Helmle writes:
> >> From time to time, especially during migration projects from Oracle to
> > PostgreSQL, i'm faced with people questioning why the alias in the FROM
> > clause for subqueries in PostgreSQL is mandatory. The default
All,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Feb 22, 2017 at 1:47 PM, Dave Page wrote:
> > On Tue, Feb 21, 2017 at 5:40 PM, Masahiko Sawada
> > wrote:
> > > On Mon, Feb 20, 2017 at 8:48 PM, Dave Page wrote:
> > >> Further to the patch I just submitted
> > >> (https://www.postgr
On Wed, Feb 22, 2017 at 10:25 AM, Rafia Sabih
wrote:
> Hello everybody,
>
> In the current version, queries in SQL or PL functions can not
> leverage parallelism. To relax this restriction I prepared a patch,
> the approach used in the patch is explained next,
Some initial comments.
--
i
On Wed, 2017-02-22 at 10:08 -0500, Tom Lane wrote:
>
> Indeed. When I wrote the comment you're referring to, quite a few
> years
> ago now, I thought that popular demand might force us to allow
> omitted
> aliases. But the demand never materialized. At this point it seems
> clear to me that the
On Wed, Feb 22, 2017 at 1:47 PM, Dave Page wrote:
>
> On Tue, Feb 21, 2017 at 5:40 PM, Masahiko Sawada
> wrote:
> > On Mon, Feb 20, 2017 at 8:48 PM, Dave Page wrote:
> >> Further to the patch I just submitted
> >> (https://www.postgresql.org/message-id/CA%2BOCxow-X%
> 3DD2fWdKy%2BHP%2BvQ1Ltrgbs
On Wed, Feb 22, 2017 at 06:33:10PM +1100, Robins Tharakan wrote:
> Stephen,
>
> On 20 February 2017 at 08:50, Stephen Frost wrote:
>
> > The other changes to use pg_roles instead of pg_authid when rolpassword
> > isn't being used look like they should just be changed to use pg_roles
> > instead
On Wed, Feb 22, 2017 at 04:51:46PM +0900, Amit Langote wrote:
> Attached patch fixes an oversight that tablesample cannot be used with
> partitioned tables:
>
> create table p (a int) partition by list (a);
> select * from p tablesample bernoulli (50);
> ERROR: TABLESAMPLE clause can only be appl
Andrew Dunstan writes:
> On 02/22/2017 10:21 AM, Jim Nasby wrote:
>> Only in the catalog though, not the datums, right? I would think you
>> could just change the oid in the catalog the same as you would for a
>> table column.
> No, in the datums.
Yeah, I don't see any way that we could fob off
On 02/22/2017 10:21 AM, Jim Nasby wrote:
> On 2/22/17 9:12 AM, Andres Freund wrote:
>>> That would allow an in-place upgrade of
>>> a really large cluster. A user would still need to modify their code
>>> to use
>>> the new type.
>>>
>>> Put another way: add ability for pg_upgrade to change the t
On 2/22/17 9:12 AM, Andres Freund wrote:
That would allow an in-place upgrade of
a really large cluster. A user would still need to modify their code to use
the new type.
Put another way: add ability for pg_upgrade to change the type of a field.
There might be other uses for that as well.
Type
>
> but if you think that it should be somewhere else, please advise Corey
> about where to put it.
Just a reminder that I'm standing by for advice.
The issue at hand is whether the if-state should be a part of the
PsqlScanState, or if it should be a separate state variable owned by
MainLoop()
On 2/22/17 7:56 AM, Peter Eisentraut wrote:
What behavior would we like by default? Refreshing a materialized view
is a pretty expensive operation, so I think scheduling an analyze quite
aggressively right afterwards is often what you want.
I think sending a stats message with the number of ins
On Wed, Feb 22, 2017 at 8:08 AM, Tom Lane wrote:
> Or else not generate
> a name at all, in which case there simply wouldn't be a way to refer to
> the subquery by name; I'm not sure what that might break though.
>
Yeah, usually when I want this I don't end up needing refer by name:
First I wr
On 2/22/17 2:51 AM, Pavel Stehule wrote:
The solution based on rights is elegant, but in this moment I cannot to
see all possible impacts on performance - because it means new check for
any call of any function. Maybe checking call stack can be good enough -
I have not idea how often use case it
On 2/22/17 8:00 AM, Peter Eisentraut wrote:
Actually, I think matviews really need to be the absolute last thing.
What if you had a matview that referenced publications or subscriptions?
I'm guessing that would be broken right now.
I'm not sure what you have in mind here. Publications and subsc
On Wed, Feb 22, 2017 at 8:08 AM, Tom Lane wrote:
> Bernd Helmle writes:
> >> From time to time, especially during migration projects from Oracle to
> > PostgreSQL, i'm faced with people questioning why the alias in the FROM
> > clause for subqueries in PostgreSQL is mandatory. The default answer
On 2017-02-22 09:06:38 -0600, Jim Nasby wrote:
> On 2/22/17 7:56 AM, Andres Freund wrote:
> > It sounded more like Jim suggested a full blown SQL type, given that he
> > replied to my concern about the possible need for a deprecation period
> > due to pg_upgrade concerns. To be useful for that, we
On 2/22/17 7:56 AM, Andres Freund wrote:
On 2017-02-22 08:43:28 -0500, Tom Lane wrote:
Andres Freund writes:
On 2017-02-22 00:10:35 -0600, Jim Nasby wrote:
I wounder if a separate "floatstamp" data type might fit the bill there. It
might not be completely seamless, but it would be binary comp
Bernd Helmle writes:
>> From time to time, especially during migration projects from Oracle to
> PostgreSQL, i'm faced with people questioning why the alias in the FROM
> clause for subqueries in PostgreSQL is mandatory. The default answer
> here is, the SQL standard requires it.
Indeed. When I
Hello Aleksander,
```
xloginsert.c:742:18: warning: implicit conversion from 'int' to 'char'
changes value from 253 to -3 [-Wconstant-conversion]
```
There is a bunch of these in "xlog.c" as well, and the same code is used
in "pg_resetwal.c".
Patch that fixes these warnings is attached to
Peter Eisentraut writes:
> There is support for COMMENT ON RULE without specifying a table
> name, for upgrading from pre-7.3 instances. I think it might be time
> for that workaround to go.
No objection here.
regards, tom lane
--
Sent via pgsql-hackers mailing list
>From time to time, especially during migration projects from Oracle to
PostgreSQL, i'm faced with people questioning why the alias in the FROM
clause for subqueries in PostgreSQL is mandatory. The default answer
here is, the SQL standard requires it.
This also is exactly the comment in our parser
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> While I'm generally not one to vote for dropping backwards-compatibility
>> features, I have to say that I find #4 the most attractive of these
>> options. It would result in getting rid of boatloads of under-tested
>> code, wherea
On 2/21/17 22:17, Andres Freund wrote:
> I've not run comparisons this year, but late last year I was seeing > 5%
> < 10% benefits - that seems plenty enough to care.
You mean the 5-minute benchmarks on my laptop are not representative? ;-)
Here is a patch that I had lying around that clears the
There is support for COMMENT ON RULE without specifying a table
name, for upgrading from pre-7.3 instances. I think it might be time
for that workaround to go.
Patch attached.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Trainin
On 23 January 2017 at 11:56, Ivan Kartyshov wrote:
> Thank you for reviews and suggested improvements.
> I rewrote patch to make it more stable.
>
> Changes
> ===
> I've made a few changes:
> 1) WAITLSN now doesn`t depend on snapshot
> 2) Check current replayed LSN rather than in xact_redo_com
On 6 January 2017 at 03:48, Andrew Gierth wrote:
> Herewith a patch for doing grouping sets via hashing or mixed hashing
> and sorting.
>
> The principal objective is to pick whatever combination of grouping sets
> has an estimated size that fits in work_mem, and minimizes the number of
> sorting
On 2/22/17 00:55, Jim Nasby wrote:
> Originally, no, but reviewing the list again I'm kindof wondering about
> DO_DEFAULT_ACL, especially since the acl code in pg_dump looks at
> defaults as part of what removes the need to explicitly dump
> permissions. I'm also wondering if DO_POLICY could pot
Tom, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> While I'm generally not one to vote for dropping backwards-compatibility
> features, I have to say that I find #4 the most attractive of these
> options. It would result in getting rid of boatloads of under-tested
> code, whereas #2 would really
On 2/22/17 06:31, Jim Mlodgenski wrote:
> Matviews already show up in the pg_stat_*_tables and the patch does
> leverage the existing pg_stat_*_tables underlying structure, but it
> creates more meaningful pg_stat_*_matviews leaving out things like
> insert and update counts.
But fields like seq
On 2017-02-22 08:43:28 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-02-22 00:10:35 -0600, Jim Nasby wrote:
> >> I wounder if a separate "floatstamp" data type might fit the bill there. It
> >> might not be completely seamless, but it would be binary compatible.
>
> > I don't really
On 2017-02-22 13:03, Petr Jelinek wrote:
0001-Skip-unnecessary-snapshot-builds.patch
0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch
0003-Fix-xl_running_xacts-usage-in-snapshot-builder.patch
0001-Use-asynchronous-connect-API-in-libpqwalreceiver.patch
0002-Fix-after-trigger-execut
Andres Freund writes:
> On 2017-02-22 00:10:35 -0600, Jim Nasby wrote:
>> I wounder if a separate "floatstamp" data type might fit the bill there. It
>> might not be completely seamless, but it would be binary compatible.
> I don't really see what'd that solve.
Seems to me this is a different na
Hello All,
I would like to propose the attached patch which removes all direct
references to ip_posid and ip_blkid members of ItemPointerData struct and
instead use ItemPointerGetOffsetNumber and ItemPointerGetBlockNumber macros
respectively to access these members.
My motivation to do this is to
On Wed, Feb 22, 2017 at 2:18 PM, Tom Lane wrote:
> I think this is really *not* a good idea. The entire permissions model
> is built around granting permissions to roles, by other roles.
My bad. I shouldn't have proposed the idea on how to achieve/implement the idea.
I should instead just have
Joel Jacobson writes:
> Currently, it's only possible to grant/revoke execute on functions to roles.
> I think it would be useful in many situations, both for documentation
> purposes,
> but also for increased security, to in a precise way control what
> other function(s) are allowed to execute
>
>> I am wondering whether we should deal with inh flat reset in a
>> slightly different way. Let expand_inherited_rtentry() mark inh =
>> false for the partitioned tables without any partitions and deal with
>> those at the time of estimating size by marking those as dummy. That
>> might be bette
Hi
On Tue, Feb 21, 2017 at 5:40 PM, Masahiko Sawada wrote:
> On Mon, Feb 20, 2017 at 8:48 PM, Dave Page wrote:
>> Further to the patch I just submitted
>> (https://www.postgresql.org/message-id/CA%2BOCxow-X%3DD2fWdKy%2BHP%2BvQ1LtrgbsYQ%3DCshzZBqyFT5jOYrFw%40mail.gmail.com)
>> I'd like to propose
On Wed, Feb 22, 2017 at 11:11 AM, Amit Langote
wrote:
> On 2017/02/22 13:46, Ashutosh Bapat wrote:
>> Looks good to me. In the attached patch I have added a comment
>> explaining the reason to make partition tables "Auto" dependent upon
>> the corresponding partitioned tables.
>
> Good call.
>
> +
Am Dienstag, den 21.02.2017, 11:17 +0100 schrieb Michael Banck:
> However, third party tools using the BASE_BACKUP command might want
> to
> extract the backup_label, e.g. in order to figure out the START WAL
> LOCATION. If they make a big tarball for the whole cluster
> potentially
> including all
1 - 100 of 110 matches
Mail list logo
