On Thu, Aug 31, 2017 at 1:15 AM, Robert Haas wrote:
> On Wed, Aug 30, 2017 at 12:47 PM, Ashutosh Bapat
> wrote:
>> +1. I think we should just pull out the OIDs from partition descriptor.
>
> Like this? The first patch refactors the expansion of a single child
> out into a separate function, and
On Fri, Aug 11, 2017 at 10:44 AM, Amit Khandekar wrote:
> On 4 August 2017 at 22:28, Amit Khandekar wrote:
>>>
I am planning to review and test this patch, Seems like this patch
needs to be rebased.
[dilip@localhost postgresql]$ patch -p1 <
../patches/update-partition-key_v15.patch
patching fil
On Wed, Aug 30, 2017 at 2:00 AM, Robert Haas wrote:
>
> I suggest defining a TBM_FILLFACTOR constant instead of repeating the
> value 0.9 in a bunch of places. I think it would also be good to try
> to find the sweet spot for that constant. Making it bigger reduces
> the number of lossy entries
Hi hackers!
Here is the patch with hooks that I consider sufficient for implementation of
incremental backup with pages tracking as extension.
Recently I was posting these things to the thread "Adding hook in BufferSync
for backup purposes" [0], but here I start separate thread since Subj field
On Mon, Aug 21, 2017 at 2:40 PM, Amit Kapila wrote:
> On Mon, Aug 21, 2017 at 1:44 PM, Haribabu Kommi
> wrote:
>>
>>
>> Thanks for adding more details. It is easy to understand.
>>
>> I marked the patch as ready for committer in the commitfest.
>>
Rebased the patch. The output of test case adde
Hi All,
Enclosed please find the patch only for the pg_dump using the 'comment on
current_database' statement.
This patch should be working with the previous patch which is
comment_on_current_database_no_pgdump_v3.patch
Regards,
Jing Wang
Fujitsu Australia
comment_on_current_database_for_pgdum
Sorry for the cross posting on this one, but I think it's important both groups
are aware.
>> I think this thread covers most of the issues.
>> https://lists.osgeo.org/pipermail/postgis-devel/2017-August/026355.html
>> My thought was is it possible for pg_upgrade to be taught to use CREATE
>> EX
Here is another attempt to implement generated columns. This is a
well-known SQL-standard feature, also available for instance in DB2,
MySQL, Oracle. A quick example:
CREATE TABLE t1 (
...,
height_cm numeric,
height_in numeric GENERATED ALWAYS AS (height_cm * 2.54)
);
(This is n
On 3/20/17 11:03, Ronan Dunklau wrote:
>> Great idea. This is too late for v10 at this point, but please add it
>> to the next CommitFest so we don't forget about it.
> I know it is too late, and thought that it was too early to add it to the
> commitfest properly since so many design decisions s
On Tue, Aug 29, 2017 at 08:44:42PM +0900, Michael Paquier wrote:
> On Mon, Aug 28, 2017 at 8:25 AM, Michael Paquier
> wrote:
> > Today's run has finished with the same failure:
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dangomushi&dt=2017-08-27%2018%3A00%3A13
> > Attached is a pat
Hi Ashutosh,
Thanks for the comments and sorry that it took me a while to reply here.
On 2017/08/23 20:16, Ashutosh Bapat wrote:
> On Mon, Aug 21, 2017 at 12:07 PM, Amit Langote
> wrote:
>> I've been working on implementing a way to perform plan-time
>> partition-pruning that is hopefully faster
On Sun, Aug 27, 2017 at 02:32:49AM +, Noah Misch wrote:
> On Fri, Aug 25, 2017 at 12:09:00PM +0200, Petr Jelinek wrote:
> > On 24/08/17 19:54, Tom Lane wrote:
> > > sungazer just failed with
> > >
> > > pg_recvlogical exited with code '256', stdout '' and stderr
> > > 'pg_recvlogical: could n
On Mon, Jul 3, 2017 at 11:31:01AM -0700, Emrul wrote:
> Hi hackers,
>
> This question came up again on Reddit:
> https://www.reddit.com/r/PostgreSQL/comments/6kyyev/i_have_hit_the_table_name_length_limit_a_number/
> and I thought I'd echo it here.
>
> I totally am on board with short, descriptiv
In initdb, many global string variables are initialized as empty strings
("") and then checked later with strcmp(), instead of just using NULL.
I think this is probably left over from the shell script conversion.
The style has also spread to pg_basebackup. So here is a patch to clean
that up, and
On Sat, Aug 26, 2017 at 03:31:12PM -0400, Tom Lane wrote:
> +
> +
> +
> + Show foreign tables
> + in information_schema.table_privileges
> + view (Peter Eisentraut)
> +
> +
> +
> + All other relevant information_schema views include
> + foreign tables, bu
A lot of semi-internal code just prints out numeric SPI error codes,
which is not very helpful. We already have an API function
SPI_result_code_string() to convert the codes to a string, so here is a
patch to make more use of that and also document it for external use.
Also included are two patch
Hi,
Following is a proposal for reporting the progress of CLUSTER command:
It seems that the following could be the phases of CLUSTER processing:
1. scanning heap
2. sort tuples
3. writing new heap
4. scan heap and write new heap
5. swapping relation files
6. rebuild index
7. perfo
On Wed, Aug 30, 2017 at 3:39 PM, Fabien COELHO wrote:
>
> Hello,
>
>>> Hmmm. The existing "is_no_vacuum" variable is typed *both* as int (in
>>> "main") and as bool (in "init"), called by main (yuk!). I see no reason
>>> to
>>> choose the bad one for the global:-)
>>
>>
>> Yeah, I think this might
On Wed, Aug 30, 2017 at 5:38 PM, Robert Haas wrote:
> Wow. Just to be clear, I am looking for the BEST case for replacement
> selection, not the worst case. But I would have expected that case to
> be a win for replacement selection, and it clearly isn't. I can
> reproduce your results here.
B
On Wed, Aug 30, 2017 at 6:14 PM, Peter Geoghegan wrote:
> On Wed, Aug 30, 2017 at 3:01 PM, Robert Haas wrote:
>> That may all be true, but my point is that if it wins in some cases,
>> we should keep it -- and proving it no longer wins in those cases will
>> require running tests.
>
> That's not
On Wed, Aug 30, 2017 at 8:02 PM, David Steele wrote:
> On 8/29/17 9:44 PM, Michael Paquier wrote:
>> On Tue, Aug 29, 2017 at 10:59 PM, David Steele wrote:
>>>
>>> Attached is the 9.6 patch. It required a bit more work in func.sgml
>>> than I was expecting so have a close look at that. The rest
On Wed, Aug 30, 2017 at 3:14 PM, Peter Geoghegan wrote:
> This is significantly faster, in a way that's clearly reproducible and
> consistent, despite the fact that we need about 10 merge passes
> without replacement selection, and only have enough memory for 7
> tapes. I think that I could find a
On Thu, Aug 31, 2017 at 8:35 AM, David G. Johnston
wrote:
> Inspired by the syntax documentation for EXPLAIN:
>
> VACUUM [ ( option [, ...] ) ] [ table_def [, ...] ]
>
> where option can be one of:
> FULL
> FREEZE
> VERBOSE
> DISABLE_PAGE_SKIPPING
>
> and where table_def is:
>
On Thu, Aug 31, 2017 at 8:39 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> So, perhaps it would be better to fix that before the next point release?
>
> Sure, I'll get it done on Friday, or tomorrow if I can manage it.
Thanks, Álvaro.
--
Michael
--
Sent via pgsql-hackers mailing list
Michael Paquier wrote:
> On Tue, Aug 29, 2017 at 11:26 AM, Tom Lane wrote:
> > Michael Paquier writes:
> >> I don't like breaking the abstraction of pg_log() with the existing
> >> flags with some kind of pg_debug() layer. The set of APIs present now
> >> in pg_rewind for logging is nice to have,
On Wed, Aug 30, 2017 at 4:08 PM, Bossart, Nathan
wrote:
> On 8/30/17, 5:37 PM, "Michael Paquier" wrote:
> > Yeah... Each approach has its cost and its advantages. It may be
> > better to wait for more opinions, no many people have complained yet
> > that for example a list of columns using twice
On 8/30/17, 5:37 PM, "Michael Paquier" wrote:
> Yeah... Each approach has its cost and its advantages. It may be
> better to wait for more opinions, no many people have complained yet
> that for example a list of columns using twice the same one fails.
Sounds good to me.
> +VACUUM [ FULL ] [ FRE
On Wed, Aug 30, 2017 at 1:47 AM, Bossart, Nathan wrote:
> On 8/28/17, 11:26 PM, "Michael Paquier" wrote:
>> About the de-duplication patch, I have to admit that I am still not a
>> fan of doing such a thing. Another road that we could take is to
>> simply complain with a proper error message if:
On Tue, Aug 29, 2017 at 11:26 AM, Tom Lane wrote:
> Michael Paquier writes:
>> I don't like breaking the abstraction of pg_log() with the existing
>> flags with some kind of pg_debug() layer. The set of APIs present now
>> in pg_rewind for logging is nice to have, and I think that those debug
>>
On Wed, Aug 30, 2017 at 3:01 PM, Robert Haas wrote:
> That may all be true, but my point is that if it wins in some cases,
> we should keep it -- and proving it no longer wins in those cases will
> require running tests.
That's not hard. On my laptop:
$ pgbench -i -s 100
...
postgres=# set work
"Regina Obe" writes:
> I think this thread covers most of the issues.
> https://lists.osgeo.org/pipermail/postgis-devel/2017-August/026355.html
> My thought was is it possible for pg_upgrade to be taught to use CREATE
> EXENSION if asked?
We intentionally *don't* do that; pg_dump goes to a lot o
On Wed, Aug 30, 2017 at 4:18 PM, Peter Geoghegan wrote:
> On Wed, Aug 30, 2017 at 12:51 PM, Robert Haas wrote:
>> On Fri, Jul 14, 2017 at 6:20 PM, Peter Geoghegan wrote:
>>> With the additional enhancements made to Postgres 10, I doubt that
>>> there are any remaining cases where it wins.
>>
>>
Alvaro Herrera writes:
> Robert Haas wrote:
>> In this case,
>> I'll blame the fact that we allow a role to be dropped while there are
>> users connected using that role.
> Actually, my first comment when Pavan mentioned this on IM was that we
> should look into fixing that problem sometime. It'
I'm not too familiar with the innards of pg_upgrade, but we've been
discussing it a lot for past couple of days and how it's causing issues for
PostGIS upgrades.
I think this thread covers most of the issues.
https://lists.osgeo.org/pipermail/postgis-devel/2017-August/026355.html
My thought was
Robert Haas wrote:
> In this case,
> I'll blame the fact that we allow a role to be dropped while there are
> users connected using that role. That's about as sensible as allowing
> a table to be dropped while there are users reading from it, or a
> database to be dropped while there are users co
On Wed, Aug 30, 2017 at 12:48 PM, Robert Haas wrote:
> These are separate topics. They should each be discussed on their own
> thread. Please don't hijack this thread to talk about something else.
I don't think that that is a fair summary.
Heikki has done a number of things in this area, of wh
On Wed, Aug 30, 2017 at 12:51 PM, Robert Haas wrote:
> On Fri, Jul 14, 2017 at 6:20 PM, Peter Geoghegan wrote:
>> With the additional enhancements made to Postgres 10, I doubt that
>> there are any remaining cases where it wins.
>
> The thing to do about that would be to come up with some cases w
On Fri, Jul 14, 2017 at 6:20 PM, Peter Geoghegan wrote:
> With the additional enhancements made to Postgres 10, I doubt that
> there are any remaining cases where it wins.
The thing to do about that would be to come up with some cases where
someone might plausibly think it would win and benchmark
On Wed, Aug 30, 2017 at 2:54 PM, Peter Geoghegan wrote:
> I noticed that this is in the upcoming CF 1 for v11. I'm signed up to review.
>
> I'd like to point out that replacement selection is also obsolete,
> which is something I brought up recently [1]. I don't actually have
> any feature-driven
On Wed, Aug 30, 2017 at 12:47 PM, Ashutosh Bapat
wrote:
> +1. I think we should just pull out the OIDs from partition descriptor.
Like this? The first patch refactors the expansion of a single child
out into a separate function, and the second patch implements EIBO on
top of it.
I realized whil
On Mon, Feb 27, 2017 at 2:45 PM, Peter Geoghegan wrote:
> Since we have an awful lot of stuff in the last CF, and this patch
> doesn't seem particularly strategic, I've marked it "Returned with
> Feedback".
I noticed that this is in the upcoming CF 1 for v11. I'm signed up to review.
I'd like to
Amit Kapila writes:
> On Tue, Aug 29, 2017 at 10:05 PM, Tom Lane wrote:
>> If no objections, I'll do the additional legwork and push.
> No objections.
Done. Out of curiosity, I pushed just the rescan-param patch to the
buildfarm to start with, to see if anything would fall over, and indeed
som
On Wed, Aug 30, 2017 at 9:42 PM, Robert Haas wrote:
> On Wed, Aug 30, 2017 at 6:08 AM, Amit Khandekar
> wrote:
>> On 25 August 2017 at 23:58, Robert Haas wrote:
>>> That just leaves indexes. In a world where keystate, tupslot, and
>>> tupmap are removed from the PartitionDispatchData, you must
On Wed, Aug 30, 2017 at 5:02 AM, Alvaro Herrera
wrote:
> Eh, if you want to optimize it for the case where debug output is not
> enabled, make sure to use ereport() not elog(). ereport()
> short-circuits evaluation of arguments, whereas elog() does not.
I should do that, but it's still not reall
On Wed, Aug 30, 2017 at 6:08 AM, Amit Khandekar wrote:
> On 25 August 2017 at 23:58, Robert Haas wrote:
>> That just leaves indexes. In a world where keystate, tupslot, and
>> tupmap are removed from the PartitionDispatchData, you must need
>> indexes or there would be no point in constructing a
On Wed, Aug 30, 2017 at 10:31 AM, Robert Haas wrote:
> On Wed, Aug 30, 2017 at 9:22 AM, Ashutosh Bapat
> wrote:
>> Amit's patches seem to be addressing the third point here. But the
>> expansion is not happening in breadth-first manner. We are expanding
>> all the partitioned partitions first and
On 2017-08-30 16:24, Tom Lane wrote:
Alexander Korotkov writes:
It doesn't seems to make sense to consider this patch unless we get
access
to suitable Power machine to reproduce benefits.
This is why I'm going to mark this patch "Returned with feedback".
Once we would get access to the appropr
On Wed, Aug 30, 2017 at 10:43 AM, amul sul wrote:
> Thanks for the suggestion, I have updated 0002-patch accordingly.
> Using this I found some strange behaviours as follow:
>
> 1) standard and extended0 output for the jsonb_hash case is not same.
> 2) standard and extended0 output for the hash_ra
Hi,
To make it clear: I don't have a strong opinion on these, I'm happy
enough to commit the patch as is, minus one unrelated change. I just
think it should be discussed.
On 2017-08-30 07:01:54 -0400, Peter Eisentraut wrote:
> On 8/30/17 00:45, Andres Freund wrote:
> > 1) Currently the default
On Wed, Aug 30, 2017 at 9:58 AM, Tom Lane wrote:
> The problem here is exactly that we cannot transmit the leader's
> state to the worker. You can't blame it on SET ROLE, because
> I didn't do one.
Hmm, that's a good reason for holding it blameless. In this case,
I'll blame the fact that we all
On Tue, Aug 29, 2017 at 11:48 PM, Robert Haas wrote:
> On Tue, Aug 22, 2017 at 8:14 AM, amul sul wrote:
> > Attaching patch 0002 for the reviewer's testing.
>
> I think that this 0002 is not something we can think of committing
> because there's no guarantee that hash functions will return the s
On Wed, Aug 30, 2017 at 9:22 AM, Ashutosh Bapat
wrote:
> Amit's patches seem to be addressing the third point here. But the
> expansion is not happening in breadth-first manner. We are expanding
> all the partitioned partitions first and then leaf partitions. So
> that's not exactly "breadth-first
Robert Haas writes:
> On Wed, Aug 30, 2017 at 9:20 AM, Tom Lane wrote:
>> I"m okay with a narrow solution if SET ROLE really is
>> the only problem, but at this stage I'm not convinced of that.
> I don't think the problem with role is that it's catalog-dependent,
> but that the effective value i
And another patch to restore behavior to replication origin drop.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 66c1b1072feb95a08739d9a752f1d6fc73d1dc77 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date:
On Wed, Aug 30, 2017 at 9:20 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 30, 2017 at 8:04 AM, Tom Lane wrote:
>>> We might need to redesign the GUC-propagation mechanism so it sends
>>> the various internal representations of GUC values, not the user-visible
>>> strings.
>
>> That w
Craig Ringer wrote:
> > FWIW, I also don't think it's ok to just change the behaviour
> > unconditionally and without a replacement for existing behaviour.
>
> Seems like it just needs a new argument nowait DEFAULT false
I added a WAIT flag to DROP_REPLICATION_SLOT, preliminary patch
attached.
Alexander Korotkov writes:
> It doesn't seems to make sense to consider this patch unless we get access
> to suitable Power machine to reproduce benefits.
> This is why I'm going to mark this patch "Returned with feedback".
> Once we would get access to the appropriate machine, I will resubmit thi
On Wed, Aug 30, 2017 at 8:33 AM, Robert Haas wrote:
> On Tue, Aug 29, 2017 at 10:36 PM, Amit Langote
> wrote:
>>> I keep having the feeling that this is a big patch with a small patch
>>> struggling to get out. Is it really necessary to change
>>> RelationGetPartitionDispatchInfo so much or coul
Robert Haas writes:
> On Wed, Aug 30, 2017 at 8:04 AM, Tom Lane wrote:
>> We might need to redesign the GUC-propagation mechanism so it sends
>> the various internal representations of GUC values, not the user-visible
>> strings.
> That would probably be better in the long run, but I'm not keen
On Wed, Aug 30, 2017 at 8:04 AM, Tom Lane wrote:
> We might need to redesign the GUC-propagation mechanism so it sends
> the various internal representations of GUC values, not the user-visible
> strings.
That would probably be better in the long run, but I'm not keen to do
it in a back-branch un
On Thu, Apr 6, 2017 at 5:38 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Thu, Apr 6, 2017 at 5:37 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> On Thu, Apr 6, 2017 at 2:16 AM, Andres Freund wrote:
>>
>>> On 2017-04-03 11:56:13 -0700, Andres Freund wrote:
>>>
On Thu, Jun 1, 2017 at 4:10 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Wed, May 31, 2017 at 7:18 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> On Wed, May 31, 2017 at 6:53 PM, Tom Lane wrote:
>>
>>> Alexander Korotkov writes:
>>> > I've discovered that Po
Masahiko Sawada wrote:
> On Fri, Aug 25, 2017 at 4:12 PM, Antonin Houska wrote:
> > Attached is a draft patch to allow extension to write log messages to a
> > separate file.
>
> Does it allow postgres core code to write log messages to multiple log
> files as well? I can imagine a use case whe
Hi Rafia,
On 17 August 2017 at 14:12, Amit Khandekar wrote:
> But for all of the cases here, partial
> subplans seem possible, and so even on HEAD it executed Partial
> Append. So between a Parallel Append having partial subplans and a
> Partial Append having partial subplans , the cost differenc
Amit Kapila writes:
> I am able to reproduce this without involving session authorization
> guc as well. One needs to drop the newly created role from another
> session, then also we can see the same error.
Hm. I suspect the basic shape of what's happening here is "an existing
session can conti
Peter Geoghegan wrote:
> > Your patch brings us one step closer to that goal. (The book says
> > that this approach is good far sparse bitsets, but your comment says
> > that we expect something near 50%. That's irrelevant anyway since a
> > future centralised popcount() implementation would do
On Wed, Aug 30, 2017 at 5:19 PM, Amit Kapila
wrote:
>
>
> I am able to reproduce this without involving session authorization
> guc as well. One needs to drop the newly created role from another
> session, then also we can see the same error.
>
>
Yeah, that's how I first created the case. But co
On Sun, Aug 27, 2017 at 8:31 PM, Michael Malis wrote:
> (Sorry David. I initially replied only to you)
>
> Ok. I've attached a patch of a proof-of-concept. I have a few
> questions about tests.
>
> What is typical workflow to add tests for changes to the planner?
Add submitted patches at commitfe
I wrote:
> I can duplicate this in HEAD and v10, but not 9.6, so I've added it
> as an open issue for v10. No idea what broke it.
Oh, scratch that: the issue exists in 9.6, it's just that the particular
test query you're using here does not generate a parallelized plan in
9.6, as shown by "explai
On Wed, Aug 30, 2017 at 7:39 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Tue, Aug 29, 2017 at 10:05 PM, Tom Lane wrote:
>> ! /* Make sure any existing workers are gracefully shut down */
>> ExecShutdownGatherWorkers(node);
>
>> The above call doesn't ensure the shutdown. It just ensures th
On Wed, Aug 30, 2017 at 5:11 PM, Robert Haas wrote:
> On Wed, Aug 30, 2017 at 6:58 AM, Pavan Deolasee
> wrote:
>> It's quite possible that I don't understand the differences in "role" and
>> "session authorization", but it still looks like a bug to me. May be
>> SerializeGUCState() should check i
Pavan Deolasee writes:
> The last statement in this test fails with an error:
> ERROR: role "testuser1" does not exist
> CONTEXT: parallel worker
I can duplicate this in HEAD and v10, but not 9.6, so I've added it
as an open issue for v10. No idea what broke it.
regard
On Wed, Aug 30, 2017 at 6:58 AM, Pavan Deolasee
wrote:
> It's quite possible that I don't understand the differences in "role" and
> "session authorization", but it still looks like a bug to me. May be
> SerializeGUCState() should check if SetRoleIsActive is true and only then
> save the role info
Amit Kapila writes:
> On Tue, Aug 29, 2017 at 10:05 PM, Tom Lane wrote:
> ! /* Make sure any existing workers are gracefully shut down */
> ExecShutdownGatherWorkers(node);
> The above call doesn't ensure the shutdown. It just ensures that we
> receive all messages from parallel workers. Basi
Hi Michael,
Thanks for reviewing!
On 8/29/17 9:44 PM, Michael Paquier wrote:
> On Tue, Aug 29, 2017 at 10:59 PM, David Steele wrote:
>>
>> Attached is the 9.6 patch. It required a bit more work in func.sgml
>> than I was expecting so have a close look at that. The rest was mostly
>> removing i
On 8/30/17 00:45, Andres Freund wrote:
> 1) Currently the default for {min,max}_wal_size depends on the segment
>size. Given that the segment size is about to be configurable, that
>seems confusing.
On the one hand, I agree that it seems confusing and unnecessary to vary
this with the segm
Hello,
While investing an issue in Postgres-XL 10, I came across this rather
surprisingly behaviour in PG master. See this test case:
create role testuser1;
set role to testuser1;
show role; -- shows testuser1
-- reset back to default role
reset session authorization ;
show role; -- shows none
On Tue, Aug 29, 2017 at 10:05 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Tue, Aug 29, 2017 at 8:32 AM, Robert Haas wrote:
>>> There's already ExecParallelReinitialize, which could be made to walk
>>> the nodes in addition to what it does already, but I don't understand
>>> exactly what else
On 25 August 2017 at 23:58, Robert Haas wrote:
>
> That just leaves indexes. In a world where keystate, tupslot, and
> tupmap are removed from the PartitionDispatchData, you must need
> indexes or there would be no point in constructing a
> PartitionDispatchData object in the first place; any app
On 2017/08/30 12:03, Robert Haas wrote:
> On Tue, Aug 29, 2017 at 10:36 PM, Amit Langote
> wrote:
>>> I keep having the feeling that this is a big patch with a small patch
>>> struggling to get out. Is it really necessary to change
>>> RelationGetPartitionDispatchInfo so much or could you just do
On 2017/08/30 9:13, Amit Langote wrote:
On 2017/08/29 20:18, Etsuro Fujita wrote:
On 2017/08/25 22:26, Robert Haas wrote:
On Wed, Aug 23, 2017 at 4:55 AM, Etsuro Fujita
wrote:
Agreed, but I'd vote for fixing this in v10 as proposed; I agree that just
ripping the CheckValidResultRel checks out
On Wed, Aug 30, 2017 at 2:43 AM, Robert Haas wrote:
> On Tue, Jul 4, 2017 at 12:33 AM, Amit Kapila wrote:
>> I have updated the patch to support wait events and moved it to upcoming CF.
>
> This patch doesn't apply any more, but I made it apply with a hammer
> and then did a little benchmarking (
82 matches
Mail list logo
