Hi, Thomas
>-Original Message-
>From: Thomas Munro [mailto:thomas.mu...@gmail.com]
>Subject: Re: Copy data to DSA area
>
>On Wed, May 8, 2019 at 5:29 PM Ideriha, Takeshi
>
>wrote:
>> >From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com]
>> >Sent: Friday, April 26, 2019 11:50 PM
In commit d50d172e51, which adds support for FINAL relation pushdown
in postgres_fdw, I forgot to update the FDW documentation about
GetForeignUpperPaths to mention that the extra parameter of that
function points to a FinalPathExtraData structure introduced by that
commit in the case of FINAL rela
Hello hackers,
On another thread, lots of undo log-related patches have been traded.
Buried deep in the stack is one that I'd like to highlight and discuss
in a separate thread, because it relates to a parallel thread of
development and it'd be good to get feedback on it.
In commit 3eb77eba, Shaw
On Mon, May 6, 2019 at 1:39 PM Ashwin Agrawal wrote:
>
> Also wish to point out, while working on Zedstore, we realized that
> TupleDesc from Relation object can be trusted at AM layer for
> scan_begin() API. As for ALTER TABLE rewrite case (ATRewriteTables()),
> catalog is updated first and hence
On Wed, May 8, 2019 at 5:29 PM Ideriha, Takeshi
wrote:
> >From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com]
> >Sent: Friday, April 26, 2019 11:50 PM
> >Well, after developing PoC, I realized that this PoC doesn't solve the local
> >process is
> >crashed before the context becomes sha
Hi,
>From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com]
>Sent: Friday, April 26, 2019 11:50 PM
>Well, after developing PoC, I realized that this PoC doesn't solve the local
>process is
>crashed before the context becomes shared because local process keeps track of
>pointer to chunks.
On Wed, May 8, 2019 at 3:53 PM Tom Lane wrote:
> Thomas Munro writes:
> > Reproduced here. Once the system reaches a state where it's leaking
> > (which happens only occasionally for me during installcheck-parallel),
> > it keeps leaking for future SSI transactions. The cause is
> > SxactGlobal
At Wed, 08 May 2019 13:06:36 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190508.130636.184826233.horiguchi.kyot...@lab.ntt.co.jp>
> At Tue, 07 May 2019 20:47:28 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20190507.204728.233299873.horiguchi.kyot...@lab.ntt.co.j
At Tue, 07 May 2019 20:47:28 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190507.204728.233299873.horiguchi.kyot...@lab.ntt.co.jp>
> Hello.
>
> At Tue, 7 May 2019 14:39:55 +0530, Rajkumar Raghuwanshi
> wrote in
>
> > Hi,
> > As this issue is reproducible without partition-wise
Thomas Munro writes:
> Reproduced here. Once the system reaches a state where it's leaking
> (which happens only occasionally for me during installcheck-parallel),
> it keeps leaking for future SSI transactions. The cause is
> SxactGlobalXmin getting stuck. The attached fixes it for me. I can'
(2019/02/25 19:59), Etsuro Fujita wrote:
(2019/02/22 23:10), Antonin Houska wrote:
Etsuro Fujita wrote:
As mentioned in the near thread, I think there is another oversight in
the cost estimation for aggregate pushdown paths in postgres_fdw, IIUC.
When costing an aggregate pushdown path using lo
On Wed, May 8, 2019 at 6:56 AM Thomas Munro wrote:
> On Wed, May 8, 2019 at 5:46 AM Tom Lane wrote:
> > I'd have to say that my first suspicion falls on bb16aba50 ...
>
> Investigating.
Reproduced here. Once the system reaches a state where it's leaking
(which happens only occasionally for me d
On Mon, May 6, 2019 at 4:11 PM Peter Geoghegan wrote:
> I am tempted to move the call to _bt_truncate() out of _bt_split()
> entirely on HEAD, possibly relocating it to
> nbtsplitloc.c/_bt_findsplitloc(). That way, there is a clearer
> separation between how split points are chosen, suffix truncat
On Tue, May 7, 2019 at 6:59 AM Tomas Vondra
wrote:
> On Tue, May 07, 2019 at 04:28:36PM +1200, Thomas Munro wrote:
> >On Tue, May 7, 2019 at 3:15 PM Tomas Vondra
> > wrote:
> >> On Tue, May 07, 2019 at 01:48:40PM +1200, Thomas Munro wrote:
> >> Switching to some other algorithm during execution m
On Wed, May 8, 2019 at 2:41 AM Fujii Masao wrote:
>
> Hi,
>
> vacuumdb command supports the corresponding options to
> any VACUUM parameters except INDEX_CLEANUP and TRUNCATE
> that were added recently. Should vacuumdb also support those
> new parameters, i.e., add --index-cleanup and --truncate o
On Mon, May 6, 2019 at 8:15 PM Tomas Vondra
wrote:
> Nope, that's not how it works. It's the array of batches that gets
> sliced, not the batches themselves.
>
> It does slightly increase the amount of data we need to shuffle between
> the temp files, because we can't write the data directly to b
Donald Dong writes:
> I was expecting the plans generated by standard_join_search to have lower
> costs
> than the plans from GEQO. But after the results I have from a join order
> benchmark show that GEQO produces plans with lower costs most of the time!
> I wonder what is causing this observat
On Tue, May 07, 2019 at 06:45:36PM -0400, Tom Lane wrote:
> Yeah. CREATE INDEX CONCURRENTLY has always had a deadlock hazard,
> so it's hardly surprising that REINDEX CONCURRENTLY does too.
> I don't think that fixing that is in-scope for v12, even if we had
> an idea how to do it, which we don't.
Hi,
I was expecting the plans generated by standard_join_search to have lower costs
than the plans from GEQO. But after the results I have from a join order
benchmark show that GEQO produces plans with lower costs most of the time!
I wonder what is causing this observation? From my understanding,
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm generally in favor of doing something like what Tom is suggesting
> > with VERBOSE, but I also feel like it should be the default for formats
> > like JSON. If you're asking for the output in JSON, then we really
>
Greetings,
* David Fetter (da...@fetter.org) wrote:
> On Tue, May 07, 2019 at 06:12:56PM -0400, Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > One idea that comes to mind is that VERBOSE could be redefined as
> > > some sort of package of primitive options, including all of
Andres Freund writes:
> On 2019-05-07 12:25:43 +0900, Michael Paquier wrote:
>> Then session 2 deadlocks while session 3 finishes correctly. I don't
>> know if this is a class of problems we'd want to address for v12, but
>> if we do then CIC (and DROP INDEX CONCURRENTLY?) could benefit from
>> i
On Tue, May 07, 2019 at 06:12:56PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >
> > One idea that comes to mind is that VERBOSE could be redefined as
> > some sort of package of primitive options, including all of the
> > "additional information" options
On 02/05/2019 10:37, Heikki Linnakangas wrote:
(resending, previous attempt didn't make it to pgsql-hackers)
On 29/04/2019 16:16, Anastasia Lubennikova wrote:
In previous emails, I have sent two patches with test and bugfix (see
attached).
After Heikki shared his concerns, I've rechecked the al
Stephen Frost writes:
> I'm generally in favor of doing something like what Tom is suggesting
> with VERBOSE, but I also feel like it should be the default for formats
> like JSON. If you're asking for the output in JSON, then we really
> should include everything that a flag like VERBOSE would c
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andres Freund writes:
> > As I said, I don't think ALL is a good idea under any name. Like it
> > just makes no sense to have ANALYZE, SUMMARY, VERBOSE, BUFFERS,
> > SETTINGS, FORMAT controlled by one option, unless you call it DWIM. It's
> > s
Andres Freund writes:
> As I said, I don't think ALL is a good idea under any name. Like it
> just makes no sense to have ANALYZE, SUMMARY, VERBOSE, BUFFERS,
> SETTINGS, FORMAT controlled by one option, unless you call it DWIM. It's
> several separate axis (query is executed or not (ANALYZE), ver
On Tue, May 7, 2019 at 5:35 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Attached patchset contains revised commit messages. I'm going to
> > commit this on no objections.
>
> Sorry for slow response --- I was tied up with release preparations.
>
> The -5 patches look pretty good. A coup
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Having our test framework deny us useful features just strikes me as
> > bizarre.
>
> This is presuming that it's useful, which is debatable IMO.
> I think most people will find it useless noise almost all of the time.
Hi,
On 2019-05-07 23:23:55 +0200, David Fetter wrote:
> Would you agree that there's a problem here as I described as
> motivation for people who operate databases?
Yea, but I don't think the solution is where you seek it. I think the
problem is that our defaults for EXPLAIN, in particular EXPLA
Stephen Frost writes:
> Having our test framework deny us useful features just strikes me as
> bizarre.
This is presuming that it's useful, which is debatable IMO.
I think most people will find it useless noise almost all of the time.
regards, tom lane
On Tue, May 7, 2019 at 9:31 AM David Fetter wrote:
> If you're tuning a query interactively, it's a lot simpler to prepend,
> for example,
>
> EXPLAIN (ALL, FORMAT JSON)
>
> to it than to prepend something along the lines of
>
> EXPLAIN(ANALYZE, VERBOSE, COSTS, BUFFERS, SETTINGS, TIMING, S
I wrote:
> is_publishable_class has a test "relid >= FirstNormalObjectId",
> which I think we should drop, for two reasons:
> 1. It makes the comment claiming that this function tests the same
> things as check_publication_add_relation a lie.
> 2. The comment about it claims that the purpose is t
On Tue, May 07, 2019 at 09:44:30AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-07 18:34:11 +0200, David Fetter wrote:
> > On Tue, May 07, 2019 at 08:41:47AM -0700, Andres Freund wrote:
> > > On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> > > > It can get a little tedious turning on (or o
I wrote:
> After looking around a bit, I propose that we invent
> "IsCatalogRelationOid(Oid reloid)" (not wedded to that name), which
> is a wrapper around IsCatalogClass() that does the needful syscache
> lookup for you. Aside from this use-case, it could be used in
> sepgsql/dml.c, which I see i
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, May 7, 2019 at 11:30 AM Stephen Frost wrote:
> > > Not unless you want to break every regression test that uses \d.
> > > Instability of the output is also a reason not to show the
> > > toast table's name in the parent's \d[+].
>
On Mon, May 6, 2019 at 1:56 PM Bruce Momjian wrote:
> Is there a reason pg_checksums is plural and not singular, i.e.,
> pg_checksum? I know it is being renamed for PG 12. It might have
> needed to be plural when it was pg_verify_checksums.
That is a good question, IMHO. I am not sure whether
On Tue, May 7, 2019 at 11:30 AM Stephen Frost wrote:
> > Not unless you want to break every regression test that uses \d.
> > Instability of the output is also a reason not to show the
> > toast table's name in the parent's \d[+].
>
> So we need a way to turn it off. That doesn't seem like it'd b
Hi,
On 2016-04-06 12:57:16 +0200, Andres Freund wrote:
> While benchmarking on hydra
> (c.f.
> http://archives.postgresql.org/message-id/20160406104352.5bn3ehkcsceja65c%40alap3.anarazel.de),
> which has quite slow IO, I was once more annoyed by how incredibly long
> the vacuum at the the end of a
Andrew Dunstan writes:
> On 5/7/19 1:46 PM, Tom Lane wrote:
>> After running the core regression tests with installcheck-parallel,
>> the pg_locks view sometimes shows me apparently-orphaned SIReadLock
>> entries. They accumulate over repeated test runs.
> Should we have a test for that run at
On 5/7/19 1:46 PM, Tom Lane wrote:
> After running the core regression tests with installcheck-parallel,
> the pg_locks view sometimes shows me apparently-orphaned SIReadLock
> entries. They accumulate over repeated test runs.
Should we have a test for that run at/near the end of the regress
On Tue, May 07, 2019 at 09:46:07AM -0400, Tom Lane wrote:
Ian Barwick writes:
Commit cc8d4151 [*] introduced a dependency between some functions in
libpgcommon and libpgfeutils,
This seems rather seriously broken. I do not think the answer is to
create a global dependency on libpgfeutils.
is_publishable_class has a test "relid >= FirstNormalObjectId",
which I think we should drop, for two reasons:
1. It makes the comment claiming that this function tests the same
things as check_publication_add_relation a lie.
2. The comment about it claims that the purpose is to reject
informatio
On Wed, May 8, 2019 at 5:46 AM Tom Lane wrote:
> After running the core regression tests with installcheck-parallel,
> the pg_locks view sometimes shows me apparently-orphaned SIReadLock
> entries. [...]
Ugh.
> I'd have to say that my first suspicion falls on bb16aba50 ...
Investigating.
--
T
After running the core regression tests with installcheck-parallel,
the pg_locks view sometimes shows me apparently-orphaned SIReadLock
entries. They accumulate over repeated test runs. Right now,
for example, I see
regression=# select * from pg_locks;
locktype | database | relation | page |
Hi,
vacuumdb command supports the corresponding options to
any VACUUM parameters except INDEX_CLEANUP and TRUNCATE
that were added recently. Should vacuumdb also support those
new parameters, i.e., add --index-cleanup and --truncate options
to the command?
Regards,
--
Fujii Masao
On Tue, May 07, 2019 at 06:47:59PM +0200, David Fetter wrote:
> On Tue, May 07, 2019 at 09:39:57AM -0400, Andrew Dunstan wrote:
> >
> > On 5/6/19 10:42 PM, David Fetter wrote:
> > > On Tue, May 07, 2019 at 11:05:32AM +0900, Kyotaro HORIGUCHI wrote:
> > >> Hi.
> > >>
> > >> At Sun, 28 Apr 2019 17:0
On Mon, Apr 8, 2019 at 8:15 PM Julien Rouhaud wrote:
>
> On Mon, Apr 8, 2019 at 12:22 PM Fujii Masao wrote:
> >
> > On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote:
> > > >
> > > > On Mon, Apr 8, 2019 at 3:58 PM Julien Rouh
On Tue, May 7, 2019 at 5:33 PM Masahiko Sawada wrote:
>
> On Mon, Apr 8, 2019 at 7:29 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 8, 2019 at 7:22 PM Fujii Masao wrote:
> > >
> > > On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Mon, Apr 8, 2019 at 5:15 PM Fujii
On Tue, May 7, 2019 at 12:27 AM Heikki Linnakangas wrote:
> I don't understand that reasoning. Yes, _bt_pagedel() will complain if
> it finds a half-dead internal page. But how does that mean that
> _bt_lock_branch_parent() can't encounter one?
I suppose that in theory it could, but only if you a
On Tue, May 07, 2019 at 09:39:57AM -0400, Andrew Dunstan wrote:
>
> On 5/6/19 10:42 PM, David Fetter wrote:
> > On Tue, May 07, 2019 at 11:05:32AM +0900, Kyotaro HORIGUCHI wrote:
> >> Hi.
> >>
> >> At Sun, 28 Apr 2019 17:07:16 +0200, David Fetter wrote
> >> in <20190428150716.gp28...@fetter.org>
Hi,
On 2019-05-07 18:34:11 +0200, David Fetter wrote:
> On Tue, May 07, 2019 at 08:41:47AM -0700, Andres Freund wrote:
> > On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> > > It can get a little tedious turning on (or off) all the boolean
> > > options to EXPLAIN, so please find attached a sho
On Tue, May 07, 2019 at 08:41:47AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> > It can get a little tedious turning on (or off) all the boolean
> > options to EXPLAIN, so please find attached a shortcut.
>
> I'm not convinced this is a good idea - it
On Tue, May 07, 2019 at 11:03:23AM +0200, Rafia Sabih wrote:
> On Tue, 7 May 2019 at 09:30, David Fetter wrote:
> >
> > Folks,
> >
> > It can get a little tedious turning on (or off) all the boolean
> > options to EXPLAIN, so please find attached a shortcut.
>
> I don't understand this, do you mi
On Tue, May 07, 2019 at 11:13:15AM +0300, Sergei Kornilov wrote:
> Hi
>
> I liked this idea.
>
> + timing_set = true;
> + es->timing = defGetBoolean(opt);
> + summary_set = true;
> + es->timing = defGetBoolean(opt);
>
On Tue, May 7, 2019 at 2:39 PM Daniel Gustafsson wrote:
> Spotted two minor typos when skimming through code, and a sentence on
> returnvalue which seemed a bit odd since executeJsonPath() can exit on
> ereport(). The attached diff fixes the typos and suggests a new wording.
>
Pushed. Thanks!
Hi,
On 2019-05-07 12:12:37 -0400, Tom Lane wrote:
> Why do you think there's no limit? We ordinarily do
> RelationGetNumberOfBlocks at least once per query on a table
Well, for the main fork. Which already could have shrunk below the size
that led the FSM to be created. And we only do
RelationGe
Hi,
On 2019-05-07 12:14:43 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-05-07 12:07:37 -0400, Tom Lane wrote:
> >> The number of deadlock failures is kind of annoying, so I'd rather remove
> >> the tests from HEAD sooner than later. What issues around that do you
> >> think remain
Andres Freund writes:
> On 2019-05-07 12:07:37 -0400, Tom Lane wrote:
>> The number of deadlock failures is kind of annoying, so I'd rather remove
>> the tests from HEAD sooner than later. What issues around that do you
>> think remain that these tests would be helpful for?
> I was wondering abo
Andres Freund writes:
> On 2019-05-07 12:04:11 -0400, Tom Lane wrote:
>> I do not think sinval messaging is going to be sufficient to avoid that
>> problem. sinval is only useful to tell you about changes if you first
>> take a lock strong enough to guarantee that no interesting change is
>> happ
Hi,
On 2019-05-07 12:07:37 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Yea, that might be right. I'm planning to leave the tests in until a
> > bunch of the open REINDEX issues are resolved. Not super likely that
> > it'd break something, but probably worth anyway?
>
> The number of deadl
Andres Freund writes:
> Yea, that might be right. I'm planning to leave the tests in until a
> bunch of the open REINDEX issues are resolved. Not super likely that
> it'd break something, but probably worth anyway?
The number of deadlock failures is kind of annoying, so I'd rather remove
the test
Hi,
On 2019-05-07 12:04:11 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-05-07 09:34:42 -0400, Tom Lane wrote:
> >> I'm inclined to wonder why bother with invals at all.
>
> > But when updating the free space for the first four blocks, we're going
> > to either have to do an smgrexi
Hi,
On 2019-05-07 12:25:43 +0900, Michael Paquier wrote:
> On Tue, May 07, 2019 at 12:07:56PM +0900, Michael Paquier wrote:
> > Now, what do we do about the potential deadlock issues in
> > WaitForOlderSnapshots? The attached is an isolation test able to
> > reproduce the deadlock within WaitForO
Andres Freund writes:
> On 2019-05-07 09:34:42 -0400, Tom Lane wrote:
>> I'm inclined to wonder why bother with invals at all.
> But when updating the free space for the first four blocks, we're going
> to either have to do an smgrexists() to check whether somebody
> concurrently created the FSM,
Hi,
On 2019-05-07 10:50:19 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I for sure thought I earlier had an idea that'd actually work. But
> > either I've lost it, or it didn't actually work. But perhaps somebody
> > else can come up with something based on the above strawman ideas?
>
> Bo
Hi,
On 2019-05-07 09:34:42 -0400, Tom Lane wrote:
> I'm inclined to wonder why bother with invals at all. The odds are
> quite good that no other backend will care (which, I imagine, is the
> reasoning behind why the original patch was designed like it was).
> A table that has a lot of concurrent
Hi,
On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> It can get a little tedious turning on (or off) all the boolean
> options to EXPLAIN, so please find attached a shortcut.
I'm not convinced this is a good idea - it seems likely that we'll add
conflicting options at some point, and then this
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Rafia Sabih writes:
> >>> IMHO, what makes more sense is to show the name of associated toast
> >>> table in the \dt+ of the normal table.
>
> >> I'm not for that: it's usel
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Rafia Sabih writes:
>>> IMHO, what makes more sense is to show the name of associated toast
>>> table in the \dt+ of the normal table.
>> I'm not for that: it's useless information in at least 99.44% of cases.
> I don't think I'd
On Tue, May 07, 2019 at 10:42:36AM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Mon, May 06, 2019 at 11:18:28PM -0400, Tom Lane wrote:
Tomas Vondra writes:
Do we actually check how many duplicates are there during planning?
Certainly that's part of the planner's cost estimates ... but i
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Rafia Sabih writes:
> > On Fri, 3 May 2019 at 16:27, Justin Pryzby wrote:
> >> Thanks - what about also showing the associated non-toast table ?
>
> > IMHO, what makes more sense is to show the name of associated toast
> > table in the \dt+ of
Andres Freund writes:
> I for sure thought I earlier had an idea that'd actually work. But
> either I've lost it, or it didn't actually work. But perhaps somebody
> else can come up with something based on the above strawman ideas?
Both of those ideas fail if an autovacuum starts up after you're
Tomas Vondra writes:
> On Mon, May 06, 2019 at 11:18:28PM -0400, Tom Lane wrote:
>> Tomas Vondra writes:
>>> Do we actually check how many duplicates are there during planning?
>> Certainly that's part of the planner's cost estimates ... but it's
>> only as good as the planner's statistical know
Alexander Korotkov writes:
> Attached patchset contains revised commit messages. I'm going to
> commit this on no objections.
Sorry for slow response --- I was tied up with release preparations.
The -5 patches look pretty good. A couple of nits:
@@ -774,9 +749,7 @@ executeItemOptUnwrapTarget(
On Tue, May 07, 2019 at 04:28:36PM +1200, Thomas Munro wrote:
On Tue, May 7, 2019 at 3:15 PM Tomas Vondra
wrote:
On Tue, May 07, 2019 at 01:48:40PM +1200, Thomas Munro wrote:
>Seems expensive for large numbers of slices -- you need to join the
>outer batch against each inner slice.
Nope, that'
Ian Barwick writes:
> Commit cc8d4151 [*] introduced a dependency between some functions in
> libpgcommon and libpgfeutils,
This seems rather seriously broken. I do not think the answer is to
create a global dependency on libpgfeutils.
regards, tom lane
Amit Kapila writes:
> On Mon, May 6, 2019 at 8:57 PM Andres Freund wrote:
>> On 2019-05-06 11:10:15 -0400, Robert Haas wrote:
>>> I think it's legitimate to question whether sending additional
>>> invalidation messages as part of the design of this feature is a good
>>> idea.
>> I don't think it
On 5/6/19 10:42 PM, David Fetter wrote:
> On Tue, May 07, 2019 at 11:05:32AM +0900, Kyotaro HORIGUCHI wrote:
>> Hi.
>>
>> At Sun, 28 Apr 2019 17:07:16 +0200, David Fetter wrote in
>> <20190428150716.gp28...@fetter.org>
>>> Our test coverage needs all the help it can get.
>>>
>>> This patch, ext
On Mon, May 06, 2019 at 11:18:28PM -0400, Tom Lane wrote:
Tomas Vondra writes:
Do we actually check how many duplicates are there during planning?
Certainly that's part of the planner's cost estimates ... but it's
only as good as the planner's statistical knowledge.
I'm looking at the code
Hi Meskes-san
There are two points.
(1)
I attach a new patch. Please review it.
- Preproc replaces any prepared_name to "$0" and changes it to an
input-variable
for PREARE with typelist and EXECUTE with paramlist.
$0 is replaced in ecpg_build_params().
It's enable not to change EC
Spotted two minor typos when skimming through code, and a sentence on
returnvalue which seemed a bit odd since executeJsonPath() can exit on
ereport(). The attached diff fixes the typos and suggests a new wording.
cheers ./daniel
typo-jsonpath_exec.diff
Description: Binary data
Hello.
At Tue, 7 May 2019 14:39:55 +0530, Rajkumar Raghuwanshi
wrote in
> Hi,
> As this issue is reproducible without partition-wise aggregate also,
> changing email subject from "Statistical aggregate functions are not
> working with partitionwise aggregate " to "Statistical aggregate functio
Hi,
As this issue is reproducible without partition-wise aggregate also,
changing email subject from "Statistical aggregate functions are not
working with partitionwise aggregate " to "Statistical aggregate functions
are not working with PARTIAL aggregation".
original reported test case and discus
On Tue, 7 May 2019 at 09:30, David Fetter wrote:
>
> Folks,
>
> It can get a little tedious turning on (or off) all the boolean
> options to EXPLAIN, so please find attached a shortcut.
>
I don't understand this, do you mind explaining a bit may be with an
example on how you want it to work.
--
On 2019/04/26 23:12, Alvaro Herrera wrote:
> On 2019-Apr-25, Amit Langote wrote:
>
>> BTW, this will need to be back-patched to 11.
>
> Done, thanks for the patch. I added the test in master, but obviously
> it doesn't work in pg11, so I just verified manually that relispartition
> is set correc
On Mon, Apr 8, 2019 at 7:29 PM Masahiko Sawada wrote:
>
> On Mon, Apr 8, 2019 at 7:22 PM Fujii Masao wrote:
> >
> > On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote:
> > > >
> > > > On Mon, Apr 8, 2019 at 3:58 PM Julien Rouh
Hi
I liked this idea.
+ timing_set = true;
+ es->timing = defGetBoolean(opt);
+ summary_set = true;
+ es->timing = defGetBoolean(opt);
second es->timing should be es->summary, right?
regards, Sergei
On Tue, May 7, 2019 at 4:00 PM Michael Paquier wrote:
>
> On Tue, May 07, 2019 at 03:41:50PM +0800, John Naylor wrote:
> > Attached is an attempt to match surrounding code. More broadly,
> > though, it seems the "ID info" comments belong with the SET_LOCKTAG_*
> > macros rather than with the LockT
On 2019/04/27 3:57, Tom Lane wrote:
> Alvaro Herrera writes:
>> Um, this one doesn't apply because of yesterday's 87259588d0ab.
>
> Before we spend too much time on minutiae, we should ask ourselves whether
> this patch is even going in the right direction. I'm not sure.
>
> One point is that i
On Fri, May 3, 2019 at 12:09 AM Robert Haas wrote:
>
> On Tue, Apr 16, 2019 at 4:00 PM Tom Lane wrote:
> > I wrote:
> > > I'm thinking that we really need to upgrade vacuum's reporting totals
> > > so that it accounts in some more-honest way for pre-existing dead
> > > line pointers. The patch a
On Tue, May 07, 2019 at 03:41:50PM +0800, John Naylor wrote:
> Attached is an attempt to match surrounding code. More broadly,
> though, it seems the "ID info" comments belong with the SET_LOCKTAG_*
> macros rather than with the LockTagType enum members.
+ LOCKTAG_SPECULATIVE_TOKEN, /* for spec
On Sun, May 05, 2019 at 05:45:53PM -0400, Tom Lane wrote:
> In the other place, checking IsSystemNamespace isn't even
> approximately the correct way to proceed, since it fails to reject
> reindexing system catalogs' toast tables.
Good point. I overlooked that part. It is easy enough to have a t
On Tue, May 07, 2019 at 09:30:47AM +0200, David Fetter wrote:
> Folks,
>
> It can get a little tedious turning on (or off) all the boolean
> options to EXPLAIN, so please find attached a shortcut.
>
> Best,
> David.
It helps to have a working patch for this.
Best,
David.
--
David Fetter http:
On Mon, 6 May 2019 at 22:39, Ashwin Agrawal wrote:
>
> On Mon, May 6, 2019 at 7:14 AM Andres Freund wrote:
> >
> > Hi,
> >
> > On May 6, 2019 3:40:55 AM PDT, Rafia Sabih
> > wrote:
> > >I was trying the toyam patch and on make check it failed with
> > >segmentation fault at
> > >
> > >static vo
On Mon, 6 May 2019 at 16:14, Andres Freund wrote:
>
> Hi,
>
> On May 6, 2019 3:40:55 AM PDT, Rafia Sabih wrote:
> >On Tue, 9 Apr 2019 at 15:17, Heikki Linnakangas
> >wrote:
> >>
> >> On 08/04/2019 20:37, Andres Freund wrote:
> >> > On 2019-04-08 15:34:46 +0300, Heikki Linnakangas wrote:
> >> >>
Attached is an attempt to match surrounding code. More broadly,
though, it seems the "ID info" comments belong with the SET_LOCKTAG_*
macros rather than with the LockTagType enum members.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
Folks,
It can get a little tedious turning on (or off) all the boolean
options to EXPLAIN, so please find attached a shortcut.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
>From 8d
On 05/05/2019 01:38, Peter Geoghegan wrote:
On Fri, Mar 1, 2019 at 3:59 PM Peter Geoghegan wrote:
/*
* Perform the same check on this internal level that
* _bt_mark_page_halfdead performed on the leaf level.
*/
if (_bt_is_page_
On 2019/04/27 0:02, Tom Lane wrote:
> Amit Langote writes:
>> I couldn't find old discussions or source code comments about this, but
>> has someone encountered the following error and wondered whether it's
>> working that way for a reason?
>
>> select a::text, b from foo order by 1, 2 collate "C
100 matches
Mail list logo
