On Thu, Sep 10, 2020 at 4:20 PM Fujii Masao wrote:
>
> >> One alternative is to add only hooks into PostgreSQL core so that we can
> >> implement the global transaction management outside. This idea was
> >> discussed before as the title "eXtensible Transaction Manager API".
> >
> > Yeah, I read t
Thanks for the review comments. I will post a new patch soon
addressing all the comments.
On Tue, Sep 15, 2020 at 2:49 PM Fujii Masao wrote:
>
> + PQreset(entry->conn);
>
> Isn't using PQreset() to reconnect to the foreign server unsafe?
> When new connection is established,
On Wed, 16 Sep 2020 at 17:43, Tom Lane wrote:
>
> Hmm ... the thread leading up to 0921554 indicates that the performance
> penalty of update_process_title=on is just ridiculously large on Windows.
> Maybe those numbers are not relevant to crash recovery WAL-application,
> but it might be smart to
On Wed, Mar 18, 2020 at 04:50:38PM -0300, Alvaro Herrera wrote:
> well, not "forever", but:
No updates in the last six months, so I am marking it as returned with
feedback.
PS: the patch fails to apply.
--
Michael
signature.asc
Description: PGP signature
On Thu, Sep 03, 2020 at 08:45:17AM +0900, Tatsuro Yamada wrote:
> I try to summarize the discussion so far.
Could you provide at least a rebased version of the patch? The CF bot
is complaning here.
--
Michael
signature.asc
Description: PGP signature
On Wed, Sep 09, 2020 at 08:47:36PM +0200, Peter Eisentraut wrote:
> ok done
As far as I can see, patches 0001 and 0002 have been already applied,
but not 0003. Could you send a rebase to allow the CF bot to run, at
least?
--
Michael
signature.asc
Description: PGP signature
On Sat, Aug 15, 2020 at 10:09:15AM +1200, Thomas Munro wrote:
> And ... now that this has a commitfest entry, cfbot told me about a
> small problem in a makefile. Third time lucky?
Still lucky since then, and the CF bot does not complain. So... The
meat of the patch is in 0003 which is fixing a
On Sat, Jul 18, 2020 at 09:24:11AM -0400, Andrew Dunstan wrote:
> I think patches 5 and 6 need to be submitted to the next commitfest,
> This is far too much scope creep to be snuck in under the current CF item.
>
> I'll look at patches 1-4.
Even with that, the patch set has been waiting on autho
On Wed, Sep 16, 2020 at 11:35:22AM +0300, Krasiyan Andreev wrote:
> I am thinking also to concentrate on Vik's patch, if it has a clear design
> point of view, clear design, I can withdraw mine patch.
Okay, I have done that then.
--
Michael
signature.asc
Description: PGP signature
On Thu, Jul 16, 2020 at 09:08:09PM +0200, Pavel Stehule wrote:
> I am sending another patch that tries to allow CachedPlans for CALL
> statements. I think this patch is very accurate, but it is not nice,
> because it is smudging very precious reference counting for CachedPlans.
Amit, you are regis
On Wed, Sep 16, 2020 at 1:20 PM Greg Nancarrow wrote:
>
> Fortunately I have been given permission to share the exact table
> definition and data I used, so you can check the behaviour and timings
> on your own test machine.
>
Thanks Greg for the script. I ran your test case and I didn't observe
On Fri, Mar 27, 2020 at 06:42:49PM -0400, David Steele wrote:
> Regarding Windows testing you may find this thread useful:
>
> https://www.postgresql.org/message-id/CAMN686ExUKturcWp4POaaVz3gR3hauSGBjOCd0E-Jh1zEXqf_Q%40mail.gmail.com
Since then, the patch is failing to apply. As this got zero ac
On Wed, Jul 29, 2020 at 08:08:06PM +0530, Rahila Syed wrote:
> The make check passes.
Since then, the patch is failing to apply, waiting on author and the
thread has died 6 weeks or so ago, so I am marking it as RwF in the
CF.
--
Michael
signature.asc
Description: PGP signature
On Thu, Jul 09, 2020 at 04:17:59PM -0400, Mike Palmiotto wrote:
> Thanks for the reviews. I'm hoping to get to this next week (hopefully
> sooner). It was on my TODO list to use this approach (from the last
> round of reviews), so I'll make sure to do it first.
Nothing has happened here in two mon
On Fri, Aug 21, 2020 at 03:25:29PM +0900, Masahiko Sawada wrote:
> Thank you for letting me know. I've attached the latest version patch set.
A rebase is needed again as the CF bot is complaining.
--
Michael
signature.asc
Description: PGP signature
On Mon, Sep 07, 2020 at 01:13:10PM +0900, Michael Paquier wrote:
> Josef, the patch has been waiting on author for a bit more than one
> month, so could you send a rebased version please? It looks that you
> are still a bit confused by the commit fest process, and as a first
> step we need a clean
On Thu, Jul 02, 2020 at 06:38:02PM +0300, Konstantin Knizhnik wrote:
> Sorry, correct patch is attached.
This needs again a rebase, and has been waiting on author for 6 weeks
now, so I am switching it to RwF.
--
Michael
signature.asc
Description: PGP signature
On Thu, Aug 06, 2020 at 11:50:06AM +0900, Michael Paquier wrote:
> True that you need an extra GRANT USAGE ON pg_toast to achieve that
> for users with no privileges, but that's not impossible now either. I
> am not sure that this use-case justifies a new option and more
> complications in the cod
On Tue, Mar 03, 2020 at 11:50:04PM -0300, Alvaro Herrera wrote:
> So, who is updating this patch for the new cmdtaglist.h stuff?
This patch had no activity for months, so I am marking it as returned
with feedback.
--
Michael
signature.asc
Description: PGP signature
On Tue, Aug 25, 2020 at 04:32:02PM +0300, Heikki Linnakangas wrote:
> On 20/08/2020 11:32, Kyotaro Horiguchi wrote:
> > 0002: Rewording that old->target and new->source makes the meaning far
> > clearer. Moving decisions core code into filemap_finalize is
> > reasonable.
> >
> > By th
On Wed, Jun 10, 2020 at 01:45:02PM -0400, Robert Haas wrote:
> My spidey sense is tingling here, telling me that we need some actual
> benchmarking. Like, suppose we test the two patches under normal cases
> and under cases that are constructed to be as bad as possible for each
> of them. Or suppos
On Fri, Jul 31, 2020 at 06:47:48PM +0900, torikoshia wrote:
> Oops, sorry about that.
> I just fixed it there for now.
The regression tests of the patch look unstable, and the CF bot is
reporting a failure here:
https://travis-ci.org/github/postgresql-cfbot/postgresql/builds/727833416
--
Michael
On Wed, Sep 16, 2020 at 01:52:27PM +0200, Pavel Stehule wrote:
> and some natural behaviour - any special case with different behaviour is a
> bad thing generally.
Please note that v33 of the patch fails to apply, speaking of at least
0001. Could you provide a rebase?
--
Michael
signature.asc
D
On Wed, Sep 02, 2020 at 04:50:14PM +0300, Anastasia Lubennikova wrote:
> I've looked through the previous discussion. As far as I got it, most of the
> controversy was about online checksums improvements.
This patch is waiting on author for two weeks now. Michael, could you
reply to the points ra
On Fri, Sep 04, 2020 at 07:42:27PM +0530, Ashutosh Bapat wrote:
> After this change, the patch will be ready for a committer.
Alexandra, this patch is waiting on author after this review. Could
you answer to the points raised by Ashutosh and update this patch
accordingly?
--
Michael
signature.a
Hi,
On 2020-09-17 14:20:50 +1200, Thomas Munro wrote:
> I wonder if there is a way we could make "Minimal Tuples but with the
> length travelling separately (and perhaps chopped off?)" into a
> first-class concept... It's also a shame to be schlepping a bunch of
> padding bytes around.
There rea
On Mon, Aug 31, 2020 at 06:03:02PM +0900, Kyotaro Horiguchi wrote:
> Rebased. Fixed bogus tests and strange tentative API change of
> SSLServer.pm. Corrected a (maybe) spelling mistake. I'm going to
> register this to the coming CF.
Stephen, are you planning to look at that? I know that you are
On Tue, Sep 15, 2020 at 02:56:40PM +0900, Michael Paquier wrote:
> I have completed the patch with those parts as per the attached. If
> there are any objections or extra opinions, please feel free.
And done with 7307df1.
--
Michael
signature.asc
Description: PGP signature
On Thu, Sep 17, 2020 at 12:14 AM Tom Lane wrote:
>
> Robert Haas writes:
> > OK. After some more study of the thread and some more experimentation,
> > I came up with the attached. I'll go ahead and commit this if nobody
> > objects.
>
> This is OK by me.
>
Looks good to me too.
Thanks,
--
Wi
On Wed, Sep 9, 2020 at 5:23 PM Amit Khandekar wrote:
> I went ahead and tried doing this. I chose an approach where we can
> return the pointer to the in-place minimal tuple data if it's a
> heap/buffer/minimal tuple slot. A new function
> ExecFetchSlotMinimalTupleData() returns in-place minimal t
Amit Langote writes:
> On Thu, Sep 17, 2020 at 3:40 AM Tom Lane wrote:
>> I also did a bit more work on the comments. (Speaking of which,
>> is there a better place to put the commentary you removed from
>> InitResultRelInfo? It was surely wildly out of place there,
>> but I'm wondering if mayb
On Thu, Sep 17, 2020 at 3:40 AM Tom Lane wrote:
> Amit Langote writes:
> > Updated patch attached.
>
> Pushed with a little bit of fooling about.
Thank you.
> After looking at the
> git history, I saw that the Assert we were wondering about used to
> be just "Assert(constr)", and there were no
> I have nothing, I'm just reading starter papers and trying to learn a
> bit more about the concepts at this stage. I was thinking of
> reviewing some of the more mechanical parts of the patch set, though,
> like perhaps the transition table lifetime management, since I have
> worked on that area
Alvaro Herrera writes:
> On 2020-Sep-16, Tom Lane wrote:
>> I think the issue is that pgindent believes "numeric" and "chr" are
>> typedefs. (The regex code can be blamed for "chr", but I'm not quite
>> sure where "numeric" is coming from.)
> It's in src/interfaces/ecpg/include/pgtypes_numeric.h
Alvaro Herrera writes:
> On 2020-Sep-16, Tom Lane wrote:
>> Note that your changes need to be backpatched into v13,
>> because AFAICS this code is violating the FE/BE protocol
>> right now --- it's just luck that libpq isn't moaning
>> about extra CommandComplete messages. But I don't think
>> we
I wrote:
> Daniel Gustafsson writes:
>> The attached patch fixes the generation of sql_help.h and perl_opmask.h to
>> make
>> sure they conform to pgindent. Those were the only file I got diffs in
>> after a
>> pgindent run apart from fmgrprotos.h which gave the below:
> Hmm, I seem to recall
On 2020-Sep-16, Tom Lane wrote:
> Note that your changes need to be backpatched into v13,
> because AFAICS this code is violating the FE/BE protocol
> right now --- it's just luck that libpq isn't moaning
> about extra CommandComplete messages. But I don't think
> we want to change the ps title b
On Wed, Sep 16, 2020 at 4:42 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > My main point here is that writing "CREATE TYPE typename AS DOMAIN" would
> > be expected, with the appropriate sub-specification, similar to "CREATE
> > TYPE typename AS RANGE".
>
> Well, that point seems entirely
On 2020-Sep-16, Tom Lane wrote:
> Daniel Gustafsson writes:
> > Not sure what pgindent is doing there, but it seems hard to address in the
> > generator.
>
> I think the issue is that pgindent believes "numeric" and "chr" are
> typedefs. (The regex code can be blamed for "chr", but I'm not qui
On Wed, Sep 16, 2020 at 4:42 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > My main point here is that writing "CREATE TYPE typename AS DOMAIN" would
> > be expected, with the appropriate sub-specification, similar to "CREATE
> > TYPE typename AS RANGE".
>
> Well, that point seems entirely
Daniel Gustafsson writes:
> The attached patch fixes the generation of sql_help.h and perl_opmask.h to
> make
> sure they conform to pgindent. Those were the only file I got diffs in after
> a
> pgindent run apart from fmgrprotos.h which gave the below:
Hmm, I seem to recall there were more wh
"David G. Johnston" writes:
> My main point here is that writing "CREATE TYPE typename AS DOMAIN" would
> be expected, with the appropriate sub-specification, similar to "CREATE
> TYPE typename AS RANGE".
Well, that point seems entirely invented. CREATE DOMAIN is in the
SQL standard:
:
Hi Simon,
On Thu, 17 Sep 2020 at 06:54, Simon Riggs wrote:
> Should pg_rusage_init(&ru0);
> be at the start of the REDO loop, since you only use it if we take that path?
Thanks for commenting.
I may be misunderstanding your words, but as far as I see it the
pg_rusage_init() is only called if we
On 2020-09-16 14:01:21 +1200, Thomas Munro wrote:
> On Wed, Sep 16, 2020 at 1:30 PM David Rowley wrote:
> > Thanks a lot for the detailed benchmark results and profiles. That was
> > useful. I've pushed both patches now. I did a bit of a sweep of the
> > comments on the 0001 patch before pushing
On 2020-Sep-16, Tom Lane wrote:
> Yeah, that works for me. It doesn't allow for having just one
> set_ps_display() call ahead of the switch, but that isn't that
> big a loss. We cannot merge the EndReplicationCommand calls to
> after the switch, because some of the cases don't want one here;
> s
Alvaro Herrera writes:
> On 2020-Sep-16, Tom Lane wrote:
>> I don't see an easy way to improve on it though. The only obvious
>> alternative would be to put another switch before the main one that
>> just fills a "const char *cmdtag" variable, but that seems ugly.
> The alternative of doing the
On Tue, Sep 15, 2020 at 3:48 PM Alexander Korotkov
wrote:
> Hi!
>
> I've skimmed through the thread and checked the patchset. Everything
> looks good, except one paragraph, which doesn't look completely clear.
>
> +
> + This emulates the functionality provided by
> +but sets the created
On 2020-Sep-16, Tom Lane wrote:
> This looks moderately reasonable to me. However, with the process
> title reporting I want to add, we're going to end up with a switch
> that looks like
>
> case T_IdentifySystemCmd:
> + set_ps_display("IDENTIFY_SYSTEM");
>
Thanx Tom and Amit for the effort.
Looking forward to try it out.
D.
-Original Message-
From: Tom Lane
Sent: 16. rujna 2020. 20:41
To: Amit Langote
Cc: Alvaro Herrera ; Domagoj Smoljanovic
; pgsql-hack...@postgresql.org
Subject: Re: pg_restore causing deadlocks on partitioned tables
On Tue, Sep 15, 2020 at 11:30 AM Tom Lane wrote:
> Pushed, thanks for looking.
I think that the Postgres 13 release notes should mention the
enhancement to contrib/amcheck made by Alexander's commit d114cc53.
I suggest something along the lines of: "Make the cross-level
verification checks perfo
> On 22 May 2020, at 11:29, Peter Eisentraut
> wrote:
> On 2020-05-20 15:56, Tom Lane wrote:
>> I wonder if we should make an effort to ensure
>> that our generated .h and .c files always satisfy pgindent.
>
> We should generally try to do that, if only so that they don't appear weird
> and ra
Hello Aya Iwata,
I like this patch, and I think we should have it. I have updated it, as
it had conflicts.
In 0002, I remove use of ftime(), because that function is obsolete.
However, with that change we lose printing of milliseconds in the trace
lines. I think that's not great, but I also thi
On Tue, Sep 8, 2020 at 2:20 PM Andres Freund wrote:
> This pattern seems like it'll get unwieldy with more than one barrier
> type. And won't flag "unhandled" barrier types either (already the case,
> I know). We could go for something like:
>
> while (flags != 0)
> {
> barrier_bit
On Wed, Sep 16, 2020 at 2:54 PM Simon Riggs wrote:
> I really like this patch, thanks for proposing it.
I'm pleased to be able to say that I agree completely with this
comment from Simon. :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, 10 Sep 2020 at 14:45, David Rowley wrote:
> I've also attached another tiny patch that I think is pretty useful
> separate from this. It basically changes:
>
> LOG: redo done at 0/D518FFD0
>
> into:
>
> LOG: redo done at 0/D518FFD0 system usage: CPU: user: 58.93 s,
> system: 0.74 s, ela
Robert Haas writes:
> OK. After some more study of the thread and some more experimentation,
> I came up with the attached. I'll go ahead and commit this if nobody
> objects.
This is OK by me.
regards, tom lane
Amit Langote writes:
> Updated patch attached.
Pushed with a little bit of fooling about. After looking at the
git history, I saw that the Assert we were wondering about used to
be just "Assert(constr)", and there were not run-time checks on
whether constr is null. That was changed when f0e4475
On Wed, Sep 16, 2020 at 11:48 AM Tom Lane wrote:
> Robert Haas writes:
> > Tom, I know that you often have strong feelings about the exact
> > wording and details of this kind of stuff, so if you feel moved to
> > commit something that is fine with me. If not, I will take my best
> > shot at it.
On Tue, Sep 15, 2020 at 2:26 PM Peter Eisentraut
wrote:
>
> On 2020-09-08 16:45, Julien Rouhaud wrote:
> > I usually agree with that approach, I'm just afraid that getting a
> > consensus on
> > the best way to do that will induce a lot of discussions, while this is
> > probably a corner case due
Alvaro Herrera writes:
> On 2020-Sep-15, Alvaro Herrera wrote:
>> I overlooked this in 2f9661311b83. From this perspective, I agree it
>> looks wrong. We still have to send *some* completion tag (the 'C'
>> message), but maybe we can invent a separate entry point in dest.c for
>> that -- EndRepl
On 2020-Sep-15, Alvaro Herrera wrote:
> I overlooked this in 2f9661311b83. From this perspective, I agree it
> looks wrong. We still have to send *some* completion tag (the 'C'
> message), but maybe we can invent a separate entry point in dest.c for
> that -- EndReplicationCommand() or some such
Attaching v6 patch, rebased because of a recent commit
3d65b0593c5578014f62e09d4008006f1783f64d. Please consider this for
further review.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
v6-0001-Detail-message-with-names-of-missing-columns-in-l.patch
Description: Binary
Amit Kapila writes:
> Thanks for the explanation. I have read your patch and it looks good to me.
Pushed, thanks for checking the patch.
regards, tom lane
Robert Haas writes:
> Tom, I know that you often have strong feelings about the exact
> wording and details of this kind of stuff, so if you feel moved to
> commit something that is fine with me. If not, I will take my best
> shot at it.
I'm not feeling terribly picky about it --- so it's all you
st 16. 9. 2020 v 17:08 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 16.09.2020 17:23, Adam Brusselback wrote:
>
> > From my point of view if will be very helpful if such > "PgExt Store"
> > will be available.
> > May be such resources already exists, but I do not >
On Wed, Sep 16, 2020 at 1:48 AM Ashutosh Sharma wrote:
> Attached is the patch with the changes suggested here. I've tried to
> use a normal heap table with (autovacuum = off) wherever possible.
> Please have a look and let me know for any other issues.
I think the comment needs some wordsmithing
On 16.09.2020 17:23, Adam Brusselback wrote:
> From my point of view if will be very helpful if such > "PgExt Store"
> will be available.
> May be such resources already exists, but I do not > know about them.
https://pgxn.org/
Thank you.
Shame on me, that I have forgot about it.
Actually
On Wed, Sep 16, 2020 at 4:17 PM Konstantin Knizhnik
wrote:
>
> On 16.09.2020 16:01, Michael Paquier wrote:
> > On Thu, Sep 10, 2020 at 02:09:11PM +0200, Daniel Gustafsson wrote:
> >> FWIW I would like to see fewer modules in contrib rather than gaining more.
> > Agreed here.
> > --
> > Michael
>
>
James McManus writes:
> However, when I try and use EXECUTE in the mvtgeom AS section of the script
> I get a syntax error on EXECUTE:
You need to convert the *entire* query into a string and apply EXECUTE
to that. You can't use EXECUTE as a part of a query.
regards, tom
> From my point of view if will be very helpful if such > "PgExt Store"
> will be available.
> May be such resources already exists, but I do not > know about them.
https://pgxn.org/
"Jonathan S. Katz" writes:
> My inclination is to leave the statement alone or use that 2nd proposal
> I listed upthread.
I'd go with the simplest wording. As you say, people running betas
are probably sufficiently versed in what to do that they don't need
the release announcement to tell them.
> On Tue, Sep 01, 2020 at 11:08:54PM +0200, Tomas Vondra wrote:
> On Tue, Sep 01, 2020 at 01:15:31PM +0200, Dmitry Dolgov wrote:
> > Hi,
> >
> > Better late than never, to follow up on the original thread [1] I would
> > like to
> > continue the discussion with the another version of the patch fo
I'm trying to develop a plpgsql function that would extract mapbox vector
tiles from a postgresql/post gis database. The database has multiple
geospatial tables, so I want the function to be able to take a table name
as a parameter.
I've gotten the function to work using hard coded table names. Di
On 16.09.2020 16:01, Michael Paquier wrote:
On Thu, Sep 10, 2020 at 02:09:11PM +0200, Daniel Gustafsson wrote:
FWIW I would like to see fewer modules in contrib rather than gaining more.
Agreed here.
--
Michael
The intention to limit the number of contrib modules seems to be obvious
becau
On 9/16/20 9:52 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Sep 16, 2020 at 2:34 PM Jonathan S. Katz
>> wrote:
>>> We've typically recommended doing the pg_upgrade since they may be
>>> coming from a version with a lower catversion. I can change "you will
>>> need" to "you may need"
Magnus Hagander writes:
> On Wed, Sep 16, 2020 at 2:34 PM Jonathan S. Katz
> wrote:
>> We've typically recommended doing the pg_upgrade since they may be
>> coming from a version with a lower catversion. I can change "you will
>> need" to "you may need" to be more accurate, but then that leads to
On Wed, Sep 16, 2020 at 3:06 PM Michael Paquier wrote:
>
> On Tue, Sep 15, 2020 at 10:46:56AM +0200, Julien Rouhaud wrote:
> > FWIW I'm fine with those news comments!
>
> Okay, I got again on this one today and finished by committing the
> patch as of 5423853.
Thanks Michael!
On Wed, Sep 16, 2020 at 2:02 PM Kyotaro Horiguchi
wrote:
>
> At Wed, 16 Sep 2020 10:05:32 +0530, Amit Kapila
> wrote in
> > On Wed, Sep 16, 2020 at 9:02 AM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Wed, 16 Sep 2020 08:33:06 +0530, Amit Kapila
> > > wrote in
> > > > On Wed, Sep 16, 2020 at 7
Hi Vignesh,
I've spent some time today looking at your new set of patches and I've
some thoughts and queries which I would like to put here:
Why are these not part of the shared cstate structure?
SerializeString(pcxt, PARALLEL_COPY_KEY_NULL_PRINT, cstate->null_print);
SerializeString(pcx
On Tue, Sep 15, 2020 at 10:46:56AM +0200, Julien Rouhaud wrote:
> FWIW I'm fine with those news comments!
Okay, I got again on this one today and finished by committing the
patch as of 5423853.
--
Michael
signature.asc
Description: PGP signature
On Thu, Sep 10, 2020 at 02:09:11PM +0200, Daniel Gustafsson wrote:
> FWIW I would like to see fewer modules in contrib rather than gaining more.
Agreed here.
--
Michael
signature.asc
Description: PGP signature
Hello,
Today I bumped into an issue with pg_rewind which is not 100% clear
where should be better fixed.
The first call of pg_rewind failed with the following message:
servers diverged at WAL location A76/39E55338 on timeline 132
could not open file
"/home/postgres/pgdata/pgroot/data/pg_wal/0
On Wed, Sep 16, 2020 at 2:34 PM Jonathan S. Katz
wrote:
> On 9/16/20 1:08 AM, Peter Eisentraut wrote:
> > On 2020-09-15 18:10, Jonathan S. Katz wrote:
> >> To upgrade to PostgreSQL 13 RC 1 from Beta 3 or an earlier version of
> >> PostgreSQL 13, you will need to use a strategy similar to upgradin
On 9/16/20 1:08 AM, Peter Eisentraut wrote:
> On 2020-09-15 18:10, Jonathan S. Katz wrote:
>> To upgrade to PostgreSQL 13 RC 1 from Beta 3 or an earlier version of
>> PostgreSQL 13, you will need to use a strategy similar to upgrading
>> between
>> major versions of PostgreSQL (e.g. `pg_upgrade` or
st 16. 9. 2020 v 11:36 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > st 9. 9. 2020 v 23:04 Justin Pryzby wrote:
> >
> > This seems to already hit a merge conflict (8febfd185).
> > Would you re-rebase ?
>
> Thanks. Sure, will post a rebased version soon.
>
> > On Tue, Sep 15, 2020 a
> On 16-Sep-2020, at 8:32 AM, Li Japin wrote:
>
> Thanks for clarifying the questions!
>
>> On Sep 15, 2020, at 12:41 PM, Bharath Rupireddy
>> wrote:
>>
>> I think we must ask few questions:
>>
>> 1. What's the major gain we get out of this? Is it that the time to
>> stream gets reduced o
The current Bloom index implementation only supports = operator, but states
in the documentation that it could be extended to handle array intersection
or union queries in future. As the original authors are hanging out in this
list, I would like to discuss what such implementation might be.
I jus
Thank you for your comment.
Please let me know if anyone has any other comments.
Regards,
Taiga Katayama
On 2020/09/10 21:09, Daniel Gustafsson wrote:
On 10 Sep 2020, at 07:54, Taiga KATAYAMA wrote:
We hope to be incorporated this extension into PostgreSQL as one of
contrib module, and wou
> st 9. 9. 2020 v 23:04 Justin Pryzby wrote:
>
> This seems to already hit a merge conflict (8febfd185).
> Would you re-rebase ?
Thanks. Sure, will post a rebased version soon.
> On Tue, Sep 15, 2020 at 08:42:40PM +0200, Pavel Stehule wrote:
>
> Maybe I found a another issue.
>
> create table fo
On Thu, Sep 10, 2020 at 6:57 PM Andrey V. Lepikhov
wrote:
> On 9/9/20 5:51 PM, Amit Langote wrote:
> > On Wed, Sep 9, 2020 at 6:42 PM Alexey Kondratov
> > wrote:
> >> And InitResultRelInfo() may set ri_usesMultiInsert to false by default,
> >> since it's used only by COPY now. Then you won't nee
At Wed, 16 Sep 2020 12:27:09 +0500, "Andrey M. Borodin"
wrote in
> I was thinking that machine epsilon is near 1e-300, but I was
> wrong. It's actually near 1e-15.
FWIW, the mantissa of double is effectively 52+1 bits, about 15.9
digits. so 1+(1e-16) is basically indistincitve from
1+(2e-16). A
Thank you very much.
I think that Vik Fearing's patch about "Implement for
window functions" is much clear, better and has a chance to be committed.
For me it's not important which patch will go into PostgreSQL, because it's
a much needed feature.
In mine patch, there is also a feature about usi
At Wed, 16 Sep 2020 10:05:32 +0530, Amit Kapila wrote
in
> On Wed, Sep 16, 2020 at 9:02 AM Kyotaro Horiguchi
> wrote:
> >
> > At Wed, 16 Sep 2020 08:33:06 +0530, Amit Kapila
> > wrote in
> > > On Wed, Sep 16, 2020 at 7:46 AM Kyotaro Horiguchi
> > > wrote:
> > By the way I'm not sure that act
On 16/09/2020 10:27, Andrey M. Borodin wrote:
Actually, I just want to understand what changes between v18 and v19
changed on-page order of items. I look into patch diff and cannot
figure it out. There are only logging changes. How this affects
scan?
The test was failing with v18 too.
- Heikki
On Thu, Mar 5, 2020 at 4:17 AM Krasiyan Andreev wrote:
> I have currently suspended development of this patch, based on it's
> review,
> but I will continue development of the other Oliver Ford's work about
> adding support of respect/ignore nulls
> for lag(),lead(),first_value(),last_value() and
Hi Bharath,
On Tue, Sep 15, 2020 at 11:49 PM Bharath Rupireddy
wrote:
>
> Few questions:
> 1. Was the run performed with default postgresql.conf file? If not,
> what are the changed configurations?
Yes, just default settings.
> 2. Are the readings for normal copy(190.891sec, mentioned by you
>
> 15 сент. 2020 г., в 22:07, Heikki Linnakangas написал(а):
>
> regression=# SELECT f1, f1 <-> '0,1' FROM point_tbl ORDER BY f1 <-> '0,1';
>f1 | ?column?
> ---+--
> (0,0) |1
> (1e-300,-1e-300) |1
97 matches
Mail list logo
