On Thu, Feb 06, 2020 at 04:52:48PM +0900, Amit Langote wrote:
> On Thu, Feb 6, 2020 at 4:31 PM Michael Paquier wrote:
>> FWIW, if we bother adding SQL functions for that, my first impression
>> was to have three functions, each one of them returning:
>> - FirstNormalObjectId
>> -
On Thu, Feb 6, 2020 at 10:31 AM Amit Langote wrote:
> On Thu, Feb 6, 2020 at 8:44 AM Justin Pryzby wrote:
> > On Wed, Feb 05, 2020 at 03:53:45PM +0900, Amit Langote wrote:
> > > diff --git a/src/test/regress/sql/alter_table.sql
> > > b/src/test/regress/sql/alter_table.sql
> > > +-- alter type
HI,
On Thu, Feb 6, 2020 at 3:24 PM Fujii Masao wrote:
> > I added a new (but minimal) isolation test for the case of tid scan.
> > (v12 and HEAD will be failed this test. v11 and HEAD with my patch
> > will be passed)
>
> Isn't this test scenario a bit overkill? We can simply test that
> as
On Wed, Feb 5, 2020 at 9:42 AM Dilip Kumar wrote:
>
> >
> > I am not able to understand the change in
> > v8-0011-BUGFIX-set-final_lsn-for-subxacts-before-cleanup. Do you have
> > any explanation for the same?
>
> It appears that in ReorderBufferCommitChild we are always setting the
> final_lsn
On Thu, Feb 06, 2020 at 09:24:16AM +0900, Michael Paquier wrote:
> On Wed, Feb 05, 2020 at 07:57:20AM +0100, Julien Rouhaud wrote:
> > This looks good, thanks a lot!
>
> Thanks for double-checking. And done.
Thanks!
While on the topic, is there any reason why the backend stays a group leader
Hi,
I've been looking at the 'make_join_rel()' part of the patch, and I'm
aware that, if we are joining A and B, a 'grouped join rel (AB)' would
be created besides the 'plain join rel (AB)', and paths are added by 1)
applying partial aggregate to the paths of the 'plain join rel (AB)', or
2)
On 05/02/2020 21:56, Jeff Davis wrote:
On Tue, 2020-02-04 at 18:10 +0200, Heikki Linnakangas wrote:
I'd love to change the LogicalTape API so that you could allocate
and
free tapes more freely. I wrote a patch to do that, as part of
replacing
tuplesort.c's polyphase algorithm with a simpler one
On Thu, 6 Feb 2020 at 16:53, Amit Langote wrote:
>
> On Thu, Feb 6, 2020 at 4:31 PM Michael Paquier wrote:
> > On Thu, Feb 06, 2020 at 04:25:47PM +0900, Amit Langote wrote:
> > > About the implementation, how about defining a static inline function,
> > > say is_user_object(), next to
During logical decoding, we send replication_origin and
replication_origin_lsn when we decode commit. In pgoutput_begin_txn,
we send values for these two but never used on the subscriber side.
Though we have provided a function (logicalrep_read_origin) to read
these two values but that is not
On Thu, Feb 6, 2020 at 20:11 Amit Kapila wrote:
> On Thu, Feb 6, 2020 at 12:10 PM Amit Kapila
> wrote:
> >
> > On Thu, Feb 6, 2020 at 11:41 AM Amit Langote
> wrote:
> > >
> > > Hi,
> > >
> > > Attached fixes $subject.
> > >
> >
> > LGTM. I will push this later today.
> >
>
> Pushed.
Thanks
> On Thu, Feb 06, 2020 at 10:24:50AM +0900, Kyotaro Horiguchi wrote:
> At Wed, 5 Feb 2020 17:37:30 +0100, Dmitry Dolgov <9erthali...@gmail.com>
> wrote in
> > > On Tue, Feb 04, 2020 at 08:34:09PM +, Floris Van Nee wrote:
> > >
> > > > this point me and Jesper inclined to go with the second
On Thu, Feb 6, 2020 at 10:45 AM Michael Paquier wrote:
>
> On Thu, Feb 06, 2020 at 08:47:14AM +0530, Amit Kapila wrote:
> > Your changes look fine to me on the first read. I will push this to
> > HEAD unless there are any objections. If we want them in
> > back-branches, we might want to
On Thu, Feb 6, 2020 at 12:10 PM Amit Kapila wrote:
>
> On Thu, Feb 6, 2020 at 11:41 AM Amit Langote wrote:
> >
> > Hi,
> >
> > Attached fixes $subject.
> >
>
> LGTM. I will push this later today.
>
Pushed.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
At Thu, 6 Feb 2020 11:57:07 +0100, Dmitry Dolgov <9erthali...@gmail.com> wrote
in
> > On Thu, Feb 06, 2020 at 10:24:50AM +0900, Kyotaro Horiguchi wrote:
> > At Wed, 5 Feb 2020 17:37:30 +0100, Dmitry Dolgov <9erthali...@gmail.com>
> > wrote in
> > We could add an additional parameter "in_cursor"
On Thu, 6 Feb 2020 at 19:12, Kasahara Tatsuhito
wrote:
>
> HI,
>
> On Thu, Feb 6, 2020 at 3:24 PM Fujii Masao
> wrote:
> > > I added a new (but minimal) isolation test for the case of tid scan.
> > > (v12 and HEAD will be failed this test. v11 and HEAD with my patch
> > > will be passed)
> >
So it appears to me that what commit 6bf0bc842 did in this area was
not just wrong, but disastrously so. Before that, we had a macro that
evaluated isinf(val) before it evaluated the inf_is_valid condition.
Now we have check_float[48]_val which do it the other way around.
That would be okay if
I wondered if it wouldn't be better if CLUSTER ON was stored in pg_class as the
Oid of a clustered index, rather than a boolean in pg_index.
That likely would've avoided (or at least exposed) this issue.
And avoids the possibility of having two indices marked as "clustered".
These would be more
Sorry, I forgot to write more significant thing.
On 2020/02/06 21:22, Kyotaro Horiguchi wrote:
At Thu, 6 Feb 2020 11:57:07 +0100, Dmitry Dolgov <9erthali...@gmail.com> wrote
in
On Thu, Feb 06, 2020 at 10:24:50AM +0900, Kyotaro Horiguchi wrote:
At Wed, 5 Feb 2020 17:37:30 +0100, Dmitry Dolgov
On Thu, Feb 06, 2020 at 04:43:18PM +0530, Amit Kapila wrote:
> On Thu, Feb 6, 2020 at 10:45 AM Michael Paquier wrote:
> >
> > On Thu, Feb 06, 2020 at 08:47:14AM +0530, Amit Kapila wrote:
> > > Your changes look fine to me on the first read. I will push this to
> > > HEAD unless there are any
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, for example), no complaint is
issued at the time, and it then fails later with a relatively uninformative
On 2020-Feb-05, Peter Geoghegan wrote:
> The second item genereated another thread a little after this thread.
> Everything was handled on this other thread. Ultimately, I rejected
> the enhancement on the grounds that it wasn't safe on standbys in the
> face of concurrent splits and deletions
On 2020/02/03 14:26, Amit Langote wrote:
On Mon, Feb 3, 2020 at 2:07 PM Fujii Masao wrote:
On 2020/02/03 11:05, Amit Langote wrote:
Okay. How about the attached?
Thanks for the patches! You added the note just after the description
about row level security on inherited table, but isn't
Hi,
On 2020-02-06 07:18:00 +0100, Laurenz Albe wrote:
> On Wed, 2020-02-05 at 20:00 -0800, Andres Freund wrote:
> > The ringbuffers we use for seqscans, vacuum, copy etc can cause very
> > drastic slowdowns (see e.g. [1]), an can cause some workloads to
> > practically never end up utilizing
Hi,
On 2020-02-06 11:03:51 -0500, Tom Lane wrote:
> Andres seems to be of the opinion that the compiler should be willing
> to ignore the semantic requirements of the C standard in order
> to rearrange the code back into the cheaper order. That sounds like
> wishful thinking to me ... even if it
Hi,
On 2020-02-06 13:15:04 -0500, Robert Haas wrote:
> On Wed, Feb 5, 2020 at 11:00 PM Andres Freund wrote:
> > I.e. to maintain the current defaults, seqscan_ringbuffer_threshold
> > would be -4.0, but could be also be set to an absolute 4GB (converted to
> > pages). Probably would want a GUC
On Thu, Feb 6, 2020 at 1:52 PM Andres Freund wrote:
> I admit it's awkward. I think we possibly could still just make the size
> displayed in bytes in either case, reducing that issue a *bit*?
That seems like it makes it even more confusing, honestly.
> > It'd sort of be nicer to have two
Michael Paquier writes:
> On Thu, Jan 16, 2020 at 10:00:52AM +0900, Michael Paquier wrote:
>> Thanks for the review. Let's wait a couple of days to see if others
>> have objections or more comments about this patch, but I'd like to
>> fix the issue and backpatch down to 12 where the parameters
On 2020-02-03 20:32, Tom Lane wrote:
> Things are evidently also going wrong for "gtest1_1". In that case
> the generated property is inherited from the parent gtest1, so we
> shouldn't be emitting anything ... how come the patch fails to
> make it do that?
This is fixed by the attached new
On Wed, Feb 5, 2020 at 11:00 PM Andres Freund wrote:
> I.e. to maintain the current defaults, seqscan_ringbuffer_threshold
> would be -4.0, but could be also be set to an absolute 4GB (converted to
> pages). Probably would want a GUC show function that displays
> proportional values in a nice
On 2020-Feb-06, Justin Pryzby wrote:
> I wondered if it wouldn't be better if CLUSTER ON was stored in pg_class as
> the
> Oid of a clustered index, rather than a boolean in pg_index.
Maybe. Do you want to try a patch?
> That likely would've avoided (or at least exposed) this issue.
> And
On Thu, Feb 6, 2020 at 11:04 AM Tom Lane wrote:
> So it appears to me that what commit 6bf0bc842 did in this area was
> not just wrong, but disastrously so. Before that, we had a macro that
> evaluated isinf(val) before it evaluated the inf_is_valid condition.
> Now we have check_float[48]_val
On Wed, Feb 5, 2020 at 9:32 AM Julien Rouhaud wrote:
> There's also the possibility to reserve 1 bit of the hash to know if
> this is a utility command or not, although I don't recall right now
> all the possible issues with utility commands and some special
> handling of them. I'll work on it
On 2020-01-15 19:11, Andres Freund wrote:
/*
* Set up constraint/default info
*/
if (has_not_null || ndef > 0 ||
attrmiss || relation->rd_rel->relchecks)
test, i.e. there are no defaults.
It does still strike me as not great that we can get a
On Mon, Feb 3, 2020 at 10:18 PM Masahiko Sawada
wrote:
> > I'm lost. If pg_{en,de}crypt and pg_kmgr_unwrap are functions, what
> > prevent users to:
> >
> >SELECT pg_kmgr_unwrap('');
> >
> > so as to recover the key, somehow in contradiction to "allows user to
> > encrypt and decrypt data
On 2020-02-06 21:29:58 +0100, Peter Eisentraut wrote:
> On 2020-01-15 19:11, Andres Freund wrote:
> > /*
> > * Set up constraint/default info
> > */
> > if (has_not_null || ndef > 0 ||
> > attrmiss || relation->rd_rel->relchecks)
> > test, i.e. there are no defaults.
On Fri, Feb 07, 2020 at 08:33:40AM +0530, Amit Kapila wrote:
> On Thu, Feb 6, 2020 at 7:26 PM Justin Pryzby wrote:
> >
> > On Thu, Feb 06, 2020 at 04:43:18PM +0530, Amit Kapila wrote:
> > > On Thu, Feb 6, 2020 at 10:45 AM Michael Paquier
> > > wrote:
> > > >
> > > > On Thu, Feb 06, 2020 at
pgxs.mk assumes that if $(EXTENSION) is set, a file
$(EXTENSION).control must exist in the $(srcdir).
Extensions that need to support multiple Pg versions, multiple
variants of the extension, etc may need to template their extension
control file. PGXS's assumption prevents those extensions from
At Wed, 5 Feb 2020 23:45:52 -0800, Noah Misch wrote in
> Buildfarm runs have triggered the assertion at the end of
> SyncRepGetSyncStandbysPriority():
..
> On my development system, this delay injection reproduces the failure:
>
> --- a/src/backend/replication/syncrep.c
> +++
Hi,
On Fri, Feb 7, 2020 at 1:27 PM Kyotaro Horiguchi
wrote:
> It seems that nkeys and key are useless. Since every table_beginscan_*
> functions have distinct parameter sets, don't we remove them from
> table_beginscan_tid?
Yeah, actually, when calling table_beginscan_tid(), nkeys is set to 0
Hi,
On 2019-10-28 23:58:11 -0700, Soumyadeep Chakraborty wrote:
> > Cool! I'll probably merge that into my patch (with attribution of
> > course).
> >
> > I wonder if it'd nicer to not have separate C variables for all of
> > these, and instead look them up on-demand from the module loaded in
> >
Hello,
Continuing the work done in commits 0dc8ead4 and c24dcd0c, here are a
few more places where we could throw away some code by switching to
pg_pread() and pg_pwrite().
0001-Use-pg_pread-and-pg_pwrite-in-slru.c.patch
Description: Binary data
0002-Use-pg_pwrite-in-rewriteheap.c.patch
Hi,
On 2020-02-07 12:38:27 +1300, Thomas Munro wrote:
> Continuing the work done in commits 0dc8ead4 and c24dcd0c, here are a
> few more places where we could throw away some code by switching to
> pg_pread() and pg_pwrite().
Nice.
> From 5723976510f30385385628758d7118042c4e4bf6 Mon Sep 17
On Fri, Feb 7, 2020 at 1:16 AM Fujii Masao wrote:
> On 2020/02/03 14:26, Amit Langote wrote:
> > On Mon, Feb 3, 2020 at 2:07 PM Fujii Masao
> > wrote:
> >> On 2020/02/03 11:05, Amit Langote wrote:
> >>> Okay. How about the attached?
> >>
> >> Thanks for the patches! You added the note just
On Thu, Feb 6, 2020 at 7:26 PM Justin Pryzby wrote:
>
> On Thu, Feb 06, 2020 at 04:43:18PM +0530, Amit Kapila wrote:
> > On Thu, Feb 6, 2020 at 10:45 AM Michael Paquier wrote:
> > >
> > > On Thu, Feb 06, 2020 at 08:47:14AM +0530, Amit Kapila wrote:
> > > > Your changes look fine to me on the
At Fri, 7 Feb 2020 12:27:26 +0900, Kasahara Tatsuhito
wrote in
> > IIUC setting SO_ALLOW_STRAT, SO_ALLOW_SYNC and SO_ALLOW_PAGEMODE has
> > no meaning during tid scan. I think v11 also should be the same.
> Thanks for your check, and useful advise.
> I was wondering if I should keep these
Hi,
On 2019-08-21 13:59:00 -0700, Melanie Plageman wrote:
> >> > +step "controller_print_speculative_locks" { SELECT
> >> locktype,classid,objid,mode,granted FROM pg_locks WHERE
> >> locktype='speculative
> >> > +token' ORDER BY granted; }
> >>
> >> I think showing the speculative locks is
Hello,
Here's a rebase of a refactoring patch that got lost behind a filing
cabinet on another thread even though there seemed to be some
agreement that we probably want something like this[1]. It introduces
a new type SegmentNumber, instead of using BlockNumber to represent
segment numbers.
Hi,
On Thu, Feb 6, 2020 at 11:01 PM Masahiko Sawada
wrote:
>
> On Thu, 6 Feb 2020 at 19:12, Kasahara Tatsuhito
> wrote:
> I've tested predicate locking including promotion cases with v3 patch
> and it works fine.
>
> +table_beginscan_tid(Relation rel, Snapshot snapshot,
> + int
On Fri, Feb 07, 2020 at 09:26:04AM +0530, Amit Kapila wrote:
> On Fri, Feb 7, 2020 at 8:41 AM Justin Pryzby wrote:
> >
> > On Fri, Feb 07, 2020 at 08:33:40AM +0530, Amit Kapila wrote:
> > > On Thu, Feb 6, 2020 at 7:26 PM Justin Pryzby wrote:
> > > >
> > > > On Thu, Feb 06, 2020 at 04:43:18PM
On Fri, 7 Feb 2020 at 05:30, Robert Haas wrote:
>
> On Mon, Feb 3, 2020 at 10:18 PM Masahiko Sawada
> wrote:
> > > I'm lost. If pg_{en,de}crypt and pg_kmgr_unwrap are functions, what
> > > prevent users to:
> > >
> > >SELECT pg_kmgr_unwrap('');
> > >
> > > so as to recover the key,
Hi,
On 2020-02-07 11:18:29 +0900, Masahiko Sawada wrote:
> Another idea we discussed is to internally integrate pgcrypto with the
> key management system.
Perhaps this has already been discussed (I only briefly looked): I'd
strongly advise against having any new infrastrure depend on
pgcrypto.
Hi,
On 2019-10-28 23:58:11 -0700, Soumyadeep Chakraborty wrote:
> > Sorry for not replying to that earlier. I'm not quite sure it's
> > actually worthwhile doing so - did you try to measure any memory / cpu
> > savings?
>
> No problem, thanks for the reply! Unfortunately, I did not do anything
> On 6 Feb 2020, at 20:04, Tom Lane wrote:
> I think this should be reverted. Perhaps there's a way to do it without
> these problems, but we failed to find one in the past.
Or change to the v1 patch in this thread, which avoids the problem by doing it
in the OpenSSL code. It's a shame to
On Thu, Feb 06, 2020 at 09:23:33AM +0100, Julien Rouhaud wrote:
> While on the topic, is there any reason why the backend stays a group leader
> for the rest of its lifetime, and should we change that?
Nothing happens without a reason. a1c1af2 is the original commit, and
the thread is here:
On Fri, Feb 7, 2020 at 8:41 AM Justin Pryzby wrote:
>
> On Fri, Feb 07, 2020 at 08:33:40AM +0530, Amit Kapila wrote:
> > On Thu, Feb 6, 2020 at 7:26 PM Justin Pryzby wrote:
> > >
> > > On Thu, Feb 06, 2020 at 04:43:18PM +0530, Amit Kapila wrote:
> > > > On Thu, Feb 6, 2020 at 10:45 AM Michael
On Fri, Feb 7, 2020 at 1:00 PM Thomas Munro wrote:
> [1] https://www.postgresql.org/message-id/flat/
That should be:
[1]
https://www.postgresql.org/message-id/flat/20190429130321.GA14886%40alvherre.pgsql#7e4ed274b6552d6c5e18a069579321c9
On Thu, Feb 06, 2020 at 11:30:40PM +0100, Daniel Gustafsson wrote:
> Or change to the v1 patch in this thread, which avoids the problem by doing it
> in the OpenSSL code. It's a shame to have generic TLS functionality be
> OpenSSL
> specific when everything else TLS has been abstracted, but not
Hi,
On 2020-02-01 18:34:33 +0900, Michael Paquier wrote:
> Seeing nothing, committed v2.
For reference: As a consequence of the discussion starting at
https://www.postgresql.org/message-id/20200205172259.GW3195%40tamriel.snowman.net
this patch has been reverted, at least for now.
Greetings,
Hi,
On February 6, 2020 11:42:30 PM PST, keisuke kuroda
wrote:
>Hi,
>
>I have been testing with newer compiler (clang-7)
>and result is a bit different at least with clang-7.
>Compiling PG 12.1 (even without patch) with clang-7
>results in __isinf() no longer being a bottleneck,
>that is, you
Hi,
I have been testing with newer compiler (clang-7)
and result is a bit different at least with clang-7.
Compiling PG 12.1 (even without patch) with clang-7
results in __isinf() no longer being a bottleneck,
that is, you don't see it in profiler at all.
So, there is no issue for people who use
Since the user does not need to know the master secret key used to cipher the
data, I don't think we should expose "pg_kmgr_unwrap("")" SQL function to
the user at all.
The wrapped key "" is stored in control data and it is possible to obtain
by malicious user and steal the key by
On Thu, Feb 6, 2020 at 12:01 AM Heikki Linnakangas wrote:
> It wasn't strictly required for what I was hacking on then. IIRC it
> would have saved some memory during sorting, but Peter G felt that it
> wasn't worth the trouble, because he made some other changes around the
> same time, which made
62 matches
Mail list logo
