On 2020/01/28 0:24, Fujii Masao wrote:
On 2020/01/15 19:18, Paul Guo wrote:
I further fixed the last test failure (due to a small bug in the test, not in
code). Attached are the new patch series. Let's see the CI pipeline result.
Thanks for updating the patches!
I started reading the
Thomas Munro writes:
> I think this caused anole to say:
> "reloptions.c", line 1362: error #2042: operand types are incompatible
> ("void" and "int")
> errdetail_internal("%s", _(optenum->detailmsg)) : 0));
Yeah, I was just looking at that :-(
We could revert the change to have these
On Wed, Mar 25, 2020 at 9:30 AM Tom Lane wrote:
> 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.
I
On 2020/03/25 0:17, Sergei Kornilov wrote:
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,
On Wed, 25 Mar 2020 at 14:08, Justin Pryzby wrote:
>
> On Wed, Mar 25, 2020 at 10:22:21AM +0530, Amit Kapila wrote:
> > On Wed, Mar 25, 2020 at 10:05 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, 25 Mar 2020 at 12:44, Amit Kapila wrote:
> > > >
> > > > On Tue, Mar 24, 2020 at 7:51 PM
On Wed, Mar 25, 2020 at 10:22:21AM +0530, Amit Kapila wrote:
> On Wed, Mar 25, 2020 at 10:05 AM Masahiko Sawada
> wrote:
> >
> > On Wed, 25 Mar 2020 at 12:44, Amit Kapila wrote:
> > >
> > > On Tue, Mar 24, 2020 at 7:51 PM Masahiko Sawada
> > > wrote:
> > > >
> > > >
> > > > I got the point. But
On 2020/03/10 11:47, Kyotaro Horiguchi wrote:
At Thu, 6 Feb 2020 23:23:42 +0900, Fujii Masao
wrote in
On 2020/02/06 1:10, Jeff Janes wrote:
If the restore command claims to have succeeded, but fails to have created
a file with the right name (due to typos or escaping or quoting issues,
On Wed, Mar 25, 2020 at 10:05 AM Masahiko Sawada
wrote:
>
> On Wed, 25 Mar 2020 at 12:44, Amit Kapila wrote:
> >
> > On Tue, Mar 24, 2020 at 7:51 PM Masahiko Sawada
> > wrote:
> > >
> > >
> > > I got the point. But if we set the error context before that, I think
> > > we need to change the
On Wed, Mar 25, 2020 at 01:34:43PM +0900, Masahiko Sawada wrote:
> I meant that with the patch, suppose that the table has 100 blocks and
> we're truncating it to 50 blocks in RelationTruncate(), the error
> context message will be "while truncating relation "aaa.bbb" to 100
> blocks", which is
On Wed, 25 Mar 2020 at 12:44, Amit Kapila wrote:
>
> 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
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
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.
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
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 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
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
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,
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
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.
> >
>
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
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
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
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
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
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
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
> >
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
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
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
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
"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
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
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
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
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
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
> >
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
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
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
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
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
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
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
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 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
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
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
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!
>
>
> > > + 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.
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!
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
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!
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
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
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
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,
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
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
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
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:
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.
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
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
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
> 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
> 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
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 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
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
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
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
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
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
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
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
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
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,
--
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
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
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
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 =
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
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:
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
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 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,
> > +
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 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 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
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
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
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
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
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
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
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
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
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 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
1 - 100 of 115 matches
Mail list logo
