>> 3.
>> + longer satisfy the partition constraint of the containing partition. In
>> that
>> + case, if there is some other partition in the partition tree for which
>> this
>> + row satisfies its partition constraint, then the row is moved to that
>> + partition. If there isn't such a
On Fri, May 12, 2017 at 8:08 AM, Amit Langote
wrote:
> On 2017/05/12 11:20, Robert Haas wrote:
>> On Thu, May 11, 2017 at 10:15 PM, Amit Langote
>> wrote:
>>> On 2017/05/12 10:42, Robert Haas wrote:
On Thu, May 11, 2017 at 12:02
On 12 May 2017 at 08:30, Amit Kapila wrote:
> On Thu, May 11, 2017 at 5:41 PM, Amit Khandekar
> wrote:
>> On 11 May 2017 at 17:23, Amit Kapila wrote:
>>> On Fri, Mar 17, 2017 at 4:07 PM, Amit Khandekar
On 12 May 2017 at 10:01, Amit Kapila wrote:
> On Fri, May 12, 2017 at 9:27 AM, Amit Kapila wrote:
>> On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar
>> wrote:
>>> On 11 May 2017 at 17:24, Amit Kapila
On Fri, May 12, 2017 at 7:12 AM, Robert Haas wrote:
> On Thu, May 11, 2017 at 12:02 PM, Dilip Kumar wrote:
>> We need to add PARTITION_STRATEGY_HASH as well, we don't support NULL
>> for hash also, right?
>
> I think it should.
>
+1
As long as we
On Fri, May 12, 2017 at 1:28 PM, Tsunakawa, Takayuki
wrote:
> Likewise, when the first host has already reached max_connections, libpq
> doesn't attempt the connection aginst later hosts.
It seems to me that the feature is behaving as wanted. Or in short
attempt
On Fri, May 12, 2017 at 9:27 AM, Amit Kapila wrote:
> On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar
> wrote:
>> On 11 May 2017 at 17:24, Amit Kapila wrote:
>>> Few comments:
>>> 1.
>>> Operating directly on partition
Hi,
When I created a subscription with copydata option that corresponds to
a publication that includes several tables, I got the following log
messages.
[7019] LOG: starting logical replication worker for subscription "hoge_sub"
[7047] LOG: logical replication apply for subscription hoge_sub
Hello,
I found a problem with libpq connection failover. When libpq cannot connect to
earlier hosts in the host list, it doesn't try to connect to other hosts. For
example, when you specify a wrong port that some non-postgres program is using,
or some non-postgres program is using PG's port
https://www.postgresql.org/message-id/camp0ubeo3fzzefie1vmc1ajkkrpxlnzqooaseu6o-c+...@mail.gmail.com
In that thread, I pointed out some important considerations for the
hash functions themselves. This is a follow-up, after I looked more
carefully.
1. The hash functions as they exist today
On 5/11/17, 7:20 PM, "Michael Paquier" wrote:
> Browsing the code
Thanks for taking a look.
> It seems to me that you don't need those extra square brackets around
> the column list. Same remark for vacuum.sgml.
I’ll remove them. My intent was to ensure that we
Andres Freund writes:
> On 2017-05-11 17:21:18 -0400, Tom Lane wrote:
>> I doubt my machine is 6X faster than yours,
>> so this indicates that the subtransaction overhead is pretty real.
> Isn't that pretty much the point? The whole open_share_lock()
> optimization looks
On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar wrote:
> On 11 May 2017 at 17:24, Amit Kapila wrote:
>> Few comments:
>> 1.
>> Operating directly on partition doesn't allow update to move row.
>> Refer below example:
>> create table t1(c1 int)
Michael Paquier writes:
> Bruce, the release notes do not mention yet that support for cleartext
> passwords is removed. This has been done recently by Heikki in
> eb61136d. This has as consequence that CREATE ROLE PASSWORD
> UNENCRYPTED returns an error, and that
Robert Haas writes:
> On Wed, May 10, 2017 at 8:39 PM, Masahiko Sawada
> wrote:
>> ... I'd like to propose to change relation
>> extension lock management so that it works using LWLock instead.
> That's not a good idea because it'll make the code
On Mon, May 8, 2017 at 10:50 PM, Bruce Momjian wrote:
> [other stuff]
Bruce, the release notes do not mention yet that support for cleartext
passwords is removed. This has been done recently by Heikki in
eb61136d. This has as consequence that CREATE ROLE PASSWORD
UNENCRYPTED
On Wed, May 10, 2017 at 10:21 PM, Amit Langote
wrote:
>> Next update on this issue by Thursday 5/11.
>
> Attached updated patches.
Thanks. 0001, at least, really needs a pgindent run. Also, my
compiler has this apparently-justifiable complaint:
Neha Khatri writes:
> On Fri, May 12, 2017 at 12:56 AM, Tom Lane wrote:
>> Neha Khatri writes:
>>> Following are pg_controldata interfaces that might require change:
>>> Latest checkpoint location:
>>> Prior checkpoint location:
On Thu, May 11, 2017 at 5:41 PM, Amit Khandekar wrote:
> On 11 May 2017 at 17:23, Amit Kapila wrote:
>> On Fri, Mar 17, 2017 at 4:07 PM, Amit Khandekar
>> wrote:
>>> On 4 March 2017 at 12:49, Robert Haas
Alvaro Herrera writes:
> Hmm, yeah, makes sense. Here's a patch for this approach.
I did some code review on this patch. The attached update makes the
following hopefully-uncontroversial changes:
* fix inconsistencies in the set of fields in CreateStatsStmt
* get
On Thu, May 11, 2017 at 10:48 AM, Michael Paquier
wrote:
> Hi all,
>
> I had my eyes on the WAL sender code this morning, and I have noticed
> that walsender.c is not completely consistent with the PID lookups it
> does in walsender.c. In two code paths, the PID value
On Thu, May 11, 2017 at 10:07 AM, Rahila Syed wrote:
> Please find attached an updated patch with review comments and bugs reported
> till date implemented.
You haven't done anything about the repeated suggestion that this
should also cover range partitioning.
+
On 2017/05/12 11:20, Robert Haas wrote:
> On Thu, May 11, 2017 at 10:15 PM, Amit Langote
> wrote:
>> On 2017/05/12 10:42, Robert Haas wrote:
>>> On Thu, May 11, 2017 at 12:02 PM, Dilip Kumar wrote:
We need to add PARTITION_STRATEGY_HASH
On Fri, May 12, 2017 at 12:56 AM, Tom Lane wrote:
> Neha Khatri writes:
> > [In case forgotten] pg_controdata and pg_waldump interfaces should also
> be
> > considered for this standardization.
>
> > Following are pg_controldata interfaces that might
On Thu, May 11, 2017 at 6:16 PM, Petr Jelinek
wrote:
> On 11/05/17 10:10, Masahiko Sawada wrote:
>> On Thu, May 11, 2017 at 4:06 PM, Michael Paquier
>> wrote:
>>> On Wed, May 10, 2017 at 11:57 AM, Masahiko Sawada
On Thu, May 11, 2017 at 10:15 PM, Amit Langote
wrote:
> On 2017/05/12 10:42, Robert Haas wrote:
>> On Thu, May 11, 2017 at 12:02 PM, Dilip Kumar wrote:
>>> We need to add PARTITION_STRATEGY_HASH as well, we don't support NULL
>>> for hash
On Fri, May 12, 2017 at 9:47 AM, Bossart, Nathan wrote:
> Attached is a more complete first attempt at adding this functionality. I
> added two node types: one for parsing the “relation and columns” list in the
> grammar, and one for holding the relation information we
On 2017/05/12 10:42, Robert Haas wrote:
> On Thu, May 11, 2017 at 12:02 PM, Dilip Kumar wrote:
>> We need to add PARTITION_STRATEGY_HASH as well, we don't support NULL
>> for hash also, right?
>
> I think it should.
>
> Actually, I think that not supporting nulls for
On Thu, May 11, 2017 at 3:19 PM, Michael Paquier
wrote:
> I imagine that pg_dump -s would be the basic operation that users
> would do first before creating a subcription on a secondary node, but
> what I find surprising is that publications are dumped by default. I
>
On Wed, May 10, 2017 at 8:39 PM, Masahiko Sawada wrote:
> Currently, the relation extension lock is implemented using
> heavyweight lock manager and almost functions (except for
> brin_page_cleanup) using LockRelationForExntesion use it with
> ExclusiveLock mode. But
On Thu, May 11, 2017 at 9:33 AM, Tom Lane wrote:
> Uh ... what in that is creating the already-extant parent?
/me looks embarrassed.
Never mind. I didn't read what you wrote carefully enough.
>> I think one answer to the original complaint might be to add a new
>> flag to
On 5/11/17, 6:32 PM, "Tom Lane" wrote:
> You probably won't get much in the near term, because we're in
> stabilize-the-release mode not develop-new-features mode.
> Please add your patch to the pending commitfest
> https://commitfest.postgresql.org/14/
> so that we remember
On Thu, May 11, 2017 at 12:02 PM, Dilip Kumar wrote:
> We need to add PARTITION_STRATEGY_HASH as well, we don't support NULL
> for hash also, right?
I think it should.
Actually, I think that not supporting nulls for range partitioning may
have been a fairly bad decision.
Of course, better thoughts appear immediately after hitting the send button.
This version of the table attempts to stipulate which section of the
process the rule applies to.
On Thu, May 11, 2017 at 8:40 PM, Rod Taylor wrote:
> I think the biggest piece missing is
"Bossart, Nathan" writes:
> Looking forward to any feedback that you have.
You probably won't get much in the near term, because we're in
stabilize-the-release mode not develop-new-features mode.
Please add your patch to the pending commitfest
On 2017-05-11 14:54:26 -0700, Andres Freund wrote:
> On 2017-05-11 14:51:55 -0700, wrote:
> > On 2017-05-08 00:10:12 -0700, Andres Freund wrote:
> > > I plan to commit the next pending patch after the back branch releases
> > > are cut - it's an invasive fix and the issue doesn't cause corruption
On Thu, May 11, 2017 at 10:41:45PM +0300, Konstantin Knizhnik wrote:
> This is why I have provided second implementation which replace
> literals with parameters after raw parsing. Certainly it is slower
> than first approach. But still provide significant advantage in
> performance: more than
I think the biggest piece missing is something to summarize the giant
blocks of text.
Attached is a table that has commands and policy types, and a "yes" if it
applies.
--
Rod Taylor
diff --git a/doc/src/sgml/ref/create_policy.sgml b/doc/src/sgml/ref/create_policy.sgml
index
On Mon, May 1, 2017 at 6:39 PM, Peter Geoghegan wrote:
> On Mon, May 1, 2017 at 6:20 PM, Tom Lane wrote:
>> Maybe you can fix this by assuming that your own session's advertised xmin
>> is a safe upper bound on everybody else's RecentGlobalXmin. But I'm not
>>
Alvaro Herrera writes:
> BTW the new castNode() family of macros don't work with Value nodes
> (because the tags are different depending on what's stored, but each
> type does not have its own struct. Oh well.)
Yeah. Value nodes are pretty much of a wart --- it's not
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Have you thought further about the upthread suggestion to just borrow
> >> SELECT's syntax lock stock and barrel?
>
> > Bison seems to like the productions below. Is this what you had in
> > mind? These
On 2017-04-15 05:18:49 +0200, Petr Jelinek wrote:
> >>> From 3318a929e691870f3c1ca665bec3bfa8ea2af2a8 Mon Sep 17 00:00:00 2001
> >>> From: Petr Jelinek
> >>> Date: Sun, 26 Feb 2017 01:07:33 +0100
> >>> Subject: [PATCH 3/5] Prevent snapshot builder xmin from going backwards
>
On 2017-05-11 14:51:55 -0700, wrote:
> On 2017-05-08 00:10:12 -0700, Andres Freund wrote:
> > I plan to commit the next pending patch after the back branch releases
> > are cut - it's an invasive fix and the issue doesn't cause corruption
> > "just" slow slot creation. So it seems better to wait
On Thu, May 11, 2017 at 2:51 PM, Andres Freund wrote:
> Now that that's done, here's an updated version of that patch. Note the
> new logic to trigger xl_running_xact's to be logged at the right spot.
> Works well in my testing.
You forgot the patch. :-)
--
Peter
On 2017-05-08 00:10:12 -0700, Andres Freund wrote:
> I plan to commit the next pending patch after the back branch releases
> are cut - it's an invasive fix and the issue doesn't cause corruption
> "just" slow slot creation. So it seems better to wait for a few days,
> rather than hurry it into
Ilya Shkuratov wrote
> First of all, to such replacement to be valid, the CTE must be
> 1. non-writable (e.g. be of form: SELECT ...),
> 2. do not use VOLATILE or STABLE functions,
> 3. ... (maybe there must be more restrictions?)
What about simple things like this?
CREATE OR
On 2017-05-11 17:21:18 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > I ran this script
>
> > CREATE SEQUENCE seq1;
>
> > DO LANGUAGE plpythonu $$
> > plan = plpy.prepare("SELECT nextval('seq1')")
> > for i in range(0, 1000):
> >
Andres Freund writes:
> On 2017-05-11 16:27:48 -0400, Peter Eisentraut wrote:
>> (So without contention fast-path locking beats the extra dance that
>> open_share_lock() does.)
> That's kind of surprising, I really wouldn't have thought it'd be faster
> without. I guess it's
Peter Eisentraut writes:
> I ran this script
> CREATE SEQUENCE seq1;
> DO LANGUAGE plpythonu $$
> plan = plpy.prepare("SELECT nextval('seq1')")
> for i in range(0, 1000):
> plpy.execute(plan)
> $$;
> and timed the "DO".
It occurred to me that
Hi,
On 2017-05-11 16:27:48 -0400, Peter Eisentraut wrote:
> On 5/10/17 12:24, Andres Freund wrote:
> > Upthread I theorized whether
> > that's actually still meaningful given fastpath locking and such, but I
> > guess we'll have to evaluate that.
>
> I did some testing.
That's with the
Peter Eisentraut writes:
> On 5/10/17 12:24, Andres Freund wrote:
>> Upthread I theorized whether
>> that's actually still meaningful given fastpath locking and such, but I
>> guess we'll have to evaluate that.
> [ with or without contention, fast-path locking
On 2017-05-11 11:35:22 -0400, Peter Eisentraut wrote:
> On 5/10/17 12:24, Andres Freund wrote:
> > The issue isn't the strength, but that we currently have this weird
> > hackery around open_share_lock():
> > /*
> > * Open the sequence and acquire AccessShareLock if needed
> > *
> > * If we
On 05/11/2017 10:52 PM, Andres Freund wrote:
On 2017-05-11 22:48:26 +0300, Konstantin Knizhnik wrote:
On 05/11/2017 09:31 PM, Tom Lane wrote:
Bruce Momjian writes:
Good point. I think we need to do some measurements to see if the
parser-only stage is actually significant.
On 5/10/17 12:24, Andres Freund wrote:
> Upthread I theorized whether
> that's actually still meaningful given fastpath locking and such, but I
> guess we'll have to evaluate that.
I did some testing.
I ran this script
CREATE SEQUENCE seq1;
DO LANGUAGE plpythonu $$
plan = plpy.prepare("SELECT
On 2017-05-11 22:48:26 +0300, Konstantin Knizhnik wrote:
> On 05/11/2017 09:31 PM, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Good point. I think we need to do some measurements to see if the
> > > parser-only stage is actually significant. I have a hunch that
> > >
Alvaro Herrera writes:
> Tom Lane wrote:
>> Have you thought further about the upthread suggestion to just borrow
>> SELECT's syntax lock stock and barrel?
> Bison seems to like the productions below. Is this what you had in
> mind? These mostly mimic joined_table and
On 05/11/2017 09:31 PM, Tom Lane wrote:
Bruce Momjian writes:
Good point. I think we need to do some measurements to see if the
parser-only stage is actually significant. I have a hunch that
commercial databases have much heavier parsers than we do.
FWIW, gram.y does show
On 05/11/2017 06:12 PM, Bruce Momjian wrote:
On Wed, May 10, 2017 at 07:11:07PM +0300, Konstantin Knizhnik wrote:
I am going to continue work on this patch I will be glad to receive any
feedback and suggestions for its improvement.
In most cases, applications are not accessing Postgres
Tom Lane wrote:
> Have you thought further about the upthread suggestion to just borrow
> SELECT's syntax lock stock and barrel? That is, it'd look something
> like
>
> CREATE STATISTICS name [(list of stats types)] expression-list FROM ...
> [ WHERE ... ] [ WITH (options) ]
>
> This would
On May 11, 2017 11:31:02 AM PDT, Tom Lane wrote:
>Bruce Momjian writes:
>> Good point. I think we need to do some measurements to see if the
>> parser-only stage is actually significant. I have a hunch that
>> commercial databases have much heavier
Bruce Momjian writes:
> Good point. I think we need to do some measurements to see if the
> parser-only stage is actually significant. I have a hunch that
> commercial databases have much heavier parsers than we do.
FWIW, gram.y does show up as significant in many of the
2017-05-11 4:23 GMT-03:00 Friedrich, Steffen <
steffen.friedr...@dieboldnixdorf.com>:
> I am writing a logical decoding output plugin decoding WAL to SQL which is
> finally applied to target database.
>
>
>
> Is it possible to decode a TRUNCATE statement and the tables involved?
>
>
Yes, use
On Thu, May 11, 2017 at 05:39:58PM +, Douglas Doole wrote:
> One interesting idea from Doug Doole was to do it between the tokenizer
> and
> parser. I think they are glued together so you would need a way to run
> the
> tokenizer separately and compare that to the tokens you
On Thu, May 11, 2017 at 05:24:16PM +0200, Remi Colinet wrote:
> 2017-05-10 21:52 GMT+02:00 David Fetter :
>
> > On Wed, May 10, 2017 at 06:40:31PM +0200, Remi Colinet wrote:
> > > Hello,
> > >
> > > This is version 2 of the new command name PROGRESS which I wrote in
> > > order
>
> One interesting idea from Doug Doole was to do it between the tokenizer
> and parser. I think they are glued together so you would need a way to run
> the tokenizer separately and compare that to the tokens you stored for the
> cached plan.
>
When I did this, we had the same problem that the
On 11 May 2017 at 18:13, Andres Freund wrote:
>>New patch, v3.
>>
>>Applying in 90 minutes, barring objections.
>
> Could you please wait till tomorrow? I've bigger pending fixes for related
> code pending/being tested that I plan to push today. I'd also like to take a
>
Tom Lane wrote:
> Have you thought further about the upthread suggestion to just borrow
> SELECT's syntax lock stock and barrel? That is, it'd look something
> like
>
> CREATE STATISTICS name [(list of stats types)] expression-list FROM ...
> [ WHERE ... ] [ WITH (options) ]
>
> This would
Simon Riggs writes:
> On 11 May 2017 at 17:41, Tom Lane wrote:
>> ...because code that worked fine for Peter and me failed
>> erratically in the buildfarm.
> I think its always a little bit too exciting for me also.
> I suggest we have a commit tree
Alvaro Herrera writes:
> Tom Lane wrote:
>> Hmm ... I'm not sure that I buy that particular argument. If you're
>> concerned that the grammar could not handle "FROM x JOIN y USING (z)",
>> wouldn't it also have a problem with "FROM x JOIN y ON (z)"?
> Tomas spent some
On May 11, 2017 8:08:11 AM PDT, Simon Riggs wrote:
>On 11 May 2017 at 14:12, Petr Jelinek
>wrote:
>
>>> Attached patch is Petr's patch, slightly rebased with added pacing
>>> delay, similar to that used by HSFeedback.
>>>
>>
>> This looks
Tom Lane wrote:
> Hmm ... I'm not sure that I buy that particular argument. If you're
> concerned that the grammar could not handle "FROM x JOIN y USING (z)",
> wouldn't it also have a problem with "FROM x JOIN y ON (z)"?
>
> It might work anyway, since the grammar should know whether ON or
On 11 May 2017 at 17:41, Tom Lane wrote:
> ...because code that worked fine for Peter and me failed
> erratically in the buildfarm.
I think its always a little bit too exciting for me also.
I suggest we have a commit tree and a main tree, with automatic
copying from commit
2017-05-11 17:16 GMT+02:00 Daniel Verite :
> Pavel Stehule wrote:
>
> > It is similar to my first or second proposal - rejected by Tom :(
>
> Doesn't it differ? ISTM that in the patches/discussion related to:
> https://commitfest.postgresql.org/11/787/
> it was
Heikki Linnakangas writes:
> On 05/11/2017 06:21 PM, Tom Lane wrote:
>>> On a side-note, I find it a bit awkward that ScalarArrayOpExpr uses a
>>> 2-element List to hold the scalar and array arguments. Wouldn't it be
>>> much more straightforward to have explicit "Expr
Monday's round of security patches was a lot more exciting than I would
have liked, because code that worked fine for Peter and me failed
erratically in the buildfarm. What eventually emerged was that I'd added
some missing free_attstatsslot() calls in rangetypes_selfuncs.c, and
naively copied
On 05/11/2017 06:21 PM, Tom Lane wrote:
Heikki Linnakangas writes:
Eval_const_expressions() doesn't know about ScalarArrayOpExpr.
...
That seems like an oversight. I guess that scenario doesn't happen very
often in practice, but there's no reason not to do it when it does.
Thx for your comment.
Based on other comments, I will probably convert the command into a SQL
function.
This allows passing arguments such as the one which can be used in the
current command (VERBOSE, FORMAT).
This will avoid keyword collisions.
Regards
Remi
2017-05-10 22:04 GMT+02:00 Pavel
2017-05-11 4:05 GMT+02:00 Michael Paquier :
> On Thu, May 11, 2017 at 1:40 AM, Remi Colinet
> wrote:
> > This is version 2 of the new command name PROGRESS which I wrote in
> order to
> > monitor long running SQL queries in a Postgres backend
On Wed, May 3, 2017 at 6:39 PM, amul sul wrote:
> On Thu, Apr 27, 2017 at 1:42 AM, Robert Haas wrote:
>
>>I spent some time today looking at these patches. It seems like there
>>is some more work still needed here to produce something committable
Peter Eisentraut writes:
> Most documentation and error messages still uses the term "transaction
> log" to refer to the write-ahead log. Here is a patch to rename that,
> which I think should be done, to match the xlog -> wal renaming in APIs.
This will need
On 5/10/17 12:24, Andres Freund wrote:
> The issue isn't the strength, but that we currently have this weird
> hackery around open_share_lock():
> /*
> * Open the sequence and acquire AccessShareLock if needed
> *
> * If we haven't touched the sequence already in this transaction,
> * we need
That's good point.
I will probably convert the new command to a SQL function.
I was fumbling between a table or a SQL function. Oracle uses
v$session_longops to track progression of long running SQL queries which
have run for more than 6 seconds.
But a function is much better to provide
Heikki Linnakangas writes:
> Eval_const_expressions() doesn't know about ScalarArrayOpExpr.
> ...
> That seems like an oversight. I guess that scenario doesn't happen very
> often in practice, but there's no reason not to do it when it does.
> Patch attached.
Yeah, I think
Pavel Stehule wrote:
> It is similar to my first or second proposal - rejected by Tom :(
Doesn't it differ? ISTM that in the patches/discussion related to:
https://commitfest.postgresql.org/11/787/
it was proposed to change \set in one way or another,
and also in the point #1 of this
On Wed, May 10, 2017 at 07:11:07PM +0300, Konstantin Knizhnik wrote:
> I am going to continue work on this patch I will be glad to receive any
> feedback and suggestions for its improvement.
> In most cases, applications are not accessing Postgres directly, but using
> some connection pooling
On 11 May 2017 at 14:12, Petr Jelinek wrote:
>> Attached patch is Petr's patch, slightly rebased with added pacing
>> delay, similar to that used by HSFeedback.
>>
>
> This looks reasonable. I would perhaps change:
>> + /*
>> +* Track lag no more than
Eval_const_expressions() doesn't know about ScalarArrayOpExpr. We
simplify the arguments, but if all the arguments are booleans, we don't
take the obvious step of replacing the whole expression with a boolean
Const. For example:
postgres=# explain select * from foo where 1 IN (1,2,3);
On 11/05/17 16:33, Stas Kelvich wrote:
>
>> On 10 May 2017, at 11:43, Petr Jelinek wrote:
>>
>> On 09/05/17 22:11, Erik Rijkers wrote:
>>> On 2017-05-09 21:00, Petr Jelinek wrote:
On 09/05/17 19:54, Erik Rijkers wrote:
> On 2017-05-09 11:50, Petr Jelinek
Neha Khatri writes:
> [In case forgotten] pg_controdata and pg_waldump interfaces should also be
> considered for this standardization.
> Following are pg_controldata interfaces that might require change:
> Latest checkpoint location:
> Prior checkpoint location:
>
Michael Paquier writes:
> On Thu, May 11, 2017 at 9:15 AM, Bruce Momjian wrote:
>> On Wed, May 10, 2017 at 01:09:36PM -0700, Joe Conway wrote:
> On 05/10/2017 12:22 PM, Tom Lane wrote:
>>> Hm, well, anybody else want to vote?
>>> +1 for #2
>> Same,
> On 10 May 2017, at 11:43, Petr Jelinek wrote:
>
> On 09/05/17 22:11, Erik Rijkers wrote:
>> On 2017-05-09 21:00, Petr Jelinek wrote:
>>> On 09/05/17 19:54, Erik Rijkers wrote:
On 2017-05-09 11:50, Petr Jelinek wrote:
>>>
>>> Ah okay, so this is same
Hello,
Please find attached an updated patch with review comments and bugs
reported till date implemented.
>1.
>In following block, we can just do with def_index, and we do not need
found_def
>flag. We can check if def_index is -1 or not to decide if default partition
is
>present.
found_def is
Hi,
On 11/05/17 14:25, tushar wrote:
> Hi,
>
> I observed that -we cannot publish "foreign table" in Publication
>
> postgres=# create foreign table t (n int) server db1_server options
> (table_name 't1');
> CREATE FOREIGN TABLE
>
> postgres=# create publication pub for table t;
> ERROR: "t"
That's a good point.
A command is more straightforward because it targets only one backend.
The user is supposed to know which backend pid is taking a long time to
complete based on pg_stat_activity().
This is somehow the same approach as EXPLAIN command.
But the use is limited to psql utility.
Robert Haas writes:
> On Thu, May 11, 2017 at 9:02 AM, Tom Lane wrote:
>> You could argue that it would be better for pg_dump to emit something
>> like
>>
>> CREATE TABLE c (...);
>> ALTER TABLE c INHERIT p;
>>
>> so that if p isn't around, at least c
On Thu, May 11, 2017 at 8:25 AM, tushar wrote:
> I observed that -we cannot publish "foreign table" in Publication
>
> postgres=# create foreign table t (n int) server db1_server options
> (table_name 't1');
> CREATE FOREIGN TABLE
>
> postgres=# create publication
Do you have more details about the failed tests?
Regards,
Remi
2017-05-06 5:38 GMT+02:00 Vinayak Pokale :
>
> On Mon, Apr 17, 2017 at 9:09 PM, Remi Colinet
> wrote:
>
>> Hello,
>>
>> I've implemented a new command named PROGRESS to monitor
On Thu, May 11, 2017 at 3:38 AM, Noah Misch wrote:
> This PostgreSQL 10 open item is past due for your status update. Kindly send
> a status update within 24 hours, and include a date for your subsequent status
> update. Refer to the policy on open item ownership:
>
Heikki Linnakangas writes:
> I updated the List of Drivers in the Wiki. I added a few drivers that
> were missing, like the ODBC driver, and the pgtclng driver, as well as a
> Go and Rust driver that I'm aware of. I reformatted it, and added a
> column to indicate whether each
On Thu, May 11, 2017 at 9:02 AM, Tom Lane wrote:
> Jeevan Ladhe writes:
>> On Thu, May 11, 2017 at 4:47 PM, Ashutosh Bapat <
>>> We add PARTITION OF clause for a table which is partition, so if the
>>> parent is not present while restoring, the
1 - 100 of 128 matches
Mail list logo