po 25. 3. 2019 v 20:40 odesílatel Erik Rijkers napsal:
> On 2019-03-24 10:32, Pavel Stehule wrote:
> > ne 24. 3. 2019 v 10:25 odesílatel Erik Rijkers napsal:
> >
> >> On 2019-03-24 06:57, Pavel Stehule wrote:
> >> > Hi
> >> >
> >> > rebase against current master
> >>
> >> I ran into this:
> >>
Hi
ne 24. 3. 2019 v 6:57 odesílatel Pavel Stehule
napsal:
> Hi
>
> rebase against current master
>
fixed issue IF NOT EXISTS & related regress tests
Regards
Pavel
> Regards
>
> Pavel
>
schema-variables-20190326.patch.gz
Description: application/gzip
Hi, kirk-san.
> From: Jamison, Kirk
> Ok. So I'd only take a look at TCP_USER_TIMEOUT parameter for now (this
> CommitFest), and maybe we could resume the discussion on socket_timeout
> in the future.
Yes, please.
> Your patch applies, however in TCP_backend_v10 patch, your documentation
> is
On Wed, Mar 13, 2019 at 2:27 PM Thomas Munro wrote:
> [...] Aside from some refactoring which I
> think looks good anyway and prepares for future patches, the main
> effect of this patch is to force the checkpointer to open and close
> the files every time which seems OK to me.
I've been trying
On Tue, Mar 26, 2019 at 1:27 PM Michael Paquier wrote:
> On Sun, Mar 24, 2019 at 10:30:47PM +1100, Haribabu Kommi wrote:
> > With the above additional options, the pg_basebackup is able to control
> > the access permissions of the backup files, but when it comes to tar mode
> > all the files are
Hi Nagaura-san,
On Monday, March 25, 2019 2:26 PM (GMT+9), Ryohei Nagaura wrote:
>Yes, I want to commit TCP_USER_TIMEOUT patches in PG12.
>Also I'd like to continue to discuss about socket_timeout after this CF.
Ok. So I'd only take a look at TCP_USER_TIMEOUT parameter for now (this
Patch tester didn't like that one bit. Here's v10 with the fixup
applied.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 4e352a1b3a0730f2c3e91e6d62335d6db6823796 Mon Sep 17 00:00:00 2001
From: Alvaro
Hi
On 2019-Mar-25, Andres Freund wrote:
> I've not followed this thread at all, so I might just be out of my depth
> here. From my POV, a later patch in the yet-to-be-applied patchqueue
> moves the main part of cluster below the table AM (as there's enough low
> level details, e.g. dealing with
On Mon, Mar 25, 2019 at 04:23:34PM +0100, Peter Eisentraut wrote:
> Let's do it. :-)
I am pretty sure that this has been said at least once since 2012.
> I've gone over this patch a few more times. I've read all the
> discussion since 2012 again and made sure all the issues were addressed.
> I
On Sat, Mar 23, 2019 at 10:52:52AM -0400, Stephen Frost wrote:
> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>> I agree the feature is important, it just does not seem like the patch
>> is RFC and given security implications I err on the side of safety here.
>
> Agreed.
Based on the
On Sun, Mar 24, 2019 at 10:30:47PM +1100, Haribabu Kommi wrote:
> With the above additional options, the pg_basebackup is able to control
> the access permissions of the backup files, but when it comes to tar mode
> all the files are sent from the server and stored as it is in backup, to
> support
On Mon, Mar 25, 2019 at 05:57:50PM -0400, Tom Lane wrote:
> In short, I'm not convinced that most of this patch is an improvement
> on the status quo. I think we'd be best off to just take the idea
> of explicitly mentioning adding --jobs to a manual run, ie roughly
Yeah, no objections from here
Hi,
On 2019-03-25 23:11:00 -0300, Alvaro Herrera wrote:
> On 2019-Mar-25, Alvaro Herrera wrote:
>
> > Here's v6 of this patch. I have rebased on top of today's CLUSTER
> > monitoring, as well as on table AM commits. The latter caused a bit of
> > trouble, as now the number of blocks processed
On Tue, Mar 26, 2019 at 10:04:48AM +0900, Tatsuro Yamada wrote:
> Hope this feature will help DBA and user. :)
Congrats, Yamada-san.
--
Michael
signature.asc
Description: PGP signature
On Tue, 26 Mar 2019 at 09:02, Julien Rouhaud wrote:
> FTR this patch doesn't apply since single child [Merge]Append
> suppression (8edd0e7946) has been pushed.
Thanks for letting me know. I've attached v14 based on current master.
--
David Rowley http://www.2ndQuadrant.com/
On 2019-Mar-25, Alvaro Herrera wrote:
> Here's v6 of this patch. I have rebased on top of today's CLUSTER
> monitoring, as well as on table AM commits. The latter caused a bit of
> trouble, as now the number of blocks processed by a scan is not as easy
> to get as before; I added a new entry
Hi all,
I have just committed a fix for a crash with the handling of partition
bounds using column references which has been discussed here:
https://www.postgresql.org/message-id/15668-0377b1981aa1a...@postgresql.org
And while discussing on the matter with Amit, the point has been
raised that
On 2019/03/26 1:53, Alvaro Herrera wrote:
> Here's v6 of this patch. I have rebased on top of today's CLUSTER
> monitoring, as well as on table AM commits. The latter caused a bit of
> trouble, as now the number of blocks processed by a scan is not as easy
> to get as before; I added a new entry
Hi,
On 2019/03/26 7:38, Alvaro Herrera wrote:
> v9 attached; this one's final AFAICT.
Agreed.
Thanks,
Amit
On 2019-Mar-25, Alvaro Herrera wrote:
> v9 attached; this one's final AFAICT.
Actually, I propose this fixup. It doesn't change the current output,
but of course it affects how this works with my patch in
https://postgr.es/m/20190321215420.GA22766@alvherre.pgsql
The v9 patch does not show
Hi,
On 2019/03/26 10:15, Michael Paquier wrote:
> Done as you suggested, with a minimal set enough to trigger the crash,
> still the error message is rather misleading as you would expect :)
Thanks for committing.
>> A separate thread will definitely attract more attention, at least in due
>>
On Fri, Mar 22, 2019 at 4:06 PM Masahiko Sawada
wrote:
>
> Attached the updated version patch. 0001 patch allows all existing
> vacuum options an boolean argument. 0002 patch introduces parallel
> lazy vacuum. 0003 patch adds -P (--parallel) option to vacuumdb
> command.
>
Thanks for sharing
On Fri, Mar 22, 2019 at 02:49:42PM +0900, Amit Langote wrote:
> This comment sounds a bit misleading. The code above this "did" find
> field names, but there were too many. What this comment should mention is
> that parsing didn't return a single field name, which is the format that
> the code
Hi Robert and Reviewers!
On 2019/03/26 0:02, Robert Haas wrote:
On Sun, Mar 24, 2019 at 9:02 PM Tatsuro Yamada
wrote:
Please find attached files. :)
Committed. Thanks!
Thank you!
Hope this feature will help DBA and user. :)
Regards,
Tatsuro Yamada
NTT Open Source Software Center
Dear David,
I have a will and already read the patch, but I thought it's not my turn.
Sorry.
Adrien,
> I did not find any test for log_min_duration that could help me. LCOV
> indicate
> there is no tests on this part (look check_log_duration()):
>
Hi,
For the tableam work I'd like to remove heapam.h from
nodeModifyTable.c. The only remaining impediment to that is a call to
setLastTid(), which is defined in tid.c but declared in heapam.h.
That doesn't seem like a particularly accurate location, it doesn't
really have that much to do with
On 2019/03/26 0:21, Robert Haas wrote:
> On Wed, Mar 20, 2019 at 12:37 AM Amit Langote
> wrote:
>> That's because get_relation_constraints() no longer (as of PG 11) includes
>> the partition constraint for SELECT queries.
>
> What commit made that change?
That would be 9fdb675fc5d2 (faster
On Tue, Mar 26, 2019 at 3:23 AM Heikki Linnakangas wrote:
> Looks good.
>
> I started to write a patch to use XID & epoch in dealing with GiST page
> deletions [1], and I really could've used an epoch to go with
> RecentGlobalXmin. I presume that would be pretty straightforward to have
> with
On 3/24/19 8:36 AM, Dean Rasheed wrote:
> On Sun, 24 Mar 2019 at 00:17, David Rowley
> wrote:
>>
>> On Sun, 24 Mar 2019 at 12:41, Tomas Vondra
>> wrote:
>>>
>>> On 3/21/19 4:05 PM, David Rowley wrote:
>>
29. Looking at the tests I see you're testing that you get bad
estimates
ove non-MV
> stats, then is it right for these tests to fail? What should the
> developer do in the case? update the expected result? remove the test?
> It's not so clear.
>
I think such changes would affect a number of other places in regression
tests (changing plans, ...), so I don't see why fixing these tests would
be any different.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
0001-multivariate-MCV-lists-20190325.patch.gz
Description: application/gzip
0002-multivariate-histograms-20190325.patch.gz
Description: application/gzip
On Tue, 26 Mar 2019 at 09:00, Tom Lane wrote:
>
> David Rowley writes:
> > [ drop-useless-merge-appends-15.patch ]
>
> Pushed with some minor adjustments.
Thank for all your work on this, and thanks for the final push.
FWIW, you should probably have credited yourself as the main author
since I
On Tuesday, March 19, 2019 12:35 AM, Tom Lane wrote:
> I noticed a few things that seem a bit fishy about pg_upgrade.
Attached are three patches which takes a stab at the issues raised here (and
the discussion in this thread):
0001 - Enforces the version check to the full version including the
Chapman Flack writes:
> Thanks for the review! Yes, that part of this commitfest entry has been
> committed already and will appear in the next minor releases of those
> branches.
Indeed, thanks for verifying that this fixes your problem.
> That leaves only one patch in this commitfest entry
Andres Freund writes:
> I was kinda hoping to keep block numbers out of the "main" APIs, to
> avoid assuming everything is BLCKSZ based. I don't have a particular
> problem allowing an optional setscanlimits type callback that works with
> block numbers. The planner could check its presence and
On 03/25/19 18:03, Ryan Lambert wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:not tested
Hi,
Thanks for the
On Thu, Mar 21, 2019 at 4:39 PM Tom Lane wrote:
> Thomas Munro writes:
> > Peter E added some nice tests for LDAP and Kerberos, but they assume
> > you have Homebrew when testing on a Mac. Here's a patch to make them
> > work with MacPorts too (a competing open source port/package
> >
On Mon, Mar 25, 2019 at 09:08:23AM -0400, Robert Haas wrote:
> If we're going to go with -g {inherit|none|group} then -g inherit
> ought to do what was originally proposed on this thread -- i.e. set
> the directory permissions to match the contents. I don't think that's
> a change that can or
v9 attached; this one's final AFAICT.
On 2019-Mar-25, Peter Eisentraut wrote:
> relispartition was added in PG10, so the conditional in
> describeOneTableDetails() seems wrong.
Hmm, yeah, we weren't using it anyway (since we can only use the new
display with pg_partition_ancestors which is new
On Mon, Mar 25, 2019 at 10:29:46AM +0100, Fabien COELHO wrote:
> I have run the non regression tests. I'm not sure of what scenarii are
> covered there, but probably not an interruption in the middle of a fsync,
> specially if fsync is usually disabled to ease the tests:-)
Force the tool to stop
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I tested the master branch (commit 8edd0e7), REL_11_STABLE (commit
Jesper Pedersen writes:
> [ v9_0001-Highlight-that-the-jobs-option-isn-t-passed-down-to-.patch ]
Now that I've looked at this, it seems like it's fairly confused about
what the proposed VACUUMDB_OPTS variable would actually do for you.
If you're going to run vacuumdb directly, it hardly seems
Hi,
On 2019-03-18 22:35:05 +1300, David Rowley wrote:
> The commit message in 8586bf7ed mentions:
>
> > Subsequent commits will incrementally abstract table access
> > functionality to be routed through table access methods. That change
> > is too large to be reviewed & committed at once, so
Hi,
On 2019-03-15 18:42:40 +1300, Edmund Horner wrote:
> I've had to adapt it to use the table scan API. I've got it compiling
> and passing tests, but I'm uneasy about some things that still use the
> heapam API.
>
> 1. I call heap_setscanlimits as I'm not sure there is a tableam
> equivalent.
I
On 3/25/19 3:44 PM, Andrew Dunstan wrote:
> On 3/21/19 3:13 AM, Michael Paquier wrote:
>> On Thu, Mar 21, 2019 at 12:45:57PM +1100, Haribabu Kommi wrote:
>>> The commit f2ab389 is later back-patch to version till 9.3 in commit
>>> 19acfd65. I guess that building the windows installer for all
As there are now 3 locking times on pgss hash struct, one day or an other,
somebody will ask for a GUC to disable this feature (to be able to run pgss
unchanged with only one lock as today).
With this GUC, pgss_store should be able to store the query text and
accumulated
execution duration in
Greetings,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On Thu, 21 Mar 2019 at 00:39, PG Bug reporting form
> wrote:
> >
> > This fails, seemingly because the RLS on 'bar' is being checked by alice,
> > instead of the view owner bob:
>
> Yes I agree, that appears to be a bug. The subquery
On Sun, Mar 24, 2019 at 11:06 AM David Rowley
wrote:
>
> On Sat, 23 Mar 2019 at 19:42, Tom Lane wrote:
> >
> > David Rowley writes:
> > > On Sat, 23 Mar 2019 at 05:40, Tom Lane wrote:
> > >> BTW, another thing we could possibly do to answer this objection is to
> > >> give the ordered-Append
David Rowley writes:
> [ drop-useless-merge-appends-15.patch ]
Pushed with some minor adjustments.
> I can get a plan that does end up with Result nodes above a Scan node.
> create table rangep (a int, b int) partition by range (a);
> create table rangep1 partition of rangep for values from(0)
On 3/21/19 3:13 AM, Michael Paquier wrote:
> On Thu, Mar 21, 2019 at 12:45:57PM +1100, Haribabu Kommi wrote:
>> The commit f2ab389 is later back-patch to version till 9.3 in commit
>> 19acfd65. I guess that building the windows installer for all the
>> versions using the same visual studio is
On 2019-03-24 10:32, Pavel Stehule wrote:
ne 24. 3. 2019 v 10:25 odesílatel Erik Rijkers napsal:
On 2019-03-24 06:57, Pavel Stehule wrote:
> Hi
>
> rebase against current master
I ran into this:
(schema 'varschema2' does not exist):
drop variable varschema2.testv cascade;
ERROR: schema
Hello Edmund,
Thanks for the review.
> I was a bit curious about the need for "set role" in the reproduction,
> but I see that it's because RI_Initial_Check does some checks to see
> if a simple SELECT can be used, and one of the checks is for basic
> table permissions.
>
I think to reproduce
Andres Freund writes:
> On 2019-03-25 13:53:32 -0400, Tom Lane wrote:
>> One idea that might be useful is to have walsenders refuse to transmit
>> any logical-replication data if they see wal_level is too low. That
>> would get users' attention pretty quickly.
> They do:
Oh, OK, then this
I pushed the refactoring now, to extract the progress reporting to a separate
function. That seems like an improvement independently from the rest of the
patch.
Sure.
I'll take another look at the rest, probably tomorrow.
Ok.
Attached is the remainder of the patch rebased to current
Hi,
On 2019-03-25 13:53:32 -0400, Tom Lane wrote:
> One idea that might be useful is to have walsenders refuse to transmit
> any logical-replication data if they see wal_level is too low. That
> would get users' attention pretty quickly.
They do:
/*
* Load previously initiated logical slot
Hi,
On 2019-03-24 23:54:53 +1300, David Rowley wrote:
> This results in an Assert failure on master and an elog ERROR prior to
> c2fe139c201:
>
> create role test_role with login;
> create table ref(a int primary key);
> grant references on ref to test_role;
> set role test_role;
> create table
Robert Haas writes:
> On Mon, Mar 25, 2019 at 10:15 AM David Fetter wrote:
>>> I do not believe this is practical either. GUC manipulation cannot
>>> look at the catalogs.
>> In this case, it really has to do something. Is setting GUCs a path so
>> critical it can't take one branch?
> No, but
On Mon, Mar 25, 2019 at 10:15 AM David Fetter wrote:
> > I do not believe this is practical either. GUC manipulation cannot
> > look at the catalogs.
>
> In this case, it really has to do something. Is setting GUCs a path so
> critical it can't take one branch?
No, but that has about zero to do
On Mon, Mar 25, 2019 at 12:33 PM Tom Lane wrote:
> Robert Haas writes:
> > Maybe we don't really need the word "tuple". Like we could just make
> > it slot_store_heap() or SlotStoreHeap(). A slot can only store a
> > tuple, after all.
>
> I don't think it's wise to think of these things as
Hi,
On 2019-03-25 12:45:36 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-03-25 12:33:38 -0400, Tom Lane wrote:
> >> I don't think it's wise to think of these things as just "slots";
> >> that name is way too generic. They are "tuple slots", and so that
> >> word has to stay in the
Here's v6 of this patch. I have rebased on top of today's CLUSTER
monitoring, as well as on table AM commits. The latter caused a bit of
trouble, as now the number of blocks processed by a scan is not as easy
to get as before; I added a new entry point heapscan_get_blocks_done on
heapam.c to
Andres Freund writes:
> On 2019-03-25 12:33:38 -0400, Tom Lane wrote:
>> I don't think it's wise to think of these things as just "slots";
>> that name is way too generic. They are "tuple slots", and so that
>> word has to stay in the relevant function names.
> Hm. But we already have
Hi,
On 2019-03-25 12:33:38 -0400, Tom Lane wrote:
> Robert Haas writes:
> > Maybe we don't really need the word "tuple". Like we could just make
> > it slot_store_heap() or SlotStoreHeap(). A slot can only store a
> > tuple, after all.
>
> I don't think it's wise to think of these things as
Robert Haas writes:
> Maybe we don't really need the word "tuple". Like we could just make
> it slot_store_heap() or SlotStoreHeap(). A slot can only store a
> tuple, after all.
I don't think it's wise to think of these things as just "slots";
that name is way too generic. They are "tuple
Hi,
On 2019-03-25 12:05:52 -0400, Robert Haas wrote:
> On Mon, Mar 25, 2019 at 11:57 AM Andres Freund wrote:
> > I think I might go for slot_store_heap_tuple etc, given that a lot of
> > those accessors have been slot_ for about ever. What do you think?
>
> I don't have a super-strong feeling
On Sun, Mar 24, 2019 at 11:23 PM Amit Kapila wrote:
> Fair point. Can such an error message change break any application?
> I see some cases where users have check based on Error Code, but not
> sure if there are people who have check based on error messages.
I'm sure there are -- in fact, I've
On 10/03/2019 13:26, Fabien COELHO wrote:
Attached is a rebase.
I pushed the refactoring now, to extract the progress reporting to a
separate function. That seems like an improvement independently from the
rest of the patch. I'll take another look at the rest, probably tomorrow.
- Heikki
On Mon, Mar 25, 2019 at 11:57 AM Andres Freund wrote:
> I think I might go for slot_store_heap_tuple etc, given that a lot of
> those accessors have been slot_ for about ever. What do you think?
I don't have a super-strong feeling about it, although changing the
case convention might confuse a
Hi,
On 2019-03-25 11:20:13 -0400, Robert Haas wrote:
> While reviewing some zheap code last week, I noticed that the naming
> of the ExecStore*Tuple() functions seems a bit unfortunate. One
> reason is that we are now using slots in all kinds of places other
> than the executor, so that the
On 2019-Mar-25, Robert Haas wrote:
> On Mon, Mar 25, 2019 at 11:27 AM Alvaro Herrera
> wrote:
> > Should we keep ExecStoreTuple as a compatibility macro for third party
> > code?
>
> I think that might be rather dangerous, actually, because slots now
> have a type, which they didn't before.
On Mon, Mar 25, 2019 at 11:27 AM Alvaro Herrera
wrote:
> Should we keep ExecStoreTuple as a compatibility macro for third party
> code?
I think that might be rather dangerous, actually, because slots now
have a type, which they didn't before. You have to use the correct
function for the kind of
On 25.03.2019 11:17, David Steele wrote:
On 3/15/19 2:11 AM, Nikita Glukhov wrote:
Attached 10th versions of the patches.
Fixed two bugs in patches 3 and 10 (see below).
Patch 3 was extracted from the main patch 5 (patch 4 in v9).
This patch no longer applies so marking Waiting on Author.
I agree about taking out the "Exec" part of the name.
On 2019-Mar-25, Robert Haas wrote:
> I'm not sure exactly what names would be better. Perhaps just change
> the "Exec" prefix to "Slot", e.g. SlotStoreHeapTuple(). Or maybe put
> InSlot at the end, like StoreHeapTupleInSlot(). Or just take
On 2019-Mar-23, Fabien COELHO wrote:
> > Per your request, here is a patch which removes \cset from pgbench. Sigh.
>
> Again, only the removal is a little deeper. This lifts the constraint about
> not using empty queries in a compound statement, at the price of some added
> logic to detect the
On Wed, Mar 20, 2019 at 12:37 AM Amit Langote
wrote:
> That's because get_relation_constraints() no longer (as of PG 11) includes
> the partition constraint for SELECT queries.
What commit made that change?
This sounds to me like maybe it should be an open item.
--
Robert Haas
EnterpriseDB:
Hi,
While reviewing some zheap code last week, I noticed that the naming
of the ExecStore*Tuple() functions seems a bit unfortunate. One
reason is that we are now using slots in all kinds of places other
than the executor, so that the "Exec" prefix seems a bit out of place.
However, you could
On 25/03/2019 12:49, Thomas Munro wrote:
On Mon, Mar 25, 2019 at 5:01 PM Thomas Munro wrote:
New version attached. I'd like to commit this for PG12.
Here is a follow-up sketch patch that shows FullTransactionId being
used in the transaction stack, so you can call eg
I noticed you lost a couple of test cases in v14, so I added them back.
I also added a case where your implementation returns a different number
of rows compared to vanilla:
select * from sl t1, sl t2 where t1.a = t2.a and t1.b = 1;
Please see the attached v15.
--
Alexander Kuzmenkov
On Mon, Mar 25, 2019 at 3:51 AM David Steele wrote:
> On 3/17/19 3:40 PM, David Rowley wrote:
> > On Thu, 14 Mar 2019 at 06:24, Robert Haas wrote:
> >
> > I think we can mark this patch as committed now as I don't think the
> > lack of a way to test it is likely to cause it to be reverted.
>
>
On Sun, Mar 24, 2019 at 9:02 PM Tatsuro Yamada
wrote:
> Please find attached files. :)
Committed. Thanks!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Perfect, thank you! I do remember seeing that message now, but hadn't
understood what it really meant.
I will test later today. Thanks
*Ryan*
On Sun, Mar 24, 2019 at 9:19 PM Tom Lane wrote:
> Chapman Flack writes:
> > On 03/24/19 21:04, Ryan Lambert wrote:
> >> I am unable to get latest
Hi,
On 2019-03-24 23:54:53 +1300, David Rowley wrote:
> This results in an Assert failure on master and an elog ERROR prior to
> c2fe139c201:
>
> create role test_role with login;
> create table ref(a int primary key);
> grant references on ref to test_role;
> set role test_role;
> create table
On Sun, Mar 24, 2019 at 02:06:59PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Thu, Mar 21, 2019 at 07:45:59PM -0300, Lucas Viecelli wrote:
> >> I am sending a patch that when an PUBLICATION is created and the
> >> wal_level is different from logical prints a WARNING in console/log:
>
>
Panagiotis Mavrogiorgos writes:
> Last November snowball added support for Greek language [1]. Following the
> instructions [2], I wrote a patch that adds fulltext search for Greek in
> Postgres. The patch is attached.
Cool!
> I would appreciate any feedback that will help in getting this
On 3/25/19 07:07, David Rowley wrote:
You had commented the test with:
-- If index conditions are different for each side, we won't select the same
-- row on both sides, so the join can't be removed.
but I don't quite understand why we can't remove the join in this
situation.
My rationale
On Thu, Mar 7, 2019 at 11:40 PM Ideriha, Takeshi
wrote:
> Just to be sure, we introduced the LRU list in this thread to find the
> entries less than threshold time
> without scanning the whole hash table. If hash table becomes large without
> LRU list, scanning time becomes slow.
Hmm. So,
On Sat, Mar 23, 2019 at 11:10 PM Amit Kapila
wrote:
> On Sat, Mar 23, 2019 at 9:50 AM Alvaro Herrera
> wrote:
> >
> > On 2019-Mar-23, Amit Kapila wrote:
> >
> > > I think some users might also be interested in the write transactions
> > > happened in the system, basically, those have consumed
>
> > Is a WARNING sufficient? Maybe I'm misunderstanding something
>
> important, but I think the attempt should fail with a HINT to set the
> > wal_level ahead of time.
>
I thought about this possibility, but I was afraid to change the current
behavior a lot, but it's worth discussing.
>
>
I
On 24/03/2019 18:50, Andrey Borodin wrote:
I was working on new version of gist check in amcheck and understand one more
thing:
/* Can this page be recycled yet? */
bool
gistPageRecyclable(Page page)
{
return PageIsNew(page) ||
(GistPageIsDeleted(page) &&
When reading another codepath, I happened to notice a few codepaths where we do
pg_malloc() immediately followed by a memset( .. 0, ..), without there being a
justification (that I can see) for not using pg_malloc0() instead. The attached
patch changes to pg_malloc0(), and passes make check.
On Thu, Mar 21, 2019 at 8:42 PM Michael Paquier wrote:
> > Why not?
>
> Because we have released v11 so as we respect the permissions set on
> the source instead from which the backup is taken for all the folder's
> content. If we begin to enforce it we may break some cases. If a new
> option
Hi
I did not review patch, just want add link to related bug 15580 and one another
-hackers thread:
https://www.postgresql.org/message-id/flat/15580-d1a6de5a3d65da51%40postgresql.org
Hello. This is a revised version.
At Wed, 20 Mar 2019 22:48:35 -0700, Noah Misch wrote in
<20190321054835.gb3842...@rfd.leadboat.com>
> On Wed, Mar 20, 2019 at 05:17:54PM +0900, Kyotaro HORIGUCHI wrote:
> > At Sun, 10 Mar 2019 19:27:08 -0700, Noah Misch wrote in
> >
Hi all,
When I do the following:
postgres=# create table t1 (a int);
postgres=# insert into t1 values(1);
postgres=# create unique index uniq_idx on t1(a);
postgres=# alter table t1 add column b float8 not null default random(), add
primary key using index uniq_idx;
ERROR: column "b" contains
On 25.03.2019 13:48, Dmitry Dolgov wrote:
On Mon, Mar 25, 2019 at 11:39 AM David Steele wrote:
On 3/25/19 1:04 PM, Konstantin Knizhnik wrote:
On 25.03.2019 11:06, David Steele wrote:
Konstantin,
This patch appears to be failing tests so I have marked it Waiting on
Author.
I have also
On Mon, 25 Mar 2019 at 23:44, Peter Eisentraut
wrote:
> I did a bit of performance testing, both a plain pgbench and the
> suggested test case with 4096 partitions. I can't detect any
> performance improvements. In fact, within the noise, it tends to be
> just a bit on the slower side.
>
> So
>> Shoudn't you add this to commitfest ?
> I added it last week, see https://commitfest.postgresql.org/23/2069/
Oups, sorry for the noise
>> Would it make sense to add it in auto explain ?
>> I don't know for explain itself, but maybe ...
> I'd think that people interested in getting the queryid in the logs
> would configure the log_line_prefix to display it consistently rather
> than having it in only a subset of cases, so that's
On Mon, Mar 25, 2019 at 12:36 PM legrand legrand
wrote:
>
> >> Would it make sense to add it in auto explain ?
> >> I don't know for explain itself, but maybe ...
>
> > I'd think that people interested in getting the queryid in the logs
> > would configure the log_line_prefix to display it
On 2019-03-23 03:30, Alvaro Herrera wrote:
>>> Thanks for the updated patch. I applied it and rebased the
>>> foreign-keys-referencing-partitioned-tables patch on top. Here's
>>> something I think you may have missed:
>>
>> I missed that indeed! Thanks for noticing. Here's an updated and
>>
On Mon, Mar 25, 2019 at 5:01 PM Thomas Munro wrote:
> New version attached. I'd like to commit this for PG12.
Here is a follow-up sketch patch that shows FullTransactionId being
used in the transaction stack, so you can call eg
GetCurrentFullTransactionId(). A table access method could use
1 - 100 of 129 matches
Mail list logo
