On Fri, May 12, 2017 at 6:08 PM, amul sul wrote:
> Hi,
>
> Please find the following updated patches attached:
I have done some testing with the new patch, most of the cases worked
as per the expectation except below
I expect the planner to select only "Seq Scan on t1" whereas it's
scanning both
On Sat, May 13, 2017 at 1:08 AM, Robert Haas wrote:
> On Fri, May 12, 2017 at 2:45 PM, Tom Lane wrote:
>
> Maybe a shorter argument for hash partitioning is that not one but two
> different people proposed patches for it within months of the initial
> partitioning patch going in. When multiple p
On Sat, May 13, 2017 at 11:01 AM, Robert Haas wrote:
> On Fri, May 12, 2017 at 12:46 PM, Robert Haas wrote:
>> On Fri, May 12, 2017 at 3:26 AM, Amit Langote
>> wrote:
>>> Fixed.
>>
>> This seems to be the same patch version as last time, so none of the
>> things you mention as fixed are, in fact
On 2017-05-12 21:56:30 -0400, Robert Haas wrote:
> Cheap isn't free, though. It's got a double-digit percentage overhead
> rather than a large-multiple-of-the-runtime overhead as triggers do,
> but people still won't want to pay it unnecessarily, I think.
That should be partiall addressable with
On Fri, May 12, 2017 at 10:19 PM, Peter Eisentraut
wrote:
> On 5/11/17 21:59, Michael Paquier wrote:
>> 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
On Fri, May 12, 2017 at 12:46 PM, Robert Haas wrote:
> On Fri, May 12, 2017 at 3:26 AM, Amit Langote
> wrote:
>> Fixed.
>
> This seems to be the same patch version as last time, so none of the
> things you mention as fixed are, in fact, fixed.
We are kind of running out of time here before beta1
On Fri, May 12, 2017 at 7:36 PM, David Fetter wrote:
> On Fri, May 12, 2017 at 06:38:55PM -0400, Peter Eisentraut wrote:
>> On 5/12/17 18:13, Alvaro Herrera wrote:
>> > I think for logical replication the tuple should appear as being in the
>> > parent table, not the partition. No?
>>
>> Logical
On Wed, May 10, 2017 at 10:05 PM, Michael Paquier
wrote:
> Regarding the patch, this is way to close to the progress facility
> already in place. So why don't you extend it for the executor?
I don't think that's a good idea. The existing progress facility
advertises a fixed number of counters wi
Alvaro Herrera writes:
> Tom Lane wrote:
>> Hm. That would behave less than desirably if getObjectClass() could
>> return a value that wasn't a member of the enum, but it's hard to
>> credit that happening. I guess I'd vote for removing the default:
>> case from all of the places that have "swit
On Fri, May 12, 2017 at 06:38:55PM -0400, Peter Eisentraut wrote:
> On 5/12/17 18:13, Alvaro Herrera wrote:
> > I think for logical replication the tuple should appear as being in the
> > parent table, not the partition. No?
>
> Logical replication replicates base table to base table. How those
On 5/12/17 18:13, Alvaro Herrera wrote:
> I think for logical replication the tuple should appear as being in the
> parent table, not the partition. No?
Logical replication replicates base table to base table. How those
tables are tied together into a partitioned table or an inheritance tree
is
Peter Eisentraut wrote:
> On 5/12/17 14:23, Robert Haas wrote:
> > One alternative would be to change the way that we dump and restore
> > the data. Instead of dumping the data with the individual partitions,
> > dump it all out for the parent and let tuple routing sort it out at
> > restore time.
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Oh, I see your patch also fixes missing code in getObjectDescription().
> >> We need that. Is there a decent way to get the compiler to warn about
> >> that oversight?
>
> > We could remove the default clause. That results in the
Alvaro Herrera writes:
> Tom Lane wrote:
>> Oh, I see your patch also fixes missing code in getObjectDescription().
>> We need that. Is there a decent way to get the compiler to warn about
>> that oversight?
> We could remove the default clause. That results in the expected
> warning, and no ot
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Oh, sorry --- I already pushed something about this.
>
> > That's fine, thanks.
>
> Oh, I see your patch also fixes missing code in getObjectDescription().
> We need that. Is there a decent way to get the compiler to warn about
>
Alvaro Herrera writes:
> Tom Lane wrote:
>> Oh, sorry --- I already pushed something about this.
> That's fine, thanks.
Oh, I see your patch also fixes missing code in getObjectDescription().
We need that. Is there a decent way to get the compiler to warn about
that oversight?
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Although I've not done anything about it here, I'm not happy about the
> >> handling of dependencies for stats objects.
>
> > Here are two patches regarding handling of dependencies.
>
> Oh, sorry --- I already pushed something ab
Alvaro Herrera writes:
> Tom Lane wrote:
>> Although I've not done anything about it here, I'm not happy about the
>> handling of dependencies for stats objects.
> Here are two patches regarding handling of dependencies.
Oh, sorry --- I already pushed something about this.
> The first one
> imp
Here is a patch to amend the docs here:
https://www.postgresql.org/docs/devel/static/plpgsql-trigger.html
In the example for an AFTER trigger, you see this code:
--
-- Create a row in emp_audit to reflect the operation performed on emp,
-- make use of the special variable TG_OP to w
backend/access/transam/Makefile contains
# ensure that version checks in xlog.c get recompiled when catversion.h changes
xlog.o: xlog.c $(top_srcdir)/src/include/catalog/catversion.h
which, at the time it was added, was sufficient to ensure you could do
"make check" after bumping catversion and t
Tom Lane wrote:
> Although I've not done anything about it here, I'm not happy about the
> handling of dependencies for stats objects. I do not think that cloning
> RemoveStatistics as RemoveStatisticsExt is sane at all. The former is
> meant to deal with cleaning up pg_statistic rows that we kn
On Fri, May 12, 2017 at 3:39 PM, Bruce Momjian wrote:
> On Tue, May 9, 2017 at 05:14:19PM -0400, Tom Lane wrote:
>> Ilya Shkuratov writes:
>> > Ok, it seems that most people in discussion are agree that removing
>> > optimization
>> > fence is a right thing to do.
>> > Nonetheless I still hopin
On Tue, May 9, 2017 at 05:14:19PM -0400, Tom Lane wrote:
> Ilya Shkuratov writes:
> > Ok, it seems that most people in discussion are agree that removing
> > optimization
> > fence is a right thing to do.
> > Nonetheless I still hoping to discuss the algorithm and its implementation.
>
> Yeah,
I wrote:
> Tomas Vondra writes:
>> On 5/12/17 4:46 AM, Tom Lane wrote:
>>> Although I've not done anything about it here, I'm not happy about the
>>> handling of dependencies for stats objects.
>> Yeah, it's a bit frankensteinian ...
> I'm prepared to create a fix for that, but it'd be easier to
On 5/12/17 14:23, Robert Haas wrote:
> One alternative would be to change the way that we dump and restore
> the data. Instead of dumping the data with the individual partitions,
> dump it all out for the parent and let tuple routing sort it out at
> restore time.
I think this could be a pg_dump
Tom Lane wrote:
> I did not review the rest of the regression test changes, nor the
> tab-complete changes. I can however report that DROP STATISTICS
> doesn't successfully complete any stats object names.
The attached patch fixes this problem.
--
Álvaro Herrerahttps://www.2nd
On Fri, May 12, 2017 at 2:45 PM, Tom Lane wrote:
> Yeah, that isn't really appetizing at all. If we were doing physical
> partitioning below the user-visible level, we could make it fly.
> But the existing design makes the partition boundaries user-visible
> which means we have to insist that the
On Fri, May 12, 2017 at 02:23:14PM -0400, Robert Haas wrote:
>
> What about integers? I think we're already assuming two's-complement
> arithmetic, which I think means that the only problem with making the
> hash values portable for integers is big-endian vs. little-endian.
> That's sounds solvea
Robert Haas writes:
> On Fri, May 12, 2017 at 1:34 PM, Tom Lane wrote:
>> I'd vote that it's not, which means that this whole approach to hash
>> partitioning is unworkable. I agree with Andres that demanding hash
>> functions produce architecture-independent values will not fly.
> If we can't
On Fri, May 12, 2017 at 1:34 PM, Tom Lane wrote:
> I'd vote that it's not, which means that this whole approach to hash
> partitioning is unworkable. I agree with Andres that demanding hash
> functions produce architecture-independent values will not fly.
If we can't produce architecture-indepen
On 5/12/17 12:12, Dagfinn Ilmari Mannsåker wrote:
> Peter Eisentraut writes:
>
>> Committed, adjusting for some of the suggestions.
>
> Looks like one occurrence was still left in:
>
> $ ag --no-group --ignore po --ignore release-\* --ignore wal.sgml
> '\btransaction\s+log\b'
> doc/src/sgml/fu
On 5/11/17 12:00, Tom Lane wrote:
> 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 wil
On Fri, May 12, 2017 at 08:35:26PM +0300, Konstantin Knizhnik wrote:
>
>
> On 12.05.2017 18:23, Bruce Momjian wrote:
> >On Fri, May 12, 2017 at 10:50:41AM +0300, Konstantin Knizhnik wrote:
> >>Definitely changing session context (search_path, date/time format, ...) may
> >>cause incorrect behavio
On May 12, 2017 12:50:41 AM PDT, Konstantin Knizhnik
wrote:
>Definitely changing session context (search_path, date/time format,
>...)
>may cause incorrect behavior of cached statements.
>Actually you may get the same problem with explicitly prepared
>statements (certainly, in the last case,
On 05/12/2017 10:17 AM, Robert Haas wrote:
> On Fri, May 12, 2017 at 1:12 PM, Andres Freund wrote:
>> Given that a lot of data types have a architecture dependent
>> representation, it seems somewhat unrealistic and expensive to have
>> a hard rule to keep them architecture agnostic. And if that'
On 12.05.2017 18:23, Bruce Momjian wrote:
On Fri, May 12, 2017 at 10:50:41AM +0300, Konstantin Knizhnik wrote:
Definitely changing session context (search_path, date/time format, ...) may
cause incorrect behavior of cached statements.
I wonder if we should clear the cache whenever any SET com
Robert Haas writes:
> On Fri, May 12, 2017 at 1:12 PM, Andres Freund wrote:
>> Given that a lot of data types have a architecture dependent representation,
>> it seems somewhat unrealistic and expensive to have a hard rule to keep them
>> architecture agnostic. And if that's not guaranteed, t
On Fri, May 12, 2017 at 9:35 PM, tushar wrote:
> Hi,
>
> There are few more issues , found in logical replication
>
> (1)ERROR: tuple concurrently updated
>
> Publication Server - (X machine)
> \\create table \ create publication \ insert rows
> create table t(n int);
> create publication pub f
On Fri, May 12, 2017 at 1:12 PM, Andres Freund wrote:
> Given that a lot of data types have a architecture dependent representation,
> it seems somewhat unrealistic and expensive to have a hard rule to keep them
> architecture agnostic. And if that's not guaranteed, then I'm doubtful it
> mak
On May 12, 2017 10:05:56 AM PDT, Robert Haas wrote:
>On Fri, May 12, 2017 at 12:08 AM, Jeff Davis wrote:
>> 1. The hash functions as they exist today aren't portable -- they can
>> return different results on different machines. That means using
>these
>> functions for hash partitioning would y
On Fri, May 12, 2017 at 12:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, May 12, 2017 at 12:04 PM, Tom Lane wrote:
>>> Actually, I now remember that I wrote that while at Salesforce (because
>>> they'd run into the problem that constant ArrayRef expressions weren't
>>> simplified). So
On Fri, May 12, 2017 at 6:08 PM, amul sul wrote:
> Hi,
>
> Please find the following updated patches attached:
>
> 0001-Cleanup.patch : Does some cleanup and code refactoring required
> for hash partition patch. Otherwise, there will be unnecessary diff in
> 0002 patch
Thanks for splitting the pa
On Thu, May 11, 2017 at 10:38 PM, Amit Langote
wrote:
> So, adding keycol IS NOT NULL (like we currently do for expressions) in
> the implicit partition constraint would be more future-proof than
> generating an actual catalogued NOT NULL constraint on the keycol? I now
> tend to think it would b
On Fri, May 12, 2017 at 12:08 AM, Jeff Davis wrote:
> 1. The hash functions as they exist today aren't portable -- they can
> return different results on different machines. That means using these
> functions for hash partitioning would yield different contents for the
> same partition on differen
On Wed, May 10, 2017 at 11:39 PM, Robert Haas wrote:
> On Wed, May 3, 2017 at 9:09 AM, amul sul wrote:
>> Fixed in the attached version.
>
> +[ PARTITION BY { HASH | RANGE | LIST } ( { class="parameter">column_name | ( class="parameter">expression ) } [ COLLATE
> In the department of severe ni
Robert Haas writes:
> On Fri, May 12, 2017 at 12:04 PM, Tom Lane wrote:
>> Actually, I now remember that I wrote that while at Salesforce (because
>> they'd run into the problem that constant ArrayRef expressions weren't
>> simplified). So that means it's been languishing in a git branch for
>>
On Fri, May 12, 2017 at 12:38 PM, Tom Lane wrote:
> I can't draw any other conclusion but that you've hacked something
> to make FATAL act like LOG. Which is a fatal mistake.
I see what you did there.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Fri, May 12, 2017 at 12:04 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 05/11/2017 06:21 PM, Tom Lane wrote:
>>> Yeah, I think it's a lack-of-round-tuits situation. Your patch reminds
>>> me of a more ambitious attempt I made awhile back to reduce the amount
>>> of duplicative boile
On Fri, May 12, 2017 at 3:26 AM, Amit Langote
wrote:
> Fixed.
This seems to be the same patch version as last time, so none of the
things you mention as fixed are, in fact, fixed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hac
On 12/05/17 10:57, Petr Jelinek wrote:
> On 12/05/17 03:31, Andres Freund wrote:
>> 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 branc
"K S, Sandhya (Nokia - IN/Bangalore)" writes:
> I have filtered the logs based on PID (19825) to see if this helps to
> debug the issue further.
Is this really a stock Postgres build?
The proximate cause of the PANIC is that the startup process is seeing
other processes active even though it has
> Ok, i agree. Patch is attached.
I added a patch to the CF
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut writes:
> Committed, adjusting for some of the suggestions.
Looks like one occurrence was still left in:
$ ag --no-group --ignore po --ignore release-\* --ignore wal.sgml
'\btransaction\s+log\b'
doc/src/sgml/func.sgml:18631:end of the transaction log at any instant,
while
Heikki Linnakangas writes:
> On 05/11/2017 06:21 PM, Tom Lane wrote:
>> Yeah, I think it's a lack-of-round-tuits situation. Your patch reminds
>> me of a more ambitious attempt I made awhile back to reduce the amount
>> of duplicative boilerplate in eval_const_expressions. I think I wrote
>> it
On 5/3/17 09:10, David Steele wrote:
> The documentation changes look good to me, but the error message changes
> are a random mix of "WAL" and "write-ahead log", even when referring to
> the same thing.
The reason for this is that some of the error messages refer to a
--waldir option or something
Committed, adjusting for some of the suggestions.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> I'm prepared to create a fix for that, but it'd be easier to commit the
> >> current patch first, to avoid merge conflicts.
>
> > It seems we're mostly in agreement regarding the parts I was touching.
> > Do you want to push your v
On Fri, May 12, 2017 at 10:50:41AM +0300, Konstantin Knizhnik wrote:
> Definitely changing session context (search_path, date/time format, ...) may
> cause incorrect behavior of cached statements.
I wonder if we should clear the cache whenever any SET command is
issued.
> Actually you may get the
Alvaro Herrera writes:
> Tom Lane wrote:
>> I'm prepared to create a fix for that, but it'd be easier to commit the
>> current patch first, to avoid merge conflicts.
> It seems we're mostly in agreement regarding the parts I was touching.
> Do you want to push your version of the patch?
It's sti
Tom Lane wrote:
> Tomas Vondra writes:
> >> Although I've not done anything about it here, I'm not happy about the
> >> handling of dependencies for stats objects.
>
> > Yeah, it's a bit frankensteinian ...
>
> I'm prepared to create a fix for that, but it'd be easier to commit the
> current pa
On 5/11/17 23:59, Tom Lane wrote:
> Right, but the existing code is *designed* to hold the lock till end of
> top-level transaction, regardless of what happens in any subtransaction.
> My understanding of your complaint is that you do not think that's OK
> for any lock stronger than AccessShareLock
Sairam Gaddam writes:
> During startup (_PG_init), I need to access some meta info of
> table/relation (like PK Column Position, FK Column Positions, Index Column
> Positions etc...) and load it into memory.
Why not fetch that info at first use, instead?
If you insist on doing it at _PG_init, yo
On 5/11/17 17:28, Andres Freund wrote:
> Isn't that pretty much the point? The whole open_share_lock()
> optimization looks like it really only can make a difference with
> subtransactions?
Yeah that confused me too. That keep-the-lock-for-the-whole-transaction
logic was introduced in a2597ef179
>
>
>
> I sent my version of patch in parallel. I think we don't need to do the
> relation open like you did, all the info is in syscache.
>
That's right.
>
Regards,
Neha
David Fetter writes:
> While it's consistent with surrounding code, I find the use of ints to
> express what is in essence a boolean condition puzzling. Any
> insights?
IIRC, it's forced by the getopt_long API, particularly the way that
the long-options struct has to be declared.
On Sat, May 13, 2017 at 12:04 AM, Petr Jelinek wrote:
> > After this commit 024711bb544645c8b1061e9f02b261e2e336981d I get
> > following error while executing CREATE SUBSCRIPTION:
> >
> > CREATE SUBSCRIPTION sub1 CONNECTION 'dbname=postgres host=localhost
> > user=neha port=5432' PUBLICATION mypu
On 5/11/17 16:34, Andres Freund wrote:
>>> This'd probably need to be removed, as we'd otherwise would get very
>>> weird semantics around aborted subxacts.
>> Can you explain in more detail what you mean by this?
> Well, right now we don't do proper lock-tracking for sequences, always
> assigning
On 12/05/17 15:55, Neha Khatri wrote:
> On 5/11/17, Petr Jelinek wrote:
>> Hi,
>>
>> On 11/05/17 14:25, tushar wrote:
>>> Hi,
>>>
>>> I observed that -we cannot publish "foreign table" in Publication
>>>
>>> but same thing is not true for Subscription
>>>
>>> postgres=# create foreign table t (n i
On 12/05/17 15:02, Peter Eisentraut wrote:
> On 5/9/17 11:43, Petr Jelinek wrote:
>> Here is rebased version of the other patch (the interface rework). I
>> also fixed the tab completion there.
>
> Committed.
>
> One small thing I changed, to make it look more like CREATE/ALTER TABLE,
> is that t
On Fri, May 12, 2017 at 10:59:27AM +0900, Michael Paquier wrote:
> 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
Michael Paquier writes:
> On Fri, May 12, 2017 at 9:05 PM, Andrew Dunstan
> wrote:
>> Does anyone object to me backpatching this? It seems to me kinda crazy
>> to have --verbose hardcoded on the back branches and not on the dev branch.
> +1. A maximum of consistency with the test code when possi
Tomas Vondra writes:
> On 5/12/17 4:46 AM, Tom Lane wrote:
>> If people agree that that reads better, we should make an effort to
>> propagate that terminology elsewhere in the docs, and into error messages,
>> objectaddress.c output, etc.
> I'm fine with the 'statistics object' wording. I've bee
Hello,
On Fri, May 12, 2017 at 5:30 PM, Rahila Syed wrote:
> Hello,
>
> >(1) With the new patch, we allow new partitions when there is overlapping
> data with default partition. The entries in default are ignored when
> running queries satisfying the new partition.
> This was introduced in late
On 12/05/17 15:09, Neha Khatri wrote:
> On Fri, May 12, 2017 at 8:19 PM, Simon Riggs wrote:
>>
>> On 11 May 2017 at 18:29, Simon Riggs wrote:
>>> On 11 May 2017 at 18:13, Andres Freund wrote:
>>>
> New patch, v3.
>
> Applying in 90 minutes, barring objections.
Could you ple
On 11/05/17 15:43, Petr Jelinek wrote:
> 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=#
[Correction below]
On 5/12/17, Neha Khatri wrote:
> On 5/11/17, Petr Jelinek wrote
>
>> However, the foreign tables indeed can't be subscribed.
Yes, I suspect that a user would _not_ want to subcribe a foreign
table in real world.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On 5/11/17, Petr Jelinek wrote:
> Hi,
>
> On 11/05/17 14:25, tushar wrote:
>> Hi,
>>
>> I observed that -we cannot publish "foreign table" in Publication
>>
>> but same thing is not true for Subscription
>>
>> postgres=# create foreign table t (n int) server db1_server options
>> (table_name 't');
Michael Paquier writes:
> 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
> attemp
On 5/11/17 21:59, Michael Paquier wrote:
> 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 dump
On Fri, May 12, 2017 at 8:19 PM, Simon Riggs wrote:
>
> On 11 May 2017 at 18:29, Simon Riggs wrote:
> > 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
On 5/9/17 11:43, Petr Jelinek wrote:
> Here is rebased version of the other patch (the interface rework). I
> also fixed the tab completion there.
Committed.
One small thing I changed, to make it look more like CREATE/ALTER TABLE,
is that the CREATE commands use WITH (...) but the ALTER commands
On Fri, May 12, 2017 at 9:05 PM, Andrew Dunstan
wrote:
> Does anyone object to me backpatching this? It seems to me kinda crazy
> to have --verbose hardcoded on the back branches and not on the dev branch.
+1. A maximum of consistency with the test code when possible is nice to have.
--
Michael
On Thu, May 11, 2017 at 9:32 PM, Dilip Kumar wrote:
> 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 co
Hi,
There are few more issues , found in logical replication
(1)ERROR: tuple concurrently updated
Publication Server - (X machine)
\\create table \ create publication \ insert rows
create table t(n int);
create publication pub for table t;
insert into t values (generate_series(1,100));
On 05/04/2017 12:50 AM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Andrew Dunstan writes:
>>> Can someone please explain to me why we have this in Makefile.global.in?
>>> (from commit e9c81b60 )
>>> PROVE_FLAGS =
>> Before that commit it was like
>>
>> PROVE_FLAGS
Hello,
>(1) With the new patch, we allow new partitions when there is overlapping
data with default partition. The entries in default are ignored when
running queries satisfying the new partition.
This was introduced in latest version. We are not allowing adding a
partition when entries with same
On 5/12/17 4:46 AM, Tom Lane wrote:
Alvaro Herrera writes:
Hmm, yeah, makes sense. Here's a patch for this approach.
...
Also, while reading the docs changes, I got rather ill from the
inconsistent and not very grammatical handling of "statistics" as a
noun, particularly the inability to
Hi hackers,
As you know, at this time Postgres cannot perform a full join on a
comparison clause. For example, if we have two tables with numeric
columns and run a query like 'select * from t1 full join t2 on t1.a >
t2.a', we get an error: "FULL JOIN is only supported with merge-joinable
or h
On Thu, May 11, 2017 at 7:37 PM, Rahila Syed wrote:
> Hello,
>
> Please find attached an updated patch with review comments and bugs
> reported till date implemented.
>
Hello Rahila,
Tested on "efa2c18 Doc fix: scale(numeric) returns integer, not numeric."
(1) With the new patch, we allow new
On 12 May 2017 at 14:56, Amit Kapila wrote:
> I think it might be better to summarize all the options discussed
> including what the patch has and see what most people consider as
> sensible.
Yes, makes sense. Here are the options that were discussed so far for
ROW triggers :
Option 1 : (the pat
On Wed, May 10, 2017 at 6:04 PM, Ashutosh Bapat
wrote:
> On Wed, May 3, 2017 at 6:39 PM, amul sul wrote:
>> On Thu, Apr 27, 2017 at 1:42 AM, Robert Haas wrote:
>>
>>>
>>> This is not yet a detailed review - I may be missing things, and
>>> review and commentary from others is welcome. If there
On 11 May 2017 at 18:29, Simon Riggs wrote:
> 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 to
On 05/11/2017 07:13 PM, Petr Jelinek wrote:
I think it does make sense to add check for this into CREATE/ALTER
SUBSCRIBER though so that user is informed immediately about the mistake
rather than by errors in the logs later.
+1 , there are few similar cases - where user does not get error at
On Fri, May 12, 2017 at 10:49 AM, Amit Khandekar wrote:
> On 12 May 2017 at 08:30, Amit Kapila wrote:
>> On Thu, May 11, 2017 at 5:41 PM, Amit Khandekar
>> wrote:
>
>> If we try to compare it with the non-partitioned update,
>> there also it is internally a delete and insert operation, but we
>
On 12/05/17 03:31, Andres Freund wrote:
> 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 fi
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa,
> Takayuki
> I found a wrong sentence here in the doc. I'm sorry, this is what I asked
> you to add...
>
> https://www.postgresql.org/docs/devel/static/libpq-connect.html#libpq-
> paramk
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> It seems to me that the feature is behaving as wanted. Or in short attempt
> to connect to the next host only if a connection cannot be established.
> If there is a failure once the exchange with the server has begun, just
> consider it as
> Just to se what other RDBMS are doing with CTEs; Look at slide
> 31 here:
> https://www.percona.com/live/17/sites/default/files/slides/Recursive%20Query%20Throwdown.pdf
That is taken from Markus Winand's post:
https://twitter.com/MarkusWinand/status/852862475699707904
"Seems like MySQL is
On Fri, May 12, 2017 at 11:24 AM, Masahiko Sawada wrote:
> 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
wrote:
On 2017/05/12 14:24, Ashutosh Bapat wrote:
> On Fri, May 12, 2017 at 8:08 AM, Amit Langote
> wrote:
>> On 2017/05/12 11:20, Robert Haas wrote:
>>> Yeah, but I have a feeling that marking the columns NOT NULL is going
>>> to make it really hard to support that in the future when we get the
>>> synt
1 - 100 of 104 matches
Mail list logo
