On Fri, Jun 11, 2021 at 8:14 PM Amit Kapila wrote:
>
> Also, I can take care of the below cosmetic issues before committing
> if we decide to do this for PG-14.
>
> Few cosmetic issues:
> ==
> 1. git diff --check shows
> src/bin/pg_basebackup/t/030_pg_recvlogical.pl:109: new blank
On Tue, 2021-06-15 at 04:59 +, David Fetter wrote:
> I thought about using the dual, but wasn't sure how many languages
> support it.
I think none of the languages for which we cater uses the dual.
But I guess you were joking, since the tests are not translated ...
> if (fail_count == 0
Hello Michaël,
I think we don't have to call doLog() before logAgg(). If we call doLog(),
we will count an extra transaction that is not actually processed because
accumStats() is called in this.
Yes, calling both is weird.
The motivation to call doLog is to catch up zeros on slow rates, so
On Tue, 15 Jun 2021 10:05:29 +0200 (CEST)
Fabien COELHO wrote:
>
> Hello Michaël,
>
> >> I think we don't have to call doLog() before logAgg(). If we call doLog(),
> >> we will count an extra transaction that is not actually processed because
> >> accumStats() is called in this.
> >
> > Yes, ca
At Fri, 11 Jun 2021 23:05:29 -0300, Ranier Vilela wrote
in
> Hi,
>
> Removing legitimate warnings can it be worth it?
>From what the warning comes from? And what is the exact message?
> -1 CAST can be wrong, when there is an invalid value defined
> (InvalidBucket, InvalidBlockNumber).
> I thi
On Tue, Jun 15, 2021 at 05:15:14PM +0900, Yugo NAGATA wrote:
> On Tue, 15 Jun 2021 10:05:29 +0200 (CEST) Fabien COELHO
> wrote:
> It was not a problem because --sampling-rate --aggregate-interval cannot be
> used at the same time.
Yep, you are right, thanks. I have missed that both options can
>> Wouldn't it be better to comment it like any other function?
>
>Sure. Attached.
Thank you for your revision.
I think this patch is good, so I will move it to ready for committer.
Best regards,
Shinya Kato
>> I don't see the need to extend the unit to YB.
>> What use case do you have in mind?
>
>Practical or no, I saw no reason not to support all defined units. I assume
>we’ll
>get to a need sooner or later. :)
Thank you for your reply!
Hmmm, I didn't think YB was necessary, but what do others thin
Attached a v3 which adds a boolean to distinguish recording vs flushing.
Better with the attachement… sorry for the noise.
--
Fabien.diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index d7479925cb..3b27ffebf8 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgb
From: Robert Haas
> Well, we're talking about running this commit routine from within
> CommitTransaction(), right? So I think it is in fact running in the
> server. And if that's so, then you have to worry about how to make it
> respond to interrupts. You can't just call some functions
> DBMSX_xa
Hi Kyotaro,
Thanks for taking a look.
Em ter., 15 de jun. de 2021 às 05:17, Kyotaro Horiguchi <
horikyota@gmail.com> escreveu:
> At Fri, 11 Jun 2021 23:05:29 -0300, Ranier Vilela
> wrote in
> > Hi,
> >
> > Removing legitimate warnings can it be worth it?
>
> From what the warning comes from
Em sex., 11 de jun. de 2021 às 19:49, Andres Freund
escreveu:
> Hi,
>
> On 2020-04-23 14:36:15 +0900, Kyotaro Horiguchi wrote:
> > At Thu, 23 Apr 2020 01:21:21 -0300, Ranier Vilela
> wrote in
> > > Em qua., 22 de abr. de 2020 às 23:27, Kyotaro Horiguchi <
> > > horikyota@gmail.com> escreveu:
Em seg., 14 de jun. de 2021 às 21:01, Ranier Vilela
escreveu:
> I took it a step further.
>
> Transactions
>
> HEAD patched
> 1000220710586781
> 1014616710388685
> 100489191059
> 10065764,333 10436275 3,5
On Mon, Jun 14, 2021 at 9:08 PM Robert Haas wrote:
>
> On Mon, Jun 14, 2021 at 2:32 AM Amit Kapila wrote:
> > Why do you think we don't need to check index AM functions? Say we
> > have an index expression that uses function and if its parallel safety
> > is changed then probably that also impact
On Tuesday, June 15, 2021 1:51 PM vignesh C wrote:
> > Attached the patch-set that addressed those two comments.
> > I also fixed the commit message a bit in the 2PC specific patch to HEAD.
> > No other changes.
> >
> > Please check.
>
> Thanks for the updated patches, the patch applies cleanly i
On Mon, Jun 14, 2021 at 12:06 PM Dilip Kumar wrote:
>
> On Mon, Jun 14, 2021 at 9:44 AM Dilip Kumar wrote:
> >
> > On Mon, Jun 14, 2021 at 8:34 AM Amit Kapila wrote:
> > >
> > > I think the test in this patch is quite similar to what Noah has
> > > pointed in the nearby thread [1] to be failing
Currently, CREATE DATABASE forces a checkpoint, then copies all the
files, then forces another checkpoint. The comments in the createdb()
function explain the reasons for this. The attached patch fixes this
problem by making CREATE DATABASE completely WAL-logged so that now we
can avoid checkpoints
On Tue, Jun 15, 2021 at 04:50:24PM +0530, Dilip Kumar wrote:
> Currently, CREATE DATABASE forces a checkpoint, then copies all the
> files, then forces another checkpoint. The comments in the createdb()
> function explain the reasons for this. The attached patch fixes this
> problem by making CREAT
On 6/15/21 2:16 AM, Kyotaro Horiguchi wrote:
> At Fri, 11 Jun 2021 10:46:45 -0400, Tom Lane wrote in
>> I think jacana uses msys[2?], so this likely indicates a problem
>> in path sanitization for the archive command. Andrew, any advice?
> Thanks for fixing it.
>
> # I haven't still succeed to
On 15/06/2021 14:20, Dilip Kumar wrote:
Design Idea:
-
First, create the target database directory along with the version
file and WAL-log this operation. Create the "relation map file" in
the target database and copy the content from the source database. For
this, we can use som
On Mon, Jun 14, 2021 at 3:47 PM Andrew Dunstan wrote:
> So, will you feel happier with this applied? I haven't tested it yet but
> I'm confident it will work.
I'm not all that unhappy now, but yeah, that looks like an improvement
to me. I'm still afraid that I will keep writing tests that blow up
On Tue, 15 Jun 2021 18:01:18 +0900
Michael Paquier wrote:
> On Tue, Jun 15, 2021 at 05:15:14PM +0900, Yugo NAGATA wrote:
> > On Tue, 15 Jun 2021 10:05:29 +0200 (CEST) Fabien COELHO
> > wrote:
> > It was not a problem because --sampling-rate --aggregate-interval cannot be
> > used at the same t
On Tue, Jun 15, 2021 at 5:34 PM Heikki Linnakangas wrote:
>
> On 15/06/2021 14:20, Dilip Kumar wrote:
> > Design Idea:
. Then
> > we can get the relfilenode of every file we need to copy, and prepare
> > a list of all such relfilenode.
>
> I guess that would work, but you could also walk the datab
On Tue, 15 Jun 2021 11:38:00 +0200 (CEST)
Fabien COELHO wrote:
>
> > Attached a v3 which adds a boolean to distinguish recording vs flushing.
I am fine with this version, but I think it would be better if we have a comment
explaining what "tx" is for.
Also, how about adding Assert(tx) instead
On Mon, Jun 14, 2021 at 4:14 PM Alexander Korotkov wrote:
> On Mon, Jun 14, 2021 at 3:50 PM Jonathan S. Katz wrote:
> > On 6/13/21 5:18 PM, Alexander Korotkov wrote:
> >
> > >> "Expands an array into a set of rows. The array's elements are read out
> > >> in storage order."
> > >>
> > >> If we tw
On Sun, Jun 13, 2021 at 2:48 PM Alexander Korotkov wrote:
> On Fri, Jun 11, 2021 at 11:16 PM Tom Lane wrote:
> >
> > Alexander Korotkov writes:
> > > What about "Range/Multirange Functions and Operators"?
> >
> > Better than a comma, I guess. Personally I didn't have a
> > problem with the form
út 15. 6. 2021 v 15:11 odesílatel Alexander Korotkov
napsal:
> On Sun, Jun 13, 2021 at 2:48 PM Alexander Korotkov
> wrote:
> > On Fri, Jun 11, 2021 at 11:16 PM Tom Lane wrote:
> > >
> > > Alexander Korotkov writes:
> > > > What about "Range/Multirange Functions and Operators"?
> > >
> > > Bett
Hi Alexander,
On Thu, May 20, 2021 at 11:13 PM Alexander Pyhalov
wrote:
>
> Hi.
>
> The attached patch allows pushing joins with function RTEs to PostgreSQL
> data sources.
> This makes executing queries like this
>
> create foreign table f_pgbench_accounts (aid int, bid int, abalance int,
> fill
Am I mistaken in thinking that this would allow CREATE DATABASE to run
inside a transaction block now, further reducing the DDL commands that are
non-transactional?
Looks quite useful to me. Can you please add this to the next commitfest?
On Wed, Jun 9, 2021 at 5:25 PM Alexander Pyhalov
wrote:
>
> Hi.
>
> This patch allows pushing case expressions to foreign servers, so that
> more types of updates could be executed directly.
>
> For example, without patch:
On Tue, 15 Jun 2021 at 21:24, wrote:
> Hmmm, I didn't think YB was necessary, but what do others think?
For me personally, without consulting Wikipedia, I know that Petabyte
comes after Terabyte and then I'm pretty sure it's Exabyte. After
that, I'd need to check.
Assuming I'm not the only pers
On Tue, 15 Jun 2021 at 05:24, wrote:
> >> I don't see the need to extend the unit to YB.
> >> What use case do you have in mind?
> >
> >Practical or no, I saw no reason not to support all defined units. I
> assume we’ll
> >get to a need sooner or later. :)
>
> Thank you for your reply!
> Hmmm, I
On 6/15/21 8:04 AM, Heikki Linnakangas wrote:
>
> Yeah, WAL-logging the contents of the source database would certainly
> be less weird than the current system. As Julien also pointed out, the
> question is, are there people using on "CREATE DATABASE foo TEMPLATE
> bar" to copy a large source dat
Alexander Korotkov writes:
> Pushed! Thanks to thread participants for raising this topic and
> review. I'll be around to resolve issues if any.
Buildfarm is pretty thoroughly unhappy. Did you do a "check-world"
before pushing?
regards, tom lane
In the NSS thread it was discussed (20210603210642.gf22...@momjian.us etc) that
we use SSL rather than TLS in the documentation, which is technically somewhat
incorrect. Consensus came to using SSL/TLS instead for referring to encrypted
connections. Since this isn't really limited to the NSS work
On Tue, Jun 15, 2021 at 7:05 AM Amit Kapila wrote:
> Okay, but I think if we go with your suggested model where whenever
> there is a change in parallel-safety of any function, we need to send
> the new invalidation then I think it won't matter whether the function
> is associated with index expre
On Tue, Jun 15, 2021 at 9:31 PM Andrew Dunstan wrote:
>
> Rather than use size, I'd be inclined to say use this if the source
> database is marked as a template, and use the copydir approach for
> anything that isn't.
Looks like a good approach.
Hi,
My use case is to create an isolated interface schema consisting of only
views and functions (possibly many schemas, for multi-tenancy or
multi-version), which has the minimal access exposure. To reduce the mental
and maintenance burden, I am inclined to create one role per interface
schema, i
Gee, I pasted the ending demonstration as html.
Re-pasting a text version.
--
┌
│ drop owned by owner;
│ drop role if exists owner, guest;
│
│ create role owner;
│ create role guest;
│
│ drop schema if exists s;
On Mon, 14 Jun 2021 10:57:07 +0200 (CEST)
Fabien COELHO wrote:
> > However, I found that conn_duration is calculated even when -C/--connect
> > is not specified, which is waste. SO we can remove this code as fixed in
> > the attached patch.
>
> I'm fine with the implied code simplification, but
On Mon, Jun 14, 2021 at 9:08 PM Robert Haas wrote:
>
> On Mon, Jun 14, 2021 at 2:32 AM Amit Kapila wrote:
>
> > Yeah, this could be one idea but I think even if we use pg_proc OID,
> > we still need to check all the rel cache entries to find which one
> > contains the invalidated OID and that cou
On Tue, Jun 15, 2021 at 8:31 AM Isaac Morland
wrote:
> On Tue, 15 Jun 2021 at 05:24, wrote:
>
>> >> I don't see the need to extend the unit to YB.
>> >> What use case do you have in mind?
>> >
>> >Practical or no, I saw no reason not to support all defined units. I
>> assume we’ll
>> >get to a n
On Tue, Jun 15, 2021 at 8:26 AM David Rowley wrote:
> On Tue, 15 Jun 2021 at 21:24, wrote:
> > Hmmm, I didn't think YB was necessary, but what do others think?
>
> For me personally, without consulting Wikipedia, I know that Petabyte
> comes after Terabyte and then I'm pretty sure it's Exabyte.
> On Thu, Mar 18, 2021 at 04:50:02PM +0100, Dmitry Dolgov wrote:
> > On Thu, Mar 18, 2021 at 09:38:09AM -0400, David Steele wrote:
> > On 1/5/21 10:51 AM, Zhihong Yu wrote:
> > >
> > > + int lastExprLenght = 0;
> > >
> > > Did you mean to name the variable lastExprLenghth ?
> > >
> > > w.
On Tue, Jun 15, 2021 at 09:37:11AM +0200, Laurenz Albe wrote:
> On Tue, 2021-06-15 at 04:59 +, David Fetter wrote:
> > I thought about using the dual, but wasn't sure how many languages
> > support it.
>
> I think none of the languages for which we cater uses the dual. But
> I guess you were
Greetings,
* Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> At Fri, 11 Jun 2021 16:08:33 +0900, Michael Paquier
> wrote in
> > On Fri, Jun 11, 2021 at 03:32:28PM +0900, Kyotaro Horiguchi wrote:
> > > I think cp can be an example as far as we explain the limitations. (On
> > > the other ha
On Wed, 16 Jun 2021 at 02:58, David Christensen
wrote:
> That said, it seems like having the code structured in a way that we can
> expand via adding an element to a table instead of the existing way it's
> written with nested if blocks is still a useful refactor, whatever we decide
> the cutof
Greetings,
* torikoshia (torikos...@oss.nttdata.com) wrote:
> On 2021-06-14 23:53, Mark Dilger wrote:
> >>On Jun 14, 2021, at 5:51 AM, torikoshia
> >>wrote:
> >>BTW, do these patches enable non-superusers to create user with
> >>bypassrls?
[...]
> >Do you believe that functionality should be adde
While working on some related issues I found that the wal receiver
tries to call walrcv_receive() loop
before replying the write/flush/apply LSN to wal senders in
XLogWalRcvSendReply(). It is possible
that walrcv_receive() loop receives and writes a lot of xlogs, so it
does not reply those LSN
info
On Tue, Jun 15, 2021 at 4:49 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Pushed! Thanks to thread participants for raising this topic and
> > review. I'll be around to resolve issues if any.
>
> Buildfarm is pretty thoroughly unhappy. Did you do a "check-world"
> before pushing?
Yes,
On Tue, Jun 15, 2021 at 07:53:26AM +0200, Peter Eisentraut wrote:
> On 15.06.21 07:37, Michael Paquier wrote:
> > > > Actually, I was just thinking that default yes/no/on/off stuff maybe
> > > > should be
> > > > defined to mean "lz4" rather than meaning pglz for "backwards
> > > > compatibility"
On Wed, Jun 9, 2021 at 9:24 PM John Naylor wrote:
> 3) It actually improves the existing exhaustive search, because the
> complexity of the join order problem depends on the query shape: a "chain"
> shape (linear) vs. a "star" shape (as in star schema), for the most common
> examples. The size
I propose to change some defaults:
log_autovacuum_min_duration = 0
log_checkpoints = on
log_lock_waits = on (and log_recovery_conflict_waits too?)
log_temp_files = 128kB
Note that pg_regress does this:
| fputs("\n# Configuration added by pg_regress\n\n", pg_conf);
| fputs("log_autovacuum_min_dura
On Tue, Jun 15, 2021 at 11:33:10AM -0400, Stephen Frost wrote:
>
> The requirements are things which are learned over years and changes
> over time. Trying to document them and keep up with them would be a
> pretty serious project all on its own. There are external projects who
> spend serious t
Hi.
Ashutosh Bapat писал 2021-06-15 16:24:
Looks quite useful to me. Can you please add this to the next
commitfest?
Addded to commitfest. Here is an updated patch version.
--
Best regards,
Alexander Pyhalov,
Postgres ProfessionalFrom 80d60eb9b1630ee55d1825964e0e976ae6c289a1 Mon Sep 17 00:0
Robert Haas writes:
> Oh, maybe I'm the one who misunderstood...
So, it's well over a year later, and so far as I can see exactly
nothing has been done about snapshot_too_old's problems.
I never liked that feature to begin with, and I would be very
glad to undertake the task of ripping it out.
Robert Haas writes:
> One idea I just ran across in
> https://15721.courses.cs.cmu.edu/spring2020/papers/22-costmodels/p204-leis.pdf
> is to try to economize by skipping consideration of bushy plans. We
> could start doing that when some budget is exceeded, similar to what
> you are proposing here
Justin Pryzby writes:
> I propose to change some defaults:
> log_autovacuum_min_duration = 0
> log_checkpoints = on
> log_lock_waits = on (and log_recovery_conflict_waits too?)
> log_temp_files = 128kB
Why?
Based on reports that I see, some quite large percentage of Postgres
DBAs never look at t
>From time to time, someone tells me that they've configured
enable_nestloop=false on postgresql.conf, which is a pretty bad idea
since there are a significant number of cases where such plans are the
only reasonable way of executing some query. However, it's no great
secret that PostgreSQL's optim
Hi,
On 2021-06-15 12:51:28 -0400, Tom Lane wrote:
> Robert Haas writes:
> > Oh, maybe I'm the one who misunderstood...
>
> So, it's well over a year later, and so far as I can see exactly
> nothing has been done about snapshot_too_old's problems.
>
> I never liked that feature to begin with, an
On Tue, Jun 15, 2021 at 9:51 AM Tom Lane wrote:
> So, it's well over a year later, and so far as I can see exactly
> nothing has been done about snapshot_too_old's problems.
FWIW I think that the concept itself is basically reasonable. The
implementation is very flawed, though, so it hardly enter
On Tue, Jun 15, 2021 at 1:00 PM Tom Lane wrote:
> Still, I take your point that maybe we could ratchet down the cost of
> exhaustive search by skimping on this part. Maybe it'd work to skip
> bushy so long as we'd found at least one left-deep or right-deep path
> for the current rel.
Yes, that s
Alexander Korotkov writes:
> I did run "check-world", but it passed for me. Probably the same
> reason it passed for some buildfarm animals...
The only buildfarm animals that have passed since this went in
are the ones that don't run the pg_dump or pg_upgrade tests.
It looks to me like the prox
On 2021-Jun-15, Tom Lane wrote:
> It looks to me like the proximate problem is that you should
> have taught pg_dump to skip these new auto-generated functions.
> However, I fail to see why we need auto-generated functions
> for this at all. Couldn't we have done it with one polymorphic
> functio
Hi,
On 2021-06-15 07:40:46 -0300, Ranier Vilela wrote:
> memcpy would not suffer from it?
It'd not be correct for short sqlstates - you'd read beyond the end of
the source buffer. There are cases of it in the ecpg code.
Greetings,
Andres Freund
Alvaro Herrera writes:
> On 2021-Jun-15, Tom Lane wrote:
>> I think this ought to be reverted and reviewed more carefully.
> It seems to me that removing the cast-to-range[] is a sufficient fix,
> and that we can do with only the unnest part for pg14; the casts can be
> added in 15 (if at all).
Andres Freund writes:
> On 2021-06-15 07:40:46 -0300, Ranier Vilela wrote:
>> memcpy would not suffer from it?
> It'd not be correct for short sqlstates - you'd read beyond the end of
> the source buffer. There are cases of it in the ecpg code.
What's a "short SQLSTATE"? They're all five charac
On 6/15/21 1:52 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> On 2021-Jun-15, Tom Lane wrote:
>>> I think this ought to be reverted and reviewed more carefully.
>
>> It seems to me that removing the cast-to-range[] is a sufficient fix,
>> and that we can do with only the unnest part for pg14; t
Peter Geoghegan writes:
> On Tue, Jun 15, 2021 at 9:51 AM Tom Lane wrote:
>> So, it's well over a year later, and so far as I can see exactly
>> nothing has been done about snapshot_too_old's problems.
> I propose that the revert question be explicitly timeboxed. If the
> issues haven't been fix
On Tue, Jun 15, 2021 at 10:09 AM Robert Haas wrote:
> How to do that is not very clear. One very simple thing we could do
> would be to introduce enable_nestloop=parameterized or
> enable_parameterized_nestloop=false. That is a pretty blunt instrument
> but the authors of the paper seem to have do
On Tue, Jun 15, 2021 at 12:15 PM Robert Haas wrote:
>
> On Wed, Jun 9, 2021 at 9:24 PM John Naylor
wrote:
> > 3) It actually improves the existing exhaustive search, because the
complexity of the join order problem depends on the query shape: a "chain"
shape (linear) vs. a "star" shape (as in sta
On Tue, Jun 15, 2021 at 11:01 AM Tom Lane wrote:
> The goal I have in mind is for snapshot_too_old to be fixed or gone
> in v15. I don't feel a need to force the issue sooner than that, so
> there's plenty of time for someone to step up, if anyone wishes to.
Seems more than reasonable to me. A y
Greetings,
* Julien Rouhaud (rjuju...@gmail.com) wrote:
> On Tue, Jun 15, 2021 at 11:33:10AM -0400, Stephen Frost wrote:
> > The requirements are things which are learned over years and changes
> > over time. Trying to document them and keep up with them would be a
> > pretty serious project all
On 6/15/21 12:06 PM, Alexander Korotkov wrote:
> On Tue, Jun 15, 2021 at 4:49 PM Tom Lane wrote:
>> Alexander Korotkov writes:
>>> Pushed! Thanks to thread participants for raising this topic and
>>> review. I'll be around to resolve issues if any.
>> Buildfarm is pretty thoroughly unhappy.
On Tue, Jun 15, 2021 at 8:18 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > I did run "check-world", but it passed for me. Probably the same
> > reason it passed for some buildfarm animals...
>
> The only buildfarm animals that have passed since this went in
> are the ones that don't run th
On 6/15/21 1:52 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> On 2021-Jun-15, Tom Lane wrote:
>>> I think this ought to be reverted and reviewed more carefully.
>> It seems to me that removing the cast-to-range[] is a sufficient fix,
>> and that we can do with only the unnest part for pg14; th
Hi,
On 2021-06-15 13:53:08 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-06-15 07:40:46 -0300, Ranier Vilela wrote:
> >> memcpy would not suffer from it?
>
> > It'd not be correct for short sqlstates - you'd read beyond the end of
> > the source buffer. There are cases of it in the
Hi,
On 2021-06-14 22:57:08 -0400, Tom Lane wrote:
> This is a followup to the conversation at [1], in which we speculated
> about constraining the isolationtester's behavior by annotating the
> specfiles, in order to eliminate common buildfarm failures such as [2]
> and reduce the need to use long
Andres Freund writes:
> On 2021-06-14 22:57:08 -0400, Tom Lane wrote:
>> This is still WIP to some extent, as I've not spent much time looking at
>> specfiles other than the ones with big delays; there may be additional
>> improvements possible in some places. Also, I've not worried about
>> whet
On Tue, Jun 15, 2021 at 12:51 PM Tom Lane wrote:
> So, it's well over a year later, and so far as I can see exactly
> nothing has been done about snapshot_too_old's problems.
Progress has been pretty limited, but not altogether nonexistent.
55b7e2f4d78d8aa7b4a5eae9a0a810601d03c563 fixed, or at le
On 6/14/21 10:57 PM, Tom Lane wrote:
> This is a followup to the conversation at [1], in which we speculated
> about constraining the isolationtester's behavior by annotating the
> specfiles, in order to eliminate common buildfarm failures such as [2]
> and reduce the need to use long delays to s
On Tue, Jun 15, 2021 at 2:04 PM Peter Geoghegan wrote:
> I guess that there is a hesitation to not introduce heuristics like
> this because it doesn't fit into some larger framework that captures
> risk -- it might be seen as an ugly special case. But isn't this
> already actually kind of special,
Em ter., 15 de jun. de 2021 às 15:48, Andres Freund
escreveu:
> Hi,
>
> On 2021-06-15 13:53:08 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2021-06-15 07:40:46 -0300, Ranier Vilela wrote:
> > >> memcpy would not suffer from it?
> >
> > > It'd not be correct for short sqlstates - you
Robert Haas writes:
> My general point here is that I would like to know whether we have a
> finite number of reasonably localized bugs or a three-ring disaster
> that is unrecoverable no matter what we do. Andres seems to think it
> is the latter, and I *think* Peter Geoghegan agrees, but I think
On Tue, Jun 15, 2021 at 12:31 PM Robert Haas wrote:
> Yes, I think it is. Reading the paper really helped me crystallize my
> thoughts about this, because when I've studied the problems myself, I
> came, as you postulate here, to the conclusion that there's a lot of
> stuff the planner does where
On Tue, Jun 15, 2021 at 12:49 PM Tom Lane wrote:
> Robert Haas writes:
> > My general point here is that I would like to know whether we have a
> > finite number of reasonably localized bugs or a three-ring disaster
> > that is unrecoverable no matter what we do. Andres seems to think it
> > is t
On Tue, Jun 15, 2021 at 12:17 PM Robert Haas wrote:
> My general point here is that I would like to know whether we have a
> finite number of reasonably localized bugs or a three-ring disaster
> that is unrecoverable no matter what we do. Andres seems to think it
> is the latter, and I *think* Pet
On Wed, Apr 1, 2020 at 4:59 PM Andres Freund wrote:
> The primary issue here is that there is no TestForOldSnapshot() in
> heap_hot_search_buffer(). Therefore index fetches will never even try to
> detect that tuples it needs actually have already been pruned away.
This is still true, right? Nobo
Peter Geoghegan writes:
> What I had in mind was this: a committer adopting the feature
> themselves. The committer would be morally obligated to maintain the
> feature on an ongoing basis, just as if they were the original
> committer. This seems like the only sensible way of resolving this
> iss
On Tue, Jun 15, 2021 at 09:53:06PM +0900, Yugo NAGATA wrote:
> I am fine with this version, but I think it would be better if we have a
> comment
> explaining what "tx" is for.
>
> Also, how about adding Assert(tx) instead of using "else if (tx)" because
> we are assuming that tx is always true w
I've been spending a lot of time looking at isolationtester results
over the past couple of days, and gotten really annoyed at how poorly
it formats query results. In particular, any column heading or value
that is 15 characters or longer is not separated from the next column,
rendering the output
On 2021-Jun-15, Tom Lane wrote:
> I've been spending a lot of time looking at isolationtester results
> over the past couple of days, and gotten really annoyed at how poorly
> it formats query results. In particular, any column heading or value
> that is 15 characters or longer is not separated f
Alvaro Herrera writes:
> On 2021-Jun-15, Tom Lane wrote:
>> If we wanted to buy into that, I'd think about discarding this
>> ad-hoc code altogether in favor of using one of libpq's fe-print.c
>> routines. But I'm not really sure that the small legibility gains
>> that would result are worth mass
On Wed, 2021-06-16 at 00:08 +0200, Daniel Gustafsson wrote:
> > On 15 Jun 2021, at 00:15, Jacob Champion wrote:
> > Attached is a quick patch; does it work on your machine?
>
> It does, thanks! I've included it in the attached v37 along with a few tiny
> non-functional improvements in comment sp
On Wed, 16 Jun 2021 at 05:09, Robert Haas wrote:
> How to do that is not very clear. One very simple thing we could do
> would be to introduce enable_nestloop=parameterized or
> enable_parameterized_nestloop=false. That is a pretty blunt instrument
> but the authors of the paper seem to have done
On Tue, Jun 15, 2021 at 5:00 PM David Rowley wrote:
> I don't really think we should solve this by having nodeNestloop.c
> fall back on hashing when the going gets tough. Overloading our nodes
> that way is not a sustainable thing to do. I'd rather see the
> executor throw the plan back at the p
Hi,
On 2021-06-15 15:17:05 -0400, Robert Haas wrote:
> But that's not clear to me. I'm not clear how exactly how many
> problems we know about and need to fix in order to keep the feature,
> and I'm also not clear how deep the hole goes. Like, if we need to get
> a certain number of specific bugs
On Tue, Jun 15, 2021 at 11:14:56AM -0500, Justin Pryzby wrote:
> You're right, I hadn't though this through all the way.
> There's precedent if the default is non-static (wal_sync_method).
>
> But I think yes/on/true/1 should be a compatibility alias for a static thing,
> and then the only option
On Tue, Jun 15, 2021 at 02:28:04PM -0400, Stephen Frost wrote:
>
> * Julien Rouhaud (rjuju...@gmail.com) wrote:
> > On Tue, Jun 15, 2021 at 11:33:10AM -0400, Stephen Frost wrote:
> >
> > The fact that this is such a complex problem is the very reason why we
> > should
> > spend a lot of energy d
On Wed, 16 Jun 2021 at 12:11, Peter Geoghegan wrote:
> Whether or not we throw the plan back at the planner or "really change
> our minds at execution time" seems like a distinction without a
> difference.
What is "really change our minds at execution time"? Is that switch
to another plan withou
1 - 100 of 133 matches
Mail list logo
