Michaël-san, Yugo-san,
I am fine with this version, but I think it would be better if we have
a comment explaining what "tx" is for.
Yes. Done.
Also, how about adding Assert(tx) instead of using "else if (tx)" because
we are assuming that tx is always true when agg_interval is not used, rig
On Mon, Jun 14, 2021 at 6:18 PM Amit Kapila wrote:
>
> On Sat, Jun 12, 2021 at 9:12 PM Tom Lane wrote:
> >
> > So far as I can find, just about everyplace that deals with replication
> > connections has slipshod error reporting. An example from worker.c is
> >
> > LogRepWorkerWalRcvConn
On Tue, Jun 15, 2021 at 11:24 PM Noah Misch wrote:
> When I say "some hackers", I don't mean that specific people think such
> thoughts right now. I'm saying that the expected cost of future cooperation
> with the feature is nonzero, and bugs in the feature raise that cost.
I see.
> > > A hacke
On Wed, Jun 16, 2021 at 03:27:21PM +0900, Kyotaro Horiguchi wrote:
>
> If we are willing to maintain the two methods.
> Couldn't we just skip the checkpoints if the database is known to
> "clean", which means no page has been loaded for the database since
> startup? We can use the "template" mark
At Tue, 15 Jun 2021 22:07:32 +0800, Julien Rouhaud wrote
in
> 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.
>
> Lo
No change yet, just posting a rebase to keep cfbot happy.
One thing I'm wondering about is whether it'd be possible, and if so,
a good idea, to make a kind of tiny reusable cache replacement
algorithm, something modern, that can be used to kill several birds
with one stone (SLRUs, this object pool
On Tue, Jun 15, 2021 at 10:47:45PM -0700, Peter Geoghegan wrote:
> On Tue, Jun 15, 2021 at 9:59 PM Noah Misch wrote:
> > Hackers are rather wise, but the variety of PostgreSQL use is enormous. We
> > see that, among other ways, when regression fixes spike in each vN.1. The
> > $SUBJECT feature w
On Tue, Jun 15, 2021 at 3:21 AM Jeff Davis wrote:
>
> On Mon, 2021-06-14 at 13:13 -0400, Robert Haas wrote:
> > I'm happy to hear other opinions, but I think I would be inclined to
> > vote in favor of #1 and/or #2 but against #3.
>
> What about upgrading it to, say, LOG? It seems like it would ha
On Mon, Mar 15, 2021 at 1:09 PM Thomas Munro wrote:
> On Sun, Mar 14, 2021 at 5:03 PM Zhihong Yu wrote:
> > + * Remove duplicates from an array. Return the new size.
> > + */
> > +ST_SCOPE size_t
> > +ST_UNIQUE(ST_ELEMENT_TYPE *array,
> >
> > The array is supposed to be sorted, right ?
> > The c
On Tue, Jun 15, 2021 at 9:59 PM Noah Misch wrote:
> Hackers are rather wise, but the variety of PostgreSQL use is enormous. We
> see that, among other ways, when regression fixes spike in each vN.1. The
> $SUBJECT feature was born in response to a user experience; a lack of hacker
> interest doe
On Wed, Jun 16, 2021 at 01:17:11AM -0400, Stephen Frost wrote:
>
> The archive command is technically invoked using the shell, but the
> interpretation of the exit code, for example, is only discussed in the C
> code, but it’s far from the only consideration that someone developing an
> archive co
On Tue, Jun 15, 2021 at 8:11 PM Amit Kapila wrote:
>
> 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 entri
On Tue, Jun 15, 2021 at 7:31 PM Robert Haas wrote:
>
> 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'
At Tue, 15 Jun 2021 07:54:49 -0400, Andrew Dunstan wrote
in
>
> 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. Andr
Greetings,
On Tue, Jun 15, 2021 at 23:21 Julien Rouhaud wrote:
> On Tue, Jun 15, 2021 at 11:00:57PM -0400, Stephen Frost wrote:
> >
> > As I suggested previously- this is similar to the hooks that we provide.
> We
> > don’t extensively document them because if you’re writing an extension
> > whi
On Tue, Jun 15, 2021 at 02:32:11PM -0700, Peter Geoghegan wrote:
> 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 o
On Wed, Jun 16, 2021 at 01:10:16PM +0900, Kyotaro Horiguchi wrote:
>
> I agree to Julien, however, I want to discuss (also) on what to do for
> 14 now. If we decide not to touch the document for the version. that
> discussion would end. What do you think about that? I think it's
> impossible to
At Wed, 16 Jun 2021 11:20:55 +0800, Julien Rouhaud wrote
in
> On Tue, Jun 15, 2021 at 11:00:57PM -0400, Stephen Frost wrote:
> >
> > As I suggested previously- this is similar to the hooks that we provide. We
> > don’t extensively document them because if you’re writing an extension
> > which u
On Tue, Jun 15, 2021 at 09:43:31PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-06-15 19:26:25 -0400, Tom Lane wrote:
> >> Going forward it wouldn't be a problem, but back-patching isolation
> >> test cases might find it annoying. On the other hand, my nearby
> >> patch to improve i
On Tuesday, June 15, 2021 10:01 PM Robert Haas wrote:
> On Tue, Jun 15, 2021 at 7:05 AM Amit Kapila wrote:
> > Yeah, dealing with partitioned tables is tricky. I think if we don't
> > want to check upfront the parallel safety of all the partitions then
> > the other option as discussed could be t
On Tue, Jun 15, 2021 at 11:00:57PM -0400, Stephen Frost wrote:
>
> As I suggested previously- this is similar to the hooks that we provide. We
> don’t extensively document them because if you’re writing an extension
> which uses a hook, you’re going to be (or should be..) reading the code too.
I
On Tue, Jun 15, 2021 at 5:00 PM David Rowley wrote:
> Most of the time when I see that happen it's down to either the
> selectivity of some correlated base-quals being multiplied down to a
> number low enough that we clamp the estimate to be 1 row. The other
> case is similar, but with join qual
At Wed, 16 Jun 2021 12:04:03 +0900 (JST), Kyotaro Horiguchi
wrote in
> Ok, if we follow the direction that we are responsible for ensuring
> that every user has reliable backups, I don't come up with proper
> description about that.
>
> We could list several "requirement" like "do sync after co
Thanks for the opinions.
At Tue, 15 Jun 2021 11:33:10 -0400, Stephen Frost wrote in
> 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 wro
Greetings,
On Tue, Jun 15, 2021 at 21:11 Julien Rouhaud wrote:
> 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 compl
>> I had not really looked at the patch, but if there's a cleanup portion to
>> the same
>> patch as you're adding the YB too, then maybe it's worth separating those out
>> into another patch so that the two can be considered independently.
>
> I agree with this opinion. It seems to me that we
>I had not really looked at the patch, but if there's a cleanup portion to the
>same
>patch as you're adding the YB too, then maybe it's worth separating those out
>into another patch so that the two can be considered independently.
I agree with this opinion. It seems to me that we should think a
On Tue, Jun 15, 2021 at 6:15 PM David Rowley wrote:
> 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
Andres Freund writes:
> On 2021-06-15 19:26:25 -0400, Tom Lane wrote:
>> Going forward it wouldn't be a problem, but back-patching isolation
>> test cases might find it annoying. On the other hand, my nearby
>> patch to improve isolation test stability is already going to create
>> issues of that
On Wed, Jun 16, 2021 at 7:17 AM Robert Haas wrote:
> Progress has been pretty limited, but not altogether nonexistent.
> 55b7e2f4d78d8aa7b4a5eae9a0a810601d03c563 fixed, or at least seemed to
> fix, the time->XID mapping, which is one of the main things that
> Andres said was broken originally. Als
Hi,
On 2021-06-15 19:26:25 -0400, Tom Lane wrote:
> Going forward it wouldn't be a problem, but back-patching isolation
> test cases might find it annoying. On the other hand, my nearby
> patch to improve isolation test stability is already going to create
> issues of that sort. (Unless, dare I
Andres Freund writes:
> Only halfway related: I wonder if we should remove the automatic
> permutation stuff - it's practically never useful. Probably not worth
> changing...
Where it is useful, it saves a lot of error-prone typing ...
> Minor suggestion: I think the folliwing would be a bit eas
Hi,
Only halfway related: I wonder if we should remove the automatic
permutation stuff - it's practically never useful. Probably not worth
changing...
On 2021-06-15 17:09:00 -0400, Tom Lane wrote:
> +The general form of a permutation entry is
> +
> + "step_name" [ ( marker [ , marker ... ] )
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
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 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
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 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
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 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
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 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
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 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
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 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
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 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: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
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
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
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,
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 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
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
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
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
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
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 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.
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 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
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 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
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 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
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
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).
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
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
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 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
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
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
>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
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
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
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.
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
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
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 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
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 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,
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
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
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,
* 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 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
> 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 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 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 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 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
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;
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
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.
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
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
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
1 - 100 of 133 matches
Mail list logo
