Hello,
I didn't realize that my target_session_attrs naming proposal was committed. I
didn't think half way it would be adopted, because the name is less intuitive
than the original target_server_type, and is different from the PgJDBC's
targetServerType.
From: pgsql-hackers-ow...@postgresql.
2017-04-13 11:30 GMT+05:00 Jeff Davis :
> I don't quite follow. I don't think any of these proposals uses btree,
> right? Range merge join doesn't need any index, your proposal uses
> gist, and PgSphere's crossmatch uses gist.
Merge join will use presorted data, B-tree provides sorted data.
Merge
On 13 April 2017 at 14:59, Tsunakawa, Takayuki
wrote:
> 2. Make transaction_read_only GUC_REPORT
> This is to avoid the added round-trip by SHOW command. It also benefits
> client apps that want to know when the server gets promoted? And this may
> simplify the libpq code.
> I don't understan
Sorry for the too-brief reply.
At Tue, 11 Apr 2017 20:08:46 +0300, Konstantin Knizhnik
wrote in
<94c8692a-f299-b72b-6227-270b8a9ed...@postgrespro.ru>
>
> On 04.04.2017 13:29, Kyotaro HORIGUCHI wrote:
> > Hi,
> >
> > At Sun, 02 Apr 2017 16:30:24 +0300, Konstantin Knizhnik
> > wrote in <58e0fcf
Hello,
At Thu, 6 Apr 2017 16:17:31 +0900, Masahiko Sawada
wrote in
> On Thu, Apr 6, 2017 at 10:51 AM, Noah Misch wrote:
> > On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote:
> >> On Wed, Apr 5, 2017 at 3:45 PM, Noah Misch wrote:
> >> > On Mon, Dec 19, 2016 at 09:49:58PM +0900, Fuji
Attached patch modifies a sentence in the inval.c header comment to
mention that operations on a pg_index tuple also registers relcache flush
operation.
Thanks,
Amit
diff --git a/src/backend/utils/cache/inval.c b/src/backend/utils/cache/inval.c
index 8159ab340d..9d62544554 100644
--- a/src/backend
On 13 April 2017 at 09:27, Amit Langote wrote:
> Attached patch modifies a sentence in the inval.c header comment to
> mention that operations on a pg_index tuple also registers relcache flush
> operation.
Correctly observed. Patch pushed.
--
Simon Riggshttp://www.2ndQuadrant.co
On 2017/04/13 18:09, Simon Riggs wrote:
> On 13 April 2017 at 09:27, Amit Langote wrote:
>> Attached patch modifies a sentence in the inval.c header comment to
>> mention that operations on a pg_index tuple also registers relcache flush
>> operation.
>
> Correctly observed. Patch pushed.
Thanks.
At Thu, 13 Apr 2017 13:52:40 +0900, Michael Paquier
wrote in
> On Tue, Apr 11, 2017 at 5:38 PM, Kyotaro HORIGUCHI
> wrote:
> > Sorry, what I have just sent was broken.
>
> You can use PROVE_TESTS when running make check to select a subset of
> tests you want to run. I use that all the time whe
On Thu, Apr 13, 2017 at 2:40 AM, Andres Freund wrote:
> On 2017-04-12 20:15:52 -0400, Peter Eisentraut wrote:
> > On 4/11/17 05:15, Magnus Hagander wrote:
> > > Is there a particular reason we don't have a function to *set* the
> > > restart_lsn of a replication slot, other than to drop it and re
Hi.
I got errors of patching on CentOS 7:
bash-4.2$ grep Hunk *.log | grep FAILED
0005-hj-leader-gate-v11.patch.log:Hunk #1 FAILED at 14.
0010-hj-parallel-v11.patch.log:Hunk #2 FAILED at 2850.
0010-hj-parallel-v11.patch.log:Hunk #1 FAILED at 21.
0010-hj-parallel-v11.patch.log:Hunk #3 FAILED at 62
I wonder if trying to add a relation to a publication that it is already a
part should be considered a no-op, instead of causing an error (which
happens in the ALTER PUBLICATION ADD TABLES case).
create table bar (a int);
create publication mypub for table bar;
alter publication mypub add table ba
On Thu, Apr 13, 2017 at 11:53 AM, Masahiko Sawada wrote:
> On Wed, Apr 12, 2017 at 11:46 PM, Peter Eisentraut
> wrote:
>> On 4/12/17 00:48, Masahiko Sawada wrote:
>>> On Wed, Apr 12, 2017 at 1:28 PM, Peter Eisentraut
Perhaps instead of a global last_start_time, we store a per relation
l
On 4/6/17, Vitaly Burovoy wrote:
> On 4/6/17, Peter Eisentraut wrote:
>> As I tried to mention earlier, it is very difficult to implement the IF
>> NOT EXISTS behavior here, because we need to run the commands the create
>> the sequence before we know whether we will need it.
>
> In fact with the
On 4/4/17, Peter Eisentraut wrote:
> On 3/30/17 22:47, Vitaly Burovoy wrote:
>> It seemed not very hard to fix it.
>> Please find attached patch to be applied on top of your one.
>>
>> I've added more tests to cover different cases of changing bounds when
>> data type is changed.
>
> Committed all
On Thu, Apr 13, 2017 at 10:04 PM, Oleg Golovanov wrote:
> bash-4.2$ grep Hunk *.log | grep FAILED
> 0005-hj-leader-gate-v11.patch.log:Hunk #1 FAILED at 14.
> 0010-hj-parallel-v11.patch.log:Hunk #2 FAILED at 2850.
> 0010-hj-parallel-v11.patch.log:Hunk #1 FAILED at 21.
> 0010-hj-parallel-v11.patch.l
On 2017/04/13 0:10, Robert Haas wrote:
> On Wed, Apr 5, 2017 at 8:25 AM, Peter Eisentraut
> wrote:
>> After thinking about it some more, I think the behavior we want would be
>> that changes to inheritance would reflect in the publication membership.
>> So if you have a partitioned table, adding
I confused sync and apply workers.
sync worker failure at start causes immediate retries.
At Thu, 13 Apr 2017 11:53:27 +0900, Masahiko Sawada
wrote in
> On Wed, Apr 12, 2017 at 11:46 PM, Peter Eisentraut
> wrote:
> > On 4/12/17 00:48, Masahiko Sawada wrote:
> >> On Wed, Apr 12, 2017 at 1:28 PM
Ouch! I replied to wrong mail.
At Thu, 13 Apr 2017 19:55:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170413.195504.89348773.horiguchi.kyot...@lab.ntt.co.jp>
> I confused sync and apply workers.
> sync worker failure at start causes immediate retries.
>
> At Thu, 13 Apr 2017 1
On 04/13/2017 05:54 AM, Michael Paquier wrote:
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
wrote:
By looking at the them, and unless I'm missing something, I don't see
how the extra information for the future implementation of channel binding
would be added (without changing t
On 13/04/17 13:24, Heikki Linnakangas wrote:
On 04/13/2017 05:54 AM, Michael Paquier wrote:
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
wrote:
By looking at the them, and unless I'm missing something, I
don't see
how the extra information for the future implementation of ch
On 13/04/17 04:54, Michael Paquier wrote:
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
wrote:
By looking at the them, and unless I'm missing something, I don't see
how the extra information for the future implementation of channel binding
would be added (without changing the
On 04/13/2017 02:35 PM, Álvaro Hernández Tortosa wrote:
On 13/04/17 13:24, Heikki Linnakangas wrote:
Right, when we get channel binding, the server will list
"SCRAM-SHA-256" and "SCRAM-SHA-256-PLUS" as the list of mechanisms.
And if we get channel binding using something else than tls-unique,
th
My only desire would be to have a final spec and implement the full parser
now, not have to change it in the future. We already know today all the
requirements, so please pick one and I will follow it :)
On Apr 13, 2017 13:47, "Heikki Linnakangas" wrote:
> On 04/13/2017 02:35 PM, Álvaro Hernán
On Thu, Apr 13, 2017 at 5:17 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Thu, 6 Apr 2017 16:17:31 +0900, Masahiko Sawada
> wrote in
>> On Thu, Apr 6, 2017 at 10:51 AM, Noah Misch wrote:
>> > On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote:
>> >> On Wed, Apr 5, 2017 at 3:45 PM, Noa
Tomas Vondra writes:
> On 04/12/2017 03:36 PM, David Rowley wrote:
>> "stakind" seems like a better name. I'd have personally gone with
>> "statype" but pg_statistic already thinks stakind is better.
> +1 to stakind
I agree with that, but as long as we're rethinking column names here,
was it a g
Aleksander,
> What you actually meant probably was "do so on ALL standby servers
> first", right?
Good point, right now it can give you the idea that applying it to just
1 standby (instead of all of them) is good enough, when instead you
need to apply it to all of them.
Attached is an adjusted v
Amit Langote writes:
> I wonder if trying to add a relation to a publication that it is already a
> part should be considered a no-op, instead of causing an error (which
> happens in the ALTER PUBLICATION ADD TABLES case).
On what grounds?
The equivalent case for inheritance is an error:
regres
On 04/13/2017 03:28 PM, Tom Lane wrote:
Tomas Vondra writes:
On 04/12/2017 03:36 PM, David Rowley wrote:
"stakind" seems like a better name. I'd have personally gone with
"statype" but pg_statistic already thinks stakind is better.
+1 to stakind
I agree with that, but as long as we're ret
Hello Robert,
My 0.02€ about your interesting questions and points.
On Sun, Apr 2, 2017 at 3:56 PM, Tom Lane wrote:
So my view of this is that "send the expression to the server" ought
to be just one option for \if, not the only way to do it.
I heartily agree. There should be some kind of
On Thu, Apr 13, 2017 at 9:33 PM, Tom Lane wrote:
> Amit Langote writes:
>> I wonder if trying to add a relation to a publication that it is already a
>> part should be considered a no-op, instead of causing an error (which
>> happens in the ALTER PUBLICATION ADD TABLES case).
>
> On what grounds?
Tomas Vondra wrote:
> On 04/10/2017 12:12 PM, David Rowley wrote:
> > During my review and time spent working on the functional dependencies
> > part of extended statistics I wondered what was the use for the
> > pg_stats_ext view. I was unsure why the length of the serialised
> > dependencies was
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> So I think I was indeed confused before, and I think you're basically
> right here, but on one point I think you are not right -- ALTER TABLE
> ONLY .. CHECK () doesn't work on a table with inheritance children
> regardless of whether the chil
Pavel Stehule wrote:
> Hi
>
> I am sending a patch with changes in XMLTABLE documentation proposed by
> Arjen.
Thanks, pushed with some rewording.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via p
Arjen Nienhuis wrote:
> Hi,
>
> In the devel docs for xmltable there should be a comma after XMLNAMESPACES()
Thanks, pushed.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing l
Arjen Nienhuis wrote:
> It wasn't completely clear for me how to use namespaces in xmltable().
> Maybe add this to the documentation. It shows the default namespace
> and quoting the namespace name.
Thanks, pushed.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Developm
Pavel Stehule wrote:
> Hi
>
> When I tested XMLTABLE function I found a bug of XPATH function -
> xpath_internal
>
> There xmltype is not correctly encoded to xmlChar due possible invalid
> encoding info in header. It is possible when XML was loaded with recv
> function and has not UTF8 encoding.
On Thu, Apr 13, 2017 at 11:05 AM, Stephen Frost wrote:
> Sure, though I won't be able to today and I've got some doubts about the
> other patches. I'll have more time tomorrow though.
OK, cool. I'll mark you down as the owner on the open items list.
--
Robert Haas
EnterpriseDB: http://www.ent
On 4/12/17 22:56, Bruce Momjian wrote:
> Is pg_upgrade the right place for an extension upgrade script? When
> pg_upgrade started creating an incremental-analyze script, people
> thought it should be more generic so it was moved to vacuumdb
> --analyze-in-stages. Seems we should do the same thing
On 4/13/17 08:37, Heikki Linnakangas wrote:
>> We could go with "ste" perhaps, or break the convention of 3-character
>> prefixes and go with "stae".
> We have a bunch of > 3-character prefixes already: amop*, amproc*,
> enum*, cast*. But I think I nevertheless like "ste" better.
"stx" perhaps?
On 4/12/17 18:31, Peter Eisentraut wrote:
> On 4/11/17 23:41, Noah Misch wrote:
>> On Tue, Apr 11, 2017 at 11:21:24PM -0400, Peter Eisentraut wrote:
>>> On 4/9/17 22:16, Noah Misch wrote:
[Action required within three days. This is a generic notification.]
>>>
>>> Patches have been posted. D
On Thu, Apr 13, 2017 at 11:48 AM, Peter Eisentraut
wrote:
> On 4/12/17 22:56, Bruce Momjian wrote:
>> Is pg_upgrade the right place for an extension upgrade script? When
>> pg_upgrade started creating an incremental-analyze script, people
>> thought it should be more generic so it was moved to va
On Thu, Apr 13, 2017 at 12:05 PM, Peter Eisentraut
wrote:
> On 4/12/17 18:31, Peter Eisentraut wrote:
>> On 4/11/17 23:41, Noah Misch wrote:
>>> On Tue, Apr 11, 2017 at 11:21:24PM -0400, Peter Eisentraut wrote:
On 4/9/17 22:16, Noah Misch wrote:
> [Action required within three days. This
Andreas Karlsson writes:
> Here is my proof of concept patch. It does basically the same thing as
> Andres's patch except that it handles quoted values a bit better and
> does not try to support anything other than the regproc type.
> The patch speeds up initdb without fsync from 0.80 seconds t
Peter Eisentraut writes:
> On 4/13/17 08:37, Heikki Linnakangas wrote:
>> We have a bunch of > 3-character prefixes already: amop*, amproc*,
>> enum*, cast*. But I think I nevertheless like "ste" better.
> "stx" perhaps?
> I would also be in favor of changing it to something other than "sta".
On Thu, Apr 13, 2017 at 8:56 AM, Fabien COELHO wrote:
> Calling the server is already available:
>
> SELECT AS varname \gset
Sure, but people are going to want to do it inline with the \if.
Anything that can be done that way can also be done this way, but
people will want it just to make the c
On 4/10/17 13:28, Fujii Masao wrote:
> src/backend/replication/logical/launcher.c
> * Worker started and attached to our shmem. This check is safe
> * because only launcher ever starts the workers, so nobody can steal
> * the worker slot.
>
> The tablesync patch
Tom Lane wrote:
> Peter Eisentraut writes:
> > On 4/13/17 08:37, Heikki Linnakangas wrote:
> >> We have a bunch of > 3-character prefixes already: amop*, amproc*,
> >> enum*, cast*. But I think I nevertheless like "ste" better.
>
> > "stx" perhaps?
>
> > I would also be in favor of changing it
On 04/13/2017 05:53 AM, Michael Paquier wrote:
Thanks for the updated patches! I had a close look at them.
Let's begin with 0001...
/*
* Negotiation generated data to be sent to the client.
*/
- elog(DEBUG4, "sending SASL response token of length
On 2017-04-13 12:13:30 -0400, Tom Lane wrote:
> Andreas Karlsson writes:
> > Here is my proof of concept patch. It does basically the same thing as
> > Andres's patch except that it handles quoted values a bit better and
> > does not try to support anything other than the regproc type.
>
> > Th
On Wed, Apr 12, 2017 at 6:58 PM, Andres Freund wrote:
> This yields plenty weird behaviour in < v10. E.g. the following is
> disallowed:
> SELECT * FROM int4mul(generate_series(1,3), 1);
> ERROR: 0A000: set-valued function called in context that cannot accept a
> set
> as is
> SELECT * FRO
Andres Freund writes:
> Cool. I wonder if we also should remove AtEOXact_CatCache()'s
> cross-checks - the resowner replacement has been in place for a while,
> and seems robust enough. They're now the biggest user of time.
Hm, biggest user of time in what workload? I've not noticed that
funct
On Thu, Apr 21, 2016 at 10:53 AM, Robert Haas wrote:
> On Thu, Apr 21, 2016 at 8:44 AM, Michael Paquier
> wrote:
>> On Thu, Apr 21, 2016 at 5:22 PM, Etsuro Fujita
>> wrote:
>>> Attached is an updated version of the patch, which modified Michael's
>>> version of the patch, as I proposed in [1] (s
On 2017-04-13 12:56:14 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Cool. I wonder if we also should remove AtEOXact_CatCache()'s
> > cross-checks - the resowner replacement has been in place for a while,
> > and seems robust enough. They're now the biggest user of time.
>
> Hm, biggest u
On 2017-04-13 12:53:27 -0400, Robert Haas wrote:
> On Wed, Apr 12, 2017 at 6:58 PM, Andres Freund wrote:
> > This yields plenty weird behaviour in < v10. E.g. the following is
> > disallowed:
> > SELECT * FROM int4mul(generate_series(1,3), 1);
> > ERROR: 0A000: set-valued function called in c
Robert Haas writes:
> So I'm not sure what the right thing to do here is.
Andres' points about composite vs noncomposite function result types
seem pretty compelling: we could make the behavior better for scalar
results, but if it then diverges from what happens for composite
results, I don't thi
On Fri, Apr 14, 2017 at 1:28 AM, Peter Eisentraut
wrote:
> On 4/10/17 13:28, Fujii Masao wrote:
>> src/backend/replication/logical/launcher.c
>> * Worker started and attached to our shmem. This check is safe
>> * because only launcher ever starts the workers, so nobody c
2017-04-13 17:19 GMT+02:00 Alvaro Herrera :
> Pavel Stehule wrote:
> > Hi
> >
> > When I tested XMLTABLE function I found a bug of XPATH function -
> > xpath_internal
> >
> > There xmltype is not correctly encoded to xmlChar due possible invalid
> > encoding info in header. It is possible when XML
>
>
> > I suggest to reuse pgbench expression engine, developed by Haas Robert:-)
>
> Not a bad idea (though I'm sure there are other reasonable options, too).
>
>
I don't want to stand in the way of any progress in getting expressions
into \if and some subspecies of \set. But, assuming we don't ge
On Thu, Apr 13, 2017 at 9:23 PM, Masahiko Sawada wrote:
> On Thu, Apr 13, 2017 at 5:17 PM, Kyotaro HORIGUCHI
> wrote:
>> Hello,
>>
>> At Thu, 6 Apr 2017 16:17:31 +0900, Masahiko Sawada
>> wrote in
>>> On Thu, Apr 6, 2017 at 10:51 AM, Noah Misch wrote:
>>> > On Thu, Apr 06, 2017 at 12:48:56AM
>
> > I suggest to reuse pgbench expression engine, developed by Haas Robert:-)
>
> Not a bad idea (though I'm sure there are other reasonable options, too).
>
I checked the pgbench code - and I think it can work well - just add
logical operators and compare operators.
Don't need to create more c
Thanks for looking at this!
On 13/04/17 02:29, Andres Freund wrote:
> Hi,
> On 2017-03-03 01:30:11 +0100, Petr Jelinek wrote:
>
>> From 7d5b48c8cb80e7c867b2096c999d08feda50b197 Mon Sep 17 00:00:00 2001
>> From: Petr Jelinek
>> Date: Fri, 24 Feb 2017 21:39:03 +0100
>> Subject: [PATCH 1/5] Reserve
On 13/04/17 07:02, Andres Freund wrote:
>
> On April 12, 2017 9:58:12 PM PDT, Noah Misch wrote:
>> On Wed, Apr 12, 2017 at 10:21:51AM -0700, Andres Freund wrote:
>>> On 2017-04-12 11:03:57 -0400, Peter Eisentraut wrote:
On 4/12/17 02:31, Noah Misch wrote:
>>> But I hope you mean to commi
On 13/04/17 13:01, Kyotaro HORIGUCHI wrote:
> Ouch! I replied to wrong mail.
>
> At Thu, 13 Apr 2017 19:55:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20170413.195504.89348773.horiguchi.kyot...@lab.ntt.co.jp>
>> I confused sync and apply workers.
>> sync worker failure at st
On Thu, Apr 13, 2017 at 12:36 PM, Michael Paquier
wrote:
> On Thu, Apr 13, 2017 at 12:28 PM, Fujii Masao wrote:
>> On Thu, Apr 13, 2017 at 5:25 AM, Peter Eisentraut
>> wrote:
>>> On 4/12/17 09:55, Fujii Masao wrote:
To fix this issue, we should terminate walsender for logical replication
>>
2017-04-13 19:46 GMT+02:00 Corey Huinker :
>
>> > I suggest to reuse pgbench expression engine, developed by Haas
>> Robert:-)
>>
>> Not a bad idea (though I'm sure there are other reasonable options, too).
>>
>>
> I don't want to stand in the way of any progress in getting expressions
> into \if
Andres Freund writes:
> On 2017-04-13 12:56:14 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> Cool. I wonder if we also should remove AtEOXact_CatCache()'s
>>> cross-checks - the resowner replacement has been in place for a while,
>>> and seems robust enough. They're now the biggest user o
On Thu, Apr 13, 2017 at 12:30 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 4/10/17 11:30, Magnus Hagander wrote:
> > After you've run pg_upgrade, you have to loop through all your databases
> > and do an "ALTER EXTENSION abc UPDATE" once for each extension.
> >
> > Is there
On Thu, Apr 13, 2017 at 6:06 PM, Robert Haas wrote:
> On Thu, Apr 13, 2017 at 11:48 AM, Peter Eisentraut
> wrote:
> > On 4/12/17 22:56, Bruce Momjian wrote:
> >> Is pg_upgrade the right place for an extension upgrade script? When
> >> pg_upgrade started creating an incremental-analyze script, p
On Thu, Apr 13, 2017 at 09:02:27PM +0200, Magnus Hagander wrote:
> On Thu, Apr 13, 2017 at 12:30 AM, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>
> On 4/10/17 11:30, Magnus Hagander wrote:
> > After you've run pg_upgrade, you have to loop through all your databases
>
Hi,
Though I've read only a part of the logical rep code yet, I'd like to
share some (relatively minor) review comments that I got so far.
In ApplyWorkerMain(), DatumGetInt32() should be used to get integer
value from the argument, instead of DatumGetObjectId().
No one resets on_commit_launcher_
On Thu, Apr 13, 2017 at 9:13 PM, Bruce Momjian wrote:
> On Thu, Apr 13, 2017 at 09:02:27PM +0200, Magnus Hagander wrote:
> > On Thu, Apr 13, 2017 at 12:30 AM, Peter Eisentraut <
> > peter.eisentr...@2ndquadrant.com> wrote:
> >
> > On 4/10/17 11:30, Magnus Hagander wrote:
> > > After you'v
On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote:
> I'm a little confused on why a SELECT policy fires against the NEW record
> for an UPDATE when using multiple FOR policies. The ALL policy doesn't seem
> to have that restriction.
My guess is that you have found a bug.
--
Robert Haas
Enterpris
On Thu, Apr 13, 2017 at 3:48 PM, Magnus Hagander wrote:
>> Well, pg_upgrade creates ./analyze_new_cluster.sh, but that just
>> contains:
>>
>> "/u/pgsql/bin/vacuumdb" --all --analyze-in-stages
>>
>> Seems like we should just get rid of ./analyze_new_cluster.sh and tell
>> the user to run v
On Thu, Apr 6, 2017 at 3:14 AM, Amit Langote
wrote:
>> The bulk of operations that work on traditional tables also work on
>> partitions
>> and partitioned tables. The next closest kind of relation, a materialized
>> view, is far less table-like. Therefore, I recommend showing both partitions
>
On Mon, Apr 3, 2017 at 3:32 PM, Daniel Verite wrote:
> In interactive mode, the warning in untaken branches is misleading
> when \endif is on the same line as the commands that
> are skipped. For instance:
>
> postgres=# \if false \echo NOK \endif
> \echo command ignored; use \endif or Ctrl-C
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote:
> > I'm a little confused on why a SELECT policy fires against the NEW record
> > for an UPDATE when using multiple FOR policies. The ALL policy doesn't seem
> > to have that restriction.
>
> My guess
On Thu, Mar 16, 2017 at 4:45 AM, Andres Freund wrote:
> During citus development we noticed that restrictions aren't pushed down
> into lateral subqueries, even if they semantically could. For example,
> in this dumbed down example:
>
> postgres[31776][1]=# CREATE TABLE t_2(id serial primary key)
On 2017-04-13 16:34:12 -0400, Robert Haas wrote:
> On Thu, Mar 16, 2017 at 4:45 AM, Andres Freund wrote:
> > During citus development we noticed that restrictions aren't pushed down
> > into lateral subqueries, even if they semantically could. For example,
> > in this dumbed down example:
> >
> >
On Fri, Mar 17, 2017 at 7:57 AM, Yugo Nagata wrote:
> I also understanded that my design has a problem during pg_dump and
> pg_upgrade, and that some information to identify the partition
> is required not depending the command order. However, I feel that
> Amul's design is a bit complicated with
On 2017-04-13 14:05:43 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-04-13 12:56:14 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >>> Cool. I wonder if we also should remove AtEOXact_CatCache()'s
> >>> cross-checks - the resowner replacement has been in place for a while,
> >>
On 04/13/2017 01:31 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote:
>> > I'm a little confused on why a SELECT policy fires against the NEW record
>> > for an UPDATE when using multiple FOR policies. The ALL policy doesn'
Rod, all,
* Joe Conway (m...@joeconway.com) wrote:
> On 04/13/2017 01:31 PM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote:
> >> > I'm a little confused on why a SELECT policy fires against the NEW record
> >> > for an
Hi
Yesterday while doing a few pg_basebackup, I realized that the integer
parameters were not properly checked against invalid input.
It is not a critical issue, but this could be misleading for an user who
writes -z max or -s 0.5…
I've attached the patch to this mail. Should I add it to the next
On 12/04/17 06:10, Peter Eisentraut wrote:
> On 3/24/17 10:49, Petr Jelinek wrote:
>> Rebase after table copy patch got committed.
>
> You could please sent another rebase of this, perhaps with some more
> documentation, as discussed downthread.
>
> Also, I wonder why we don't offer the other val
On 13/04/17 12:23, Masahiko Sawada wrote:
> On Thu, Apr 13, 2017 at 11:53 AM, Masahiko Sawada
> wrote:
>> On Wed, Apr 12, 2017 at 11:46 PM, Peter Eisentraut
>> wrote:
>>> On 4/12/17 00:48, Masahiko Sawada wrote:
On Wed, Apr 12, 2017 at 1:28 PM, Peter Eisentraut
> Perhaps instead of a gl
Hello Robert,
Calling the server is already available:
SELECT AS varname \gset
Sure, but people are going to want to do it inline with the \if.
Yes... and my changed opinion is that the answer to this approach should
be "no", only client side after if.
Anything that can be done that
On Fri, Apr 14, 2017 at 6:32 AM, Pierre Ducroquet wrote:
> Yesterday while doing a few pg_basebackup, I realized that the integer
> parameters were not properly checked against invalid input.
> It is not a critical issue, but this could be misleading for an user who
> writes -z max or -s 0.5…
> I'
On Fri, Apr 14, 2017 at 3:03 AM, Fujii Masao wrote:
> On Thu, Apr 13, 2017 at 12:36 PM, Michael Paquier
> wrote:
>> On Thu, Apr 13, 2017 at 12:28 PM, Fujii Masao wrote:
>>> On Thu, Apr 13, 2017 at 5:25 AM, Peter Eisentraut
>>> wrote:
On 4/12/17 09:55, Fujii Masao wrote:
> To fix this i
On Mon, Apr 3, 2017 at 3:32 PM, Daniel Verite wrote:
In interactive mode, the warning in untaken branches is misleading
when \endif is on the same line as the commands that
are skipped. For instance:
postgres=# \if false \echo NOK \endif
\echo command ignored; use \endif or Ctrl-C to exit
On Fri, Apr 14, 2017 at 2:47 AM, Fujii Masao wrote:
> I'm thinking that it's less confusing to report always 0 as the priority of
> async standby whatever the setting of synchronous_standby_names is.
> Thought?
Or we could have priority being reported to NULL for async standbys as
well, the prior
On Thu, Apr 13, 2017 at 7:40 PM, Vitaly Burovoy
wrote:
> On 4/6/17, Vitaly Burovoy wrote:
>> On 4/6/17, Peter Eisentraut wrote:
>>> As I tried to mention earlier, it is very difficult to implement the IF
>>> NOT EXISTS behavior here, because we need to run the commands the create
>>> the sequenc
On 2017/04/14 5:28, Robert Haas wrote:
> On Thu, Apr 6, 2017 at 3:14 AM, Amit Langote
> wrote:
>>> The bulk of operations that work on traditional tables also work on
>>> partitions
>>> and partitioned tables. The next closest kind of relation, a materialized
>>> view, is far less table-like. T
On 13/04/17 18:11, Robert Haas wrote:
> On Thu, Apr 13, 2017 at 12:05 PM, Peter Eisentraut
> wrote:
>> On 4/12/17 18:31, Peter Eisentraut wrote:
>>> On 4/11/17 23:41, Noah Misch wrote:
On Tue, Apr 11, 2017 at 11:21:24PM -0400, Peter Eisentraut wrote:
> On 4/9/17 22:16, Noah Misch wrote:
>
On Fri, Apr 14, 2017 at 9:38 AM, Michael Paquier
wrote:
> On Fri, Apr 14, 2017 at 2:47 AM, Fujii Masao wrote:
>> I'm thinking that it's less confusing to report always 0 as the priority of
>> async standby whatever the setting of synchronous_standby_names is.
>> Thought?
>
> Or we could have prio
On 4/13/17 12:11, Robert Haas wrote:
> I wonder if we should have an --no-subscriptions option, now that they
> are dumped by default, just like we have --no-blobs, --no-owner,
> --no-password, --no-privileges, --no-acl, --no-tablespaces, and
> --no-security-labels. It seems like there is probably
I don't think inheritance and partitioning should behave the same in
terms of logical replication.
For me the current behavior with inherited tables is correct.
What I would like partitioned tables support to look like is that if we
add partitioned table, the data decoded from any of the partitio
On Fri, Apr 14, 2017 at 1:37 AM, Heikki Linnakangas wrote:
> On 04/13/2017 05:53 AM, Michael Paquier wrote:
>> +* Parse the list of SASL authentication mechanisms in the
>> +* AuthenticationSASL message, and select the best mechanism that we
>> +* support. (Only SCRAM-SHA-256 is suppo
On 4/4/17 09:59, Stephen Frost wrote:
>> Attached is a patch that adds the pg_dump support, but I'm struggling to
>> make the tests work. Could you take a look? Problem one I'm seeing is
>> that the tests assert that there are no comments in the post-data
>> section, which is no longer the case h
On 3/29/17 04:11, Alexander Law wrote:
> Please consider committing the attached patches to remove trailing
> spaces in strings in the source code.
> One patch is for localizable messages, and the other is just for
> consistency (less important).
committed
--
Peter Eisentraut http
1 - 100 of 113 matches
Mail list logo
