On Tue, Mar 24, 2020 at 11:05 AM Thomas Munro
wrote:
> On Tue, Mar 24, 2020 at 9:55 AM Thomas Munro
> wrote:
> > On Tue, Mar 24, 2020 at 6:01 AM Tom Lane wrote:
> > > Alvaro Herrera writes:
> > > > While messing with EXPLAIN on a query emitted by pg_dump, I noticed
> that
> > > > current Postg
On 20.03.2020 03:34, Peter Geoghegan wrote:
On Thu, Mar 19, 2020 at 9:34 AM Anastasia Lubennikova
wrote:
During tests, we catched an assertion failure in _bt_killitems() for
posting tuple in unique index:
/* kitem must have matching offnum when heap TIDs match */
Assert(kitem->indexOffset == o
On 2020/03/05 20:16, Fujii Masao wrote:
On 2020/03/05 16:58, Masahiko Sawada wrote:
On Wed, 4 Mar 2020 at 15:21, Fujii Masao wrote:
On 2020/03/04 14:31, Masahiko Sawada wrote:
On Wed, 4 Mar 2020 at 13:48, Fujii Masao wrote:
On 2020/03/04 13:27, Michael Paquier wrote:
On Wed, Mar
On Tue, 24 Mar 2020 at 13:53, Amit Kapila wrote:
>
> On Tue, Mar 24, 2020 at 9:46 AM Justin Pryzby wrote:
> >
> > On Mon, Mar 23, 2020 at 02:25:14PM +0530, Amit Kapila wrote:
> > > > Yea, and it would be misleading if we reported "while scanning block..of
> > > > relation" if we actually failed w
Thanks for working on this.
At Mon, 23 Mar 2020 20:56:59 +, Teja Mupparti wrote
in
> This is my *first* attempt to submit a Postgres patch, please let me know if
> I missed any process or format of the patch
Welcome! The format looks fine to me. It would be better if it had a
commit mess
On Tue, Mar 24, 2020 at 2:37 PM Masahiko Sawada
wrote:
>
> On Tue, 24 Mar 2020 at 13:53, Amit Kapila wrote:
> >
> > On Tue, Mar 24, 2020 at 9:46 AM Justin Pryzby wrote:
> > >
> > > On Mon, Mar 23, 2020 at 02:25:14PM +0530, Amit Kapila wrote:
> > > > > Yea, and it would be misleading if we report
On 2020-03-23 17:26, Daniel Verite wrote:
Peter Eisentraut wrote:
What is that status of this patch set? I think we have nailed down the
behavior, but there were some concerns about certain performance
characteristics. Do people feel that those are required to be addressed
in this cyc
5d0c2d5eba shot out this.
Rebased.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 6837855f0c938b5e34039897158bc912c6619d2b Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Thu, 5 Sep 2019 20:21:55 +0900
Subject: [PATCH v7 1/4] Move callback-call from ReadPageInternal
Hi
rebase
Regards
Pavel
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 402c4b1b26..429e0d5708 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -2199,6 +2199,16 @@ CREATE INDEX
+
+\gf format [
On Sun, Mar 15, 2020 at 2:26 PM I wrote:
>
> To get more logical behavior, perhaps the optional parameter is better
> as an offset instead of an origin. Alternatively (or additionally),
> the function could do the math on int64 timestamps directly.
For v6, I changed the algorithm to use pg_tm for
On 2020-03-02 14:22, Peter Eisentraut wrote:
Starting with Python 3.9, the Python headers contain inline functions
that fall afoul of our -Wdeclaration-after-statement coding style. In
order to silence those warnings, I've added some GCC-specific
contortions to disable that warning for Python.h
On Wed, Feb 12, 2020 at 6:50 AM Melanie Plageman
wrote:
>
>
> On Tue, Feb 11, 2020 at 4:45 PM Andres Freund wrote:
>>
>>
>> I additionally restricted the controller_print_speculative_locks step to
>> the current database and made a bunch of debug output more
>> precise. Survived ~150 runs locally
On Sun, Jan 12, 2020 at 3:33 AM Alexander Korotkov
wrote:
>
> On Wed, Jan 8, 2020 at 4:37 PM Tom Lane wrote:
> > Heikki Linnakangas writes:
> > > On 01/11/2019 01:50, Alexander Korotkov wrote:
> > >> This happens so, because we're checking that there is no broken HOT
> > >> chains after index cr
On Mon, Mar 9, 2020 at 11:07 PM Andres Freund wrote:
>
> On 2020-03-07 11:15:27 +0530, Dilip Kumar wrote:
> > IMHO, if we conclude that because there is no performance gain so we
> > don't want to add one extra path in the code then we might want to
> > remove that TODO from the code so that we do
On Tue, 24 Mar 2020 at 18:19, Amit Kapila wrote:
>
> On Tue, Mar 24, 2020 at 2:37 PM Masahiko Sawada
> wrote:
> >
> > On Tue, 24 Mar 2020 at 13:53, Amit Kapila wrote:
> > >
> > > On Tue, Mar 24, 2020 at 9:46 AM Justin Pryzby
> > > wrote:
> > > >
> > > > On Mon, Mar 23, 2020 at 02:25:14PM +0530
On Tue, Mar 24, 2020 at 6:16 PM Amit Kapila wrote:
>
> On Mon, Mar 9, 2020 at 11:07 PM Andres Freund wrote:
> >
> > On 2020-03-07 11:15:27 +0530, Dilip Kumar wrote:
> > > IMHO, if we conclude that because there is no performance gain so we
> > > don't want to add one extra path in the code then w
On Tue, 24 Mar 2020 at 01:08, Tomas Vondra wrote:
>
> Hmmm. So let's consider a simple OR clause with two arguments, both
> covered by single statistics object. Something like this:
>
>CREATE TABLE t (a int, b int);
>INSERT INTO t SELECT mod(i, 10), mod(i, 10)
> FROM generate_series(1
Hi Konstantin,
On 11/14/19 2:06 AM, Konstantin Knizhnik wrote:
Attached please find rebased patch with this bug fixed.
This patch no longer applies: http://cfbot.cputube.org/patch_27_2067.log
CF entry has been updated to Waiting on Author.
Regards,
--
-David
da...@pgmasters.net
Hello John,
this looks like a nice feature. I'm wondering how it relates to the
following use-case:
When drawing charts, the user can select pre-defined widths on times
(like "15 min", "1 hour").
The data for these slots is fitted always to intervalls that start in 0
in the slot, e.g. if t
Hi Wenjing,
Please check my findings(on gtt_v20.patch) as below:
*TestCase1:* (cache lookup failed on GTT)
-- Session1:
postgres=# create global temporary table gtt1(c1 int) on commit delete rows;
CREATE TABLE
-- Session2:
postgres=# drop table gtt1 ;
DROP TABLE
-- Session1:
postgres=# create g
On Tue, Mar 24, 2020 at 6:18 PM Masahiko Sawada
wrote:
>
>
> I've read through the latest version patch (v31), here are my comments:
>
> 1.
> +/* Update error traceback information */
> +olderrcbarg = *vacrelstats;
> +update_vacuum_error_cbarg(vacrelstats,
> +
Hello,
I build the pdf (for HEAD) almost daily without problems, but at the
moment I get the error below.
I am not sure whether to blame my particular setup (debian stretch), or
whether there might be an error in the .sgml. The html files still
build OK.
If anyone has a suggestion on how
On Tue, Mar 24, 2020 at 07:07:03PM +0530, Amit Kapila wrote:
> On Tue, Mar 24, 2020 at 6:18 PM Masahiko Sawada
> wrote:
> > 1.
> > +/* Update error traceback information */
> > +olderrcbarg = *vacrelstats;
> > +update_vacuum_error_cbarg(vacrelstats,
> > +
On Tue, Mar 24, 2020 at 7:18 PM Justin Pryzby wrote:
>
> On Tue, Mar 24, 2020 at 07:07:03PM +0530, Amit Kapila wrote:
> > On Tue, Mar 24, 2020 at 6:18 PM Masahiko Sawada
> > wrote:
> > > 1.
> > > +/* Update error traceback information */
> > > +olderrcbarg = *vacrelstats;
> > > +
On Tue, Mar 24, 2020 at 1:24 AM Amit Kapila wrote:
>
> On Fri, Mar 20, 2020 at 7:09 AM James Coleman wrote:
> >
> > Awesome, thanks for confirming with an actual plan.
> >
> > > I don't think it matters in nontext mode, but at least in text mode, I
> > > think
> > > maybe the Unfetched blocks sh
Ubuntu 18.04: no crash, but possibly a side effect:
[INFO] FOUserAgent - Rendered page #2685.
[INFO] FOUserAgent - Rendered page #2686.
[INFO] FOUserAgent - Rendered page #2687.
[WARN] FOUserAgent - Destination: Unresolved ID reference
"function-encode" found.
[WARN] FOUserAgent - Destination: U
On Tue, Mar 24, 2020 at 02:29:57PM +0900, Masahiko Sawada wrote:
> That seems to work fine.
>
> So we will have pg_cryptokeys within PGDATA and each key is stored
> into separate file named the key id such as "sql", "tde-wal" and
> "tde-block". I'll update the patch and post.
Yes, that makes sens
On Tue, 24 Mar 2020 at 22:37, Amit Kapila wrote:
>
> On Tue, Mar 24, 2020 at 6:18 PM Masahiko Sawada
> wrote:
> >
> >
> > I've read through the latest version patch (v31), here are my comments:
> >
> > 1.
> > +/* Update error traceback information */
> > +olderrcbarg = *vacrelstat
Erikjan Rijkers writes:
> I build the pdf (for HEAD) almost daily without problems, but at the
> moment I get the error below.
> I am not sure whether to blame my particular setup (debian stretch), or
> whether there might be an error in the .sgml. The html files still
> build OK.
Yeah, I see
On Tue, Mar 24, 2020 at 01:20:07PM +, Dean Rasheed wrote:
On Tue, 24 Mar 2020 at 01:08, Tomas Vondra wrote:
Hmmm. So let's consider a simple OR clause with two arguments, both
covered by single statistics object. Something like this:
CREATE TABLE t (a int, b int);
INSERT INTO t SELE
On Mon, Mar 23, 2020 at 9:32 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
>
> I'm giving up on making color the default, since there is clearly no
> consensus.
>
> Attached is the documentation patch reworked.
>
I think there is also some value in adding the functionality propos
On 11/13/19 4:45 PM, Alvaro Herrera wrote:
>
But it is not totally
unreasonable to have lots of partitions, and as we improve the system,
more and more people will want to.
+1
This patch still applies but there seems to be some disagreement on how
to proceed.
Any thoughts?
Regards,
--
-Dav
On 2020-03-24 15:31, Tom Lane wrote:
The problem seems to be that cedffbdb8
introduced some broken table markup. I wonder why xmllint
failed to catch it?
It's not a validity issue in the DocBook markup. The error comes from
FOP, which complains because it requires the column count, but other
Hi Fabien,
On 11/27/19 11:01 PM, Michael Paquier wrote:
On Wed, Nov 27, 2019 at 10:14:16AM +0100, Fabien COELHO wrote:
Indeed, I did not notice.
This patch no longer applies: http://cfbot.cputube.org/patch_27_2262.log
CF entry has been updated to Waiting on Author.
Regards,
--
-David
da...
On 11/29/19 12:22 AM, nagaura.ryo...@fujitsu.com wrote:
From: Michael Paquier
On Wed, Jun 26, 2019 at 11:56:28AM +, nagaura.ryo...@fujitsu.com wrote:
It seems that you did not think so at that time.
# Please refer to [1]
I don't think all the reviewers are completely negative.
I recall
On 11/29/19 4:34 AM, Fabien COELHO wrote:
It seems to me that there is no point to have the variable aset in
Command because this structure includes already MetaCommand, so the
information is duplicated. [...] Perhaps I am missing something?
Yep. ISTM that you are missing that aset is not an
On 12/1/19 8:56 PM, osumi.takami...@fujitsu.com wrote:
The latest patch includes calls to heap_open(), causing its compilation to fail.
Could you please send a rebased version of the patch? I have moved the entry to
next CF, waiting on author.
Thanks. I've fixed where you pointed out.
This
Peter Eisentraut writes:
> On 2020-03-24 15:31, Tom Lane wrote:
>> The problem seems to be that cedffbdb8
>> introduced some broken table markup. I wonder why xmllint
>> failed to catch it?
> It's not a validity issue in the DocBook markup. The error comes from
> FOP, which complains because i
Hello
> I pushed the latest version of the patch. If you have further opinion
> about immediate promotion, let's keep discussing that!
Thank you!
Honestly, I forgot that the promotion is documented in high-availability.sgml
as:
> Before failover, any WAL immediately available in the archive or
On 2020-Mar-24, David Steele wrote:
> This patch still applies but there seems to be some disagreement on
> how to proceed.
Actually, I don't think there's any disagreement regarding the patch I
last posted. (There was disagreement on the previous patches, which
were very different). Tom sugges
On 12/2/19 1:39 AM, Haozhou Wang wrote:
Thank you very much for your email. I rebased the code with the newest
master and attached it in the attachment.
This patch applies but no longer builds on Linux or Windows:
https://travis-ci.org/github/postgresql-cfbot/postgresql/builds/666113036
https
Hi David,
On 24.03.2020 16:26, David Steele wrote:
Hi Konstantin,
On 11/14/19 2:06 AM, Konstantin Knizhnik wrote:
Attached please find rebased patch with this bug fixed.
This patch no longer applies: http://cfbot.cputube.org/patch_27_2067.log
CF entry has been updated to Waiting on Author.
> On Wed, Mar 11, 2020 at 11:17:51AM +1300, David Rowley wrote:
>
> Yes, I was complaining that a ProjectionPath breaks the optimisation
> and I don't believe there's any reason that it should.
>
> I believe the way to make that work correctly requires paying
> attention to the Path's uniquekeys ra
> On Wed, Mar 11, 2020 at 06:56:09PM +0800, Andy Fan wrote:
>
> There was a dedicated thread [1] where David explain his idea very
> detailed, and you can also check that messages around that message for
> the context. hope it helps.
Thanks for pointing out to this thread! Somehow I've missed it
Hi Tom,
On 12/3/19 4:44 AM, Gareth Palmer wrote:
On Sun, Dec 1, 2019 at 4:32 PM Michael Paquier wrote:
On Fri, Nov 22, 2019 at 12:24:15PM +1300, Gareth Palmer wrote:
Attached is an updated patch with for_locking_clause added, test-cases
re-use existing tables and the comments and documentati
On Mon, Mar 23, 2020 at 11:43 PM Amit Kapila wrote:
> All others except one are passing now. See the summary of the failed
> test below and attached are failed run logs.
>
> Test Summary Report
> ---
> t/003_corruption.pl (Wstat: 65280 Tests: 14 Failed: 0)
> Non-zero exit statu
On 17.12.2019 11:10, Arthur Zakirov wrote:
On 2019/12/05 11:31, Michael Paquier wrote:
On Wed, Dec 04, 2019 at 06:15:52PM +0900, Arthur Zakirov wrote:
Ah, I thought that pg_identify_object() gives properly quoted
identity, and
it could be used to make SQL script.
It depends on the object typ
On Fri, Mar 13, 2020 at 6:58 AM Justin Pryzby wrote:
>
> Thanks for picking up this patch. There's a minor typo:
>
> +* readable outside of this sessoin. Therefore
> doing IO here isn't
>
> => session
>
> --
> Justin
>
Thanks, please see the updated and rebased patch. (m
On 12/17/19 3:10 AM, Arthur Zakirov wrote:
I attached new version of the patch. It still uses pg_identify_object(),
I'm not sure about other ways to build identities yet.
This patch applies and builds but fails regression tests on Linux and
Windows:
https://travis-ci.org/postgresql-cfbot/po
On 12/24/19 3:15 AM, Konstantin Knizhnik wrote:
New version of patch implicitly adding multicolumn statistic in
auto_explain extension and using it in optimizer for more precise
estimation of join selectivity.
This patch fixes race condition while adding statistics and restricts
generated stati
David Steele writes:
> On 12/3/19 4:44 AM, Gareth Palmer wrote:
>> Attached is a fixed version.
> Does this version of the patch address your concerns?
No. I still find the reliance on a FROM clause being present
to be pretty arbitrary. Also, I don't believe that ruleutils.c
requires no change
On Mon, Mar 23, 2020 at 6:42 PM Stephen Frost wrote:
> While I get the desire to have a default here that includes checksums,
> the way the command is structured, it strikes me as odd that the lack of
> MANIFEST_CHECKSUMS in the command actually results in checksums being
> included.
I don't thin
On 2020-03-20 01:11, Alvaro Herrera wrote:
I gave this a look. I first reformatted it so I could read it; that's
0001. Second I changed all the long items into s, which
are shorter and don't have to repeat the title of the refered to page.
(Of course, this changes the link to be in the same st
Good afternoon!
I would be grateful for some direction on how to use Background workers to
have a worker automatically restart *only* in certain cases, i.e. on
postmaster start (_PG_init) or a soft crash. I run into all sorts of
trouble if I set bgw_restart_time to actually restart on sigterm, be
I wrote:
> No doubt that's all fixable, but the realization that some cases of
> this syntax are *not* just syntactic sugar for standards-compliant
> syntax is giving me pause. Do we really want to get out front of
> the SQL committee on extending INSERT in an incompatible way?
One compromise tha
On Fri, Mar 20, 2020 at 3:58 PM Justin Pryzby wrote:
> > + A process that writes dirty pages and WAL
> > + Records to the file system and creates a special
>
> Does the chckpointer actually write WAL ?
Yes.
> An FK doesn't require the values in its table to be unique, right ?
I believ
On Tue, Mar 24, 2020 at 2:33 PM Jeremy Finzel wrote:
> I would be grateful for some direction on how to use Background workers to
> have a worker automatically restart *only* in certain cases, i.e. on
> postmaster start (_PG_init) or a soft crash. I run into all sorts of trouble
> if I set bgw
On 2020-03-24 18:03:57 +0530, Amit Kapila wrote:
> Can we change the status of CF entry for this patch [1] to committed
> or is there any work pending?
Done!
I took a quick look through this patch. While I see nothing to complain
about implementation-wise, I'm a bit befuddled as to why we need this
reporting when there is no comparable data provided for regular index-only
scans. Over there, you just get "Heap Fetches: n", and the existing
counts for b
On 2020-03-24 18:36:03 +0530, Dilip Kumar wrote:
> IMHO, I have tried the best case but did not see any performance gain
> so I am not planning to test this further. I have attached the patch
> for removing the TODO.
Pushed. Thanks!
>
>
> > > + Records to the file system and creates a special
> >
> > Does the chckpointer actually write WAL ?
>
> Yes.
>
> > An FK doesn't require the values in its table to be unique, right ?
>
> I believe it does require that the values are unique.
>
> > I think there's some confusion. Con
On 2020-03-23 17:24:49 -0400, Tom Lane wrote:
> Hearing no objections, I started to review Andres' patchset with
> that plan in mind.
Thanks for pushing the first part!
On 24.03.20 19:46, Robert Haas wrote:
Do we use shared_buffers for WAL ?
No.
What's about the explanation in
https://www.postgresql.org/docs/12/runtime-config-wal.html :
"wal_buffers (integer) The amount of shared memory used for WAL data
that has not yet been written to disk. The defau
On Tue, Mar 24, 2020 at 3:40 PM Jürgen Purtz wrote:
> On 24.03.20 19:46, Robert Haas wrote:
> Do we use shared_buffers for WAL ?
>
> No.
>
> What's about the explanation in
> https://www.postgresql.org/docs/12/runtime-config-wal.html : "wal_buffers
> (integer)The amount of shared memory used
On 2020-Mar-23, Alvaro Herrera wrote:
> COPY public.ft1 (c1, c2, c3) FROM stdin;
> pg_dump: error: query failed: ERROR: foreign-data wrapper "dummy" has no
> handler
> pg_dump: error: query was: COPY (SELECT c1, c2, c3 FROM public.ft1 ) TO
> stdout;
>
> Maybe what we should do just verify that
Andres Freund writes:
> On 2020-03-23 17:24:49 -0400, Tom Lane wrote:
>> Hearing no objections, I started to review Andres' patchset with
>> that plan in mind.
> Thanks for pushing the first part!
I pushed all of it, actually.
regards, tom lane
On Sun, Mar 15, 2020 at 3:23 PM Tomas Vondra
wrote:
> On Sun, Mar 15, 2020 at 02:48:02PM +1300, Thomas Munro wrote:
> >Stimulated by some bad plans involving JSON, I found my way to your
> >WIP stats-on-expressions patch in this thread. Do I understand
> >correctly that it will eventually also su
Justin Pryzby writes:
> On Wed, Jan 22, 2020 at 02:34:57PM +0900, Michael Paquier wrote:
>> From patch 0003:
>> /*
>> +* Indent multi-line DETAIL if being sent to client (verbose)
>> +* We don't know if it's sent to the client (client_min_messages);
>> +* Also, that affects
I think the startup sighup handler should be in startup.c, not xlog.c,
which has enough random code already. We can add an accessor in xlog.c
to let changing the walrcv status flag, to be called from the signal
handler.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Dev
Dear Sir/Madam,
I am very much interested in working on a project of PostgreSQL for Google
summer internship. While I was writing a proposal, I came across some
guidelines by the company to get in touch about the nature of the project
and then draft the proposal. I would be very much interested in
On Tue, Mar 24, 2020 at 7:07 PM Maryam Farrukh
wrote:
> Dear Sir/Madam,
>
> I am very much interested in working on a project of PostgreSQL for Google
> summer internship. While I was writing a proposal, I came across some
> guidelines by the company to get in touch about the nature of the projec
On Mon, Mar 23, 2020 at 11:44 PM Alvaro Herrera
wrote:
>
> On 2020-Mar-23, James Coleman wrote:
>
> > 4. nodeIncrementalSort.c ExecReScanIncrementalSort: This whole chunk
> > is suspect. I've mentioned previously I don't have a great mental
> > model of how rescan works and its invariants (IIRC so
On Tue, Mar 24, 2020 at 3:38 PM Amit Kapila wrote:
> On Sun, Jan 12, 2020 at 3:33 AM Alexander Korotkov
> wrote:
> >
> > On Wed, Jan 8, 2020 at 4:37 PM Tom Lane wrote:
> > > Heikki Linnakangas writes:
> > > > On 01/11/2019 01:50, Alexander Korotkov wrote:
> > > >> This happens so, because we're
On 2020-Mar-24, Alvaro Herrera wrote:
> On 2020-Mar-23, Alvaro Herrera wrote:
>
> > COPY public.ft1 (c1, c2, c3) FROM stdin;
> > pg_dump: error: query failed: ERROR: foreign-data wrapper "dummy" has no
> > handler
> > pg_dump: error: query was: COPY (SELECT c1, c2, c3 FROM public.ft1 ) TO
> >
Hi,
On 2020-03-18 18:18:44 +1300, Thomas Munro wrote:
> From 1b03eb5ada24c3b23ab8ca6db50e0c5d90d38259 Mon Sep 17 00:00:00 2001
> From: Thomas Munro
> Date: Mon, 9 Dec 2019 17:22:07 +1300
> Subject: [PATCH 3/5] Add WalRcvGetWriteRecPtr() (new definition).
>
> A later patch will read received WAL
Hi Tom,
Thanks for the feedback.
* I find it entirely unacceptable to stick some planner temporary
fields into struct SubLink. If you need that storage you'll have
to find some other place to put it. But in point of fact I don't
think you need it; it doesn't look to me to be
Nikita Glukhov writes:
> Attached new version of the patch.
I spent a little bit of time looking through this, and have a few
comments:
* You have a lot of places where tests for particular ASCII characters
are done like this:
if ((charlen == 1) && t_iseq(src, '\\'))
This is a tedious
On Tue, Mar 24, 2020 at 06:26:11PM -0400, James Coleman wrote:
On Mon, Mar 23, 2020 at 11:44 PM Alvaro Herrera
wrote:
On 2020-Mar-23, James Coleman wrote:
> 4. nodeIncrementalSort.c ExecReScanIncrementalSort: This whole chunk
> is suspect. I've mentioned previously I don't have a great mental
Hi
>From the PG logical replication documentation, I see that there is a listed
>limitation that sequence relation is not replicated logically. After some
>examination, I see that retrieving the next value from a sequence using the
>nextval() call will emits a WAL update every 32 calls to nex
"Li, Zheng" writes:
> * I find it entirely unacceptable to stick some planner temporary
> fields into struct SubLink. If you need that storage you'll have
> to find some other place to put it. But in point of fact I don't
> think you need it; it doesn't look to me to be critical
On Tue, 10 Mar 2020 at 00:13, David Rowley wrote:
> Over in inheritance_planner(), I noticed that the RT index of the
> SELECT query and the UPDATE/DELETE query can differ. There was some
> code that performed translations. I changed that code slightly so that
> it's a bit more optimal. It was bu
David Rowley writes:
> I had a closer look at this today and the code I have in
> inheritance_planner() is certainly not right.
Although I didn't get around to it for v13, there's still a plan on the
table for inheritance_planner() to get nuked from orbit [1].
Maybe this improvement should be pu
On Tue, Mar 24, 2020 at 7:08 PM Tomas Vondra
wrote:
>
> On Tue, Mar 24, 2020 at 06:26:11PM -0400, James Coleman wrote:
> >On Mon, Mar 23, 2020 at 11:44 PM Alvaro Herrera
> > wrote:
> >>
> >> On 2020-Mar-23, James Coleman wrote:
> >>
> >> > 4. nodeIncrementalSort.c ExecReScanIncrementalSort: This w
On Thu, Mar 19, 2020 at 07:53:39PM +, Dean Rasheed wrote:
On Wed, 18 Mar 2020 at 00:29, Tomas Vondra wrote:
OK, I took a look. I think from the correctness POV the patch is OK, but
I think the dependencies_clauselist_selectivity() function now got a bit
too complex. I've been able to parse
On Wed, Mar 25, 2020 at 12:41 AM Dmitry Dolgov <9erthali...@gmail.com>
wrote:
> > On Wed, Mar 11, 2020 at 06:56:09PM +0800, Andy Fan wrote:
> >
> > There was a dedicated thread [1] where David explain his idea very
> > detailed, and you can also check that messages around that message for
> > th
On 2020-03-24 16:19:21 -0700, Cary Huang wrote:
> Hi
>
>
>
> From the PG logical replication documentation, I see that there is a
> listed limitation that sequence relation is not replicated
> logically. After some examination, I see that retrieving the next
> value from a sequence using the nex
On Wed, 25 Mar 2020 at 13:00, Tom Lane wrote:
>
> David Rowley writes:
> > I had a closer look at this today and the code I have in
> > inheritance_planner() is certainly not right.
>
> Although I didn't get around to it for v13, there's still a plan on the
> table for inheritance_planner() to ge
On Tue, Mar 24, 2020 at 8:23 PM James Coleman wrote:
> While working on finding a test case to show rescan isn't implemented
> properly yet, I came across a bug. At the top of
> ExecInitIncrementalSort, we assert that eflags does not contain
> EXEC_FLAG_REWIND. But the following query (with merge
Attached is a small patch that introduces a simple function,
AllocSetEstimateChunkSpace(), and uses it to improve the estimate for
the size of a hash entry for hash aggregation.
Getting reasonable estimates for the hash entry size (including the
TupleHashEntryData, the group key tuple, the per-gro
Hello David,
On 3/25/2020 2:08 AM, David Steele wrote:
On 12/17/19 3:10 AM, Arthur Zakirov wrote:
I attached new version of the patch. It still uses
pg_identify_object(), I'm not sure about other ways to build
identities yet.
This patch applies and builds but fails regression tests on Linu
On Tue, Mar 24, 2020 at 5:05 AM Peter Eisentraut
wrote:
> You can also run this yourself without the detour through the commit
> fest app. Attached are three patches that add .appveyor.yml files, for
> MSVC, MinGW, and Cygwin respectively. (An open problem is to combine
> them all into one.) I
Hi David,
Sorry I couldn't get to this sooner.
On Wed, Mar 25, 2020 at 9:49 AM David Rowley wrote:
> On Wed, 25 Mar 2020 at 13:00, Tom Lane wrote:
> > David Rowley writes:
> > > I had a closer look at this today and the code I have in
> > > inheritance_planner() is certainly not right.
> >
> >
Hi pghackers,
This is my first time posting here ... Gilles Darold and I are developing a
new FDW which is based on the contrib/postgres_fdw. The postgres_fdw logic uses
a RegisterXactCallback function to send local transactions remote. But I found
that a registered XactCallback is not always c
On Wed, Mar 25, 2020 at 12:44 AM Tom Lane wrote:
>
> I took a quick look through this patch. While I see nothing to complain
> about implementation-wise, I'm a bit befuddled as to why we need this
> reporting when there is no comparable data provided for regular index-only
> scans. Over there, y
On Tue, Mar 24, 2020 at 7:56 AM Juan José Santamaría Flecha
wrote:
> On Mon, Mar 23, 2020 at 5:59 AM Thomas Munro wrote:
>> Done in this new 0002 patch (untested). 0001 removes the comment that
>> individual collations can't have a NULL version, reports NULL for
>> Linux/glibc collations like C.
On Tue, Mar 24, 2020 at 09:47:30PM +0900, Masahiko Sawada wrote:
> We need to set the error context after setting new_rel_pages.
Done
> The type name ErrCbPhase seems to be very generic name, how about
> VacErrCbPhase or VacuumErrCbPhase?
Done.
Thanks for your review comments.
--
Justin
>From
On Tue, Mar 24, 2020 at 7:51 PM Masahiko Sawada
wrote:
>
> On Tue, 24 Mar 2020 at 22:37, Amit Kapila wrote:
> >
> > On Tue, Mar 24, 2020 at 6:18 PM Masahiko Sawada
> > wrote:
> > >
> > >
> > > I've read through the latest version patch (v31), here are my comments:
> > >
> > > 1.
> > > +/
On Wed, Mar 25, 2020 at 8:49 AM Justin Pryzby wrote:
>
> On Tue, Mar 24, 2020 at 09:47:30PM +0900, Masahiko Sawada wrote:
> > We need to set the error context after setting new_rel_pages.
>
> Done
>
> > The type name ErrCbPhase seems to be very generic name, how about
> > VacErrCbPhase or VacuumEr
On Wed, Mar 25, 2020 at 12:46 AM Andres Freund wrote:
>
> On 2020-03-24 18:36:03 +0530, Dilip Kumar wrote:
> > IMHO, I have tried the best case but did not see any performance gain
> > so I am not planning to test this further. I have attached the patch
> > for removing the TODO.
>
> Pushed. Than
On Wed, Mar 25, 2020 at 9:23 AM Amit Kapila wrote:
>
> On Wed, Mar 25, 2020 at 12:46 AM Andres Freund wrote:
> >
> > On 2020-03-24 18:36:03 +0530, Dilip Kumar wrote:
> > > IMHO, I have tried the best case but did not see any performance gain
> > > so I am not planning to test this further. I hav
1 - 100 of 113 matches
Mail list logo
