Julien Rouhaud writes:
> On Wed, Apr 07, 2021 at 11:33:20PM -0700, Andres Freund wrote:
>> Nothing special, really. Surprised the BF doesn't see it:
> Is think this is because the buildfarm client is running installcheck for the
> contribs rather than check, and pg_stat_statements/Makefile has:
>
On Thu, 8 Apr 2021 at 05:54, Tomas Vondra wrote:
> I only ran that with a single client, the machine only has 4 cores and
> this should not be related to concurrency, so 1 client seems fine. The
> average of 10 runs, 15 seconds each look like this:
Thanks for running these tests. The reason I a
2021年4月8日(木) 15:04 Fujii Masao :
>
> On 2021/04/08 13:43, Kohei KaiGai wrote:
> > In case when a local table (with no children) has same contents,
> > TRUNCATE command
> > witll remove the entire table contents.
>
> But if there are local child tables that inherit the local parent table, and
> TRU
On Wed, Apr 7, 2021 at 10:37 PM vignesh C wrote:
> > I think, we can also have validate_publication option allowed for
> > ALTER SUBSCRIPTION SET PUBLICATION and REFRESH PUBLICATION commands
> > with the same behaviour i.e. error out when specified publications
> > don't exist in the publisher. Th
On Wed, Apr 07, 2021 at 11:33:20PM -0700, Andres Freund wrote:
> Hi,
>
> On 2021-04-08 02:05:25 -0400, Tom Lane wrote:
> > So far the buildfarm seems to be turning green after b3ee4c503 ...
> > so I wonder what extra condition is needed to cause the failure
> > Andres is seeing.
>
> Nothing speci
Hi,
On 2021-04-08 01:41:40 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Independent of this patch, it might be a good idea to have
> > ExecInitParallelPlan() be robust against NULL querystrings. Places like
> > executor_errposition() are certainly trying to be...
>
> FWIW, I think the long
Hi,
On 2021-04-08 02:05:25 -0400, Tom Lane wrote:
> So far the buildfarm seems to be turning green after b3ee4c503 ...
> so I wonder what extra condition is needed to cause the failure
> Andres is seeing.
Nothing special, really. Surprised the BF doesn't see it:
andres@awork3:~/build/postgres/de
Julien Rouhaud writes:
> On Wed, Apr 07, 2021 at 10:27:59PM -0700, Andres Freund wrote:
>> One holdup was that
>> check-world didn't succeed with force_parallel_mode=regress even after
>> the fix - but that turned out to be the fault of
Move pg_stat_statements query jumbling to core.
> Yep,
On 2021/04/08 13:43, Kohei KaiGai wrote:
In case when a local table (with no children) has same contents,
TRUNCATE command
witll remove the entire table contents.
But if there are local child tables that inherit the local parent table, and TRUNCATE
ONLY is executed, only the contents in th
On 2021-Apr-07, Alvaro Herrera wrote:
> However, I just noticed there is a huge problem, which is that the new
> code in relation_needs_vacanalyze() is doing find_all_inheritors(), and
> we don't necessarily have a snapshot that lets us do that. While adding
> a snapshot acquisition at that spot
On Thu, Apr 8, 2021 at 9:42 AM Bharath Rupireddy
wrote:
>
> On Thu, Apr 8, 2021 at 8:44 AM Amit Kapila wrote:
> >
> > On Wed, Apr 7, 2021 at 7:12 PM Bharath Rupireddy
> > wrote:
> > >
> > > On Wed, Apr 7, 2021 at 3:30 PM Amit Kapila
> > > wrote:
> > > >
> > > > During recent developments in th
On Wed, Apr 07, 2021 at 10:27:59PM -0700, Andres Freund wrote:
>
> One holdup was that
> check-world didn't succeed with force_parallel_mode=regress even after
> the fix - but that turned out to be the fault of
>
> commit 5fd9dfa5f50e4906c35133a414ebec5b6d518493 (HEAD)
> Author: Bruce Momjian
>
Andres Freund writes:
> Independent of this patch, it might be a good idea to have
> ExecInitParallelPlan() be robust against NULL querystrings. Places like
> executor_errposition() are certainly trying to be...
FWIW, I think the long-term drift of things is definitely that
we want to have the qu
On Thu, Apr 8, 2021 at 1:54 PM David Rowley wrote:
> On Thu, 8 Apr 2021 at 15:32, Amit Langote wrote:
> > There's 10-20% improvement in this case too for various partition
> > counts, which really has more to do with 86dc90056 than the work done
> > here.
>
> I'm not sure of the exact query you'r
Hi,
On 2021-04-08 01:16:02 -0400, Tom Lane wrote:
> Michael Paquier writes:
> > On Wed, Apr 07, 2021 at 04:22:17PM -0400, Tom Lane wrote:
> >> Buildfarm suggests this has some issues under force_parallel_mode.
> >> I'm wondering about missed fields in outfuncs/readfuncs, or the like.
>
> > The pr
On 4/8/21 8:13 AM, Tom Lane wrote:
I wrote:
Peter Eisentraut writes:
Can we move forward with this?
We could just push the change and see what happens. But I was thinking
more in terms of doing that early in the v15 cycle. I remain skeptical
that we need a near-term fix.
To make sure we
On 2021-Apr-07, Alvaro Herrera wrote:
> OK, I bit the bullet and re-did the logic in the way I had proposed
> earlier in the thread: do the propagation on the collector's side, by
> sending only the list of ancestors: the collector can read the tuple
> change count by itself, to add it to each anc
Michael Paquier writes:
> On Wed, Apr 07, 2021 at 04:22:17PM -0400, Tom Lane wrote:
>> Buildfarm suggests this has some issues under force_parallel_mode.
>> I'm wondering about missed fields in outfuncs/readfuncs, or the like.
> The problem looks a bit more fundamental to me, as there seems to be
On Thu, 8 Apr 2021 at 15:32, Amit Langote wrote:
> There's 10-20% improvement in this case too for various partition
> counts, which really has more to do with 86dc90056 than the work done
> here.
I'm not sure of the exact query you're running, but I imagine the
reason that it wasn't that slow wi
2021年4月8日(木) 11:44 Fujii Masao :
>
> On 2021/04/08 10:56, Kohei KaiGai wrote:
> > 2021年4月8日(木) 4:19 Fujii Masao :
> >>
> >> On 2021/04/06 21:06, Kazutaka Onishi wrote:
> >>> Thank you for checking v13, and here is v14 patch.
> >>>
> 1) Are we using all of these macros? I see that we are settin
On Wed, Apr 7, 2021 at 6:52 PM Bharath Rupireddy
wrote:
>
> On Wed, Apr 7, 2021 at 6:04 PM Ashutosh Bapat
> wrote:
> > At best CREATE SEQUENCE START ... RESTART ... can be a shorthand
> > for CREATE SEQUENCE ... START; ALTER SEQUENCE ... RESTART run back to
> > back. So it looks useful but i
On Wed, Apr 07, 2021 at 02:12:11PM -0400, Bruce Momjian wrote:
>
> Patch applied. I am ready to adjust this with any improvements people
> might have. Thank you for all the good feedback we got on this, and I
> know many users have waited a long time for this feature.
Thanks a lot Bruce and eve
On Thu, Apr 8, 2021 at 8:44 AM Amit Kapila wrote:
>
> On Wed, Apr 7, 2021 at 7:12 PM Bharath Rupireddy
> wrote:
> >
> > On Wed, Apr 7, 2021 at 3:30 PM Amit Kapila wrote:
> > >
> > > During recent developments in the vacuum, it has been noticed [1] that
> > > parallel vacuum workers don't use any
Hi,
On 2021-04-07 13:32:18 -0700, Andres Freund wrote:
> While working on this I found a, somewhat substantial, issue:
>
> When the primary is idle, on the standby logical decoding via walsender
> will typically not process the records until further WAL writes come in
> from the primary, or until
On Thu, Apr 8, 2021 at 3:02 AM Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Apr 7, 2021 at 12:34 PM Tom Lane wrote:
> >> Indeed, that's a pretty impressive comparison.
>
> > +1. That looks like a big improvement.
>
> > In a vacuum, you'd hope that partitioning a table would make things
> >
On Wed, Apr 07, 2021 at 04:22:17PM -0400, Tom Lane wrote:
> Buildfarm suggests this has some issues under force_parallel_mode.
> I'm wondering about missed fields in outfuncs/readfuncs, or the like.
The problem looks a bit more fundamental to me, as there seems to be
some confusion with the concep
On 2021-Apr-07, Bruce Momjian wrote:
> On Thu, Apr 8, 2021 at 10:38:08AM +0800, Julien Rouhaud wrote:
> > Thanks! And I agree with using query_id in the new field names while
> > keeping
> > queryid for pg_stat_statements to avoid unnecessary query breakage.
>
> I think we need more feedback
On Thu, Apr 8, 2021 at 8:52 AM Masahiko Sawada wrote:
>
> On Thu, Apr 8, 2021 at 12:17 PM Amit Kapila wrote:
> >
> > On Wed, Apr 7, 2021 at 5:11 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Apr 7, 2021 at 7:00 PM Amit Kapila
> > > wrote:
> > > >
> > > > During recent developments in the
On Thu, Apr 8, 2021 at 12:17 PM Amit Kapila wrote:
>
> On Wed, Apr 7, 2021 at 5:11 PM Masahiko Sawada wrote:
> >
> > On Wed, Apr 7, 2021 at 7:00 PM Amit Kapila wrote:
> > >
> > > During recent developments in the vacuum, it has been noticed [1] that
> > > parallel vacuum workers don't use any bu
OK, I bit the bullet and re-did the logic in the way I had proposed
earlier in the thread: do the propagation on the collector's side, by
sending only the list of ancestors: the collector can read the tuple
change count by itself, to add it to each ancestor. This seems less
wasteful. Attached is
On Wed, Apr 7, 2021 at 5:11 PM Masahiko Sawada wrote:
>
> On Wed, Apr 7, 2021 at 7:00 PM Amit Kapila wrote:
> >
> > During recent developments in the vacuum, it has been noticed [1] that
> > parallel vacuum workers don't use any buffer access strategy. I think
> > we can fix it either by propagat
On Wed, Apr 7, 2021 at 7:12 PM Bharath Rupireddy
wrote:
>
> On Wed, Apr 7, 2021 at 3:30 PM Amit Kapila wrote:
> >
> > During recent developments in the vacuum, it has been noticed [1] that
> > parallel vacuum workers don't use any buffer access strategy. I think
> > we can fix it either by propag
I wrote:
> Peter Eisentraut writes:
>> Can we move forward with this?
> We could just push the change and see what happens. But I was thinking
> more in terms of doing that early in the v15 cycle. I remain skeptical
> that we need a near-term fix.
To make sure we don't forget, I added an entry
On Wed, Apr 07, 2021 at 07:42:11PM -0700, Noah Misch wrote:
> I think this is a bug in $SUBJECT.
Sorry for the late reply. I intend to answer to that and this is
registered as an open item, but I got busy with some other things.
--
Michael
signature.asc
Description: PGP signature
On Thu, Apr 8, 2021 at 12:56 PM Amit Kapila wrote:
>
> On Thu, Apr 8, 2021 at 3:49 AM Peter Smith wrote:
> >
> > On Wed, Apr 7, 2021 at 10:15 PM Amit Kapila wrote:
> > >
> > > On Wed, Apr 7, 2021 at 1:11 PM Ajin Cherian wrote:
> >
> > 3.
> > There is inconsistent wording for what seems to be th
On Thu, Apr 8, 2021 at 3:49 AM Peter Smith wrote:
>
> On Wed, Apr 7, 2021 at 10:15 PM Amit Kapila wrote:
> >
> > On Wed, Apr 7, 2021 at 1:11 PM Ajin Cherian wrote:
>
> 3.
> There is inconsistent wording for what seems to be the same condition.
> e.g.1 The existing documentation [2] says "Xid of
On 2021/04/08 10:56, Kohei KaiGai wrote:
2021年4月8日(木) 4:19 Fujii Masao :
On 2021/04/06 21:06, Kazutaka Onishi wrote:
Thank you for checking v13, and here is v14 patch.
1) Are we using all of these macros? I see that we are setting them
but we only use TRUNCATE_REL_CONTEXT_ONLY. If not use
On Thu, Apr 8, 2021 at 8:41 AM Peter Geoghegan wrote:
>
> On Wed, Apr 7, 2021 at 8:52 AM Peter Geoghegan wrote:
> > All of the changes from your fixup patch are clear improvements, and
> > so I'll include them in the final commit. Thanks!
>
> I did change the defaults of the GUCs to 1.6 billion,
On Thu, Apr 8, 2021 at 10:38:08AM +0800, Julien Rouhaud wrote:
> On Wed, Apr 07, 2021 at 10:31:01PM -0400, Bruce Momjian wrote:
> > On Wed, Apr 7, 2021 at 08:54:02PM -0400, Bruce Momjian wrote:
> > > > Unless I'm missing something this will output the query id in the next
> > > > log
> > > > lin
On Sun, Apr 04, 2021 at 03:08:02PM -0700, Noah Misch wrote:
> On Wed, Mar 31, 2021 at 09:37:44AM +0900, Michael Paquier wrote:
> > On Tue, Mar 30, 2021 at 12:02:45PM +0900, Michael Paquier wrote:
> > > Okay. So I have looked at that stuff in details, and after fixing
> > > all the issues reported
On Wed, Apr 07, 2021 at 10:31:01PM -0400, Bruce Momjian wrote:
> On Wed, Apr 7, 2021 at 08:54:02PM -0400, Bruce Momjian wrote:
> > > Unless I'm missing something this will output the query id in the next log
> > > line? The new code should be added before the newline is output, and the
> > > com
On Wed, Apr 7, 2021 at 08:54:02PM -0400, Bruce Momjian wrote:
> > Unless I'm missing something this will output the query id in the next log
> > line? The new code should be added before the newline is output, and the
> > comma
> > should also be output before the queryid.
>
> Yes, correct, upd
On Wed, Apr 7, 2021 at 11:47 AM Bharath Rupireddy
wrote:
>
> On Wed, Apr 7, 2021 at 11:44 AM Michael Paquier wrote:
> >
> > On Wed, Apr 07, 2021 at 06:31:19AM +0530, Bharath Rupireddy wrote:
> > > Setting p->pd_flags = 0; is unnecessary and redundant after memsetting
> > > the page to zeros. Also
On Thu, Apr 8, 2021 at 1:34 AM Tom Lane wrote:
> Amit Langote writes:
> > Also, I think we should update the commentary around ri_projectNew a
> > bit to make it clear that noplace beside ExecGet{Insert|Update}Tuple
> > should be touching it and the associated slots.
>
> Hm. I pushed your commen
On Thu, Apr 8, 2021 at 5:56 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-04-08 09:17:42 +0900, Michael Paquier wrote:
> > On Wed, Apr 07, 2021 at 11:09:41AM -0300, Euler Taveira wrote:
> > > On Wed, Apr 7, 2021, at 10:25 AM, Bharath Rupireddy wrote:
> > >> I agree to not remove "with (oids = false)
Hi,
On 2021-04-07 17:10:37 -0700, Andres Freund wrote:
> I think this can be solved in two different ways:
>
> 1) Hold ReplicationSlotAllocationLock with LW_SHARED across most of
>InvalidateObsoleteReplicationSlots(). That way nobody could re-create a new
>slot in the to-be-obsoleted-slot'
I wrote:
> I had an idea about that. I've not tested this, but I think it would be
> a trivial matter of adding a coalesce() call to make the query act like
> the type name for a not-present argument is an empty string, rather than
> NULL which is what it gets right now. Then you could do what I
2021年4月8日(木) 4:19 Fujii Masao :
>
> On 2021/04/06 21:06, Kazutaka Onishi wrote:
> > Thank you for checking v13, and here is v14 patch.
> >
> >> 1) Are we using all of these macros? I see that we are setting them
> >> but we only use TRUNCATE_REL_CONTEXT_ONLY. If not used, can we remove
> >> them?
>
> Attached a patch which attempts to fix this by moving the cancellation
> cancelling request after processing results.
Thank you for your fixing. I tested and the problem has been solved after
applying your patch.
Regards,
Shi yu
Hi,
I found a typo in jsonfuncs.c, probably.
s/an an/an/
Please find attached patch.
Thanks,
Tatsuro Yamada
diff --git a/src/backend/utils/adt/jsonfuncs.c
b/src/backend/utils/adt/jsonfuncs.c
index 511467280f..9961d27df4 100644
--- a/src/backend/utils/adt/jsonfuncs.c
+++ b/src/backend/utils/a
On Wed, Apr 7, 2021 at 08:54:02PM -0400, Bruce Momjian wrote:
> > > I am also confused about the inconsistency of calling the GUC
> > > compute_query_id (with underscore), but pg_stat_activity.queryid. If we
> > > make it pg_stat_activity.query_id, it doesn't match most of the other
> > > *id col
On Thu, Apr 8, 2021 at 08:47:48AM +0800, Julien Rouhaud wrote:
> On Wed, Apr 07, 2021 at 07:38:35PM -0400, Bruce Momjian wrote:
> > On Wed, Apr 7, 2021 at 07:01:25PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Uh, I think your patch missed a few things. First, you use "%zd"
> > >
On Wed, Apr 07, 2021 at 07:38:35PM -0400, Bruce Momjian wrote:
> On Wed, Apr 7, 2021 at 07:01:25PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Uh, I think your patch missed a few things. First, you use "%zd"
> > > (size_t) for the printf string, but calls to pgstat_get_my_queryid() in
On Thu, Apr 8, 2021 at 12:13 AM Andrey Borodin wrote:
> > 7 апр. 2021 г., в 14:44, Andrey Borodin написал(а):
> > Maybe instead of fully associative cache with random replacement we could
> > use 1-associative cache?
> > i.e. each page can reside only in one spcific buffer slot. If there's
> >
Hi,
On 2021-04-08 09:17:42 +0900, Michael Paquier wrote:
> On Wed, Apr 07, 2021 at 11:09:41AM -0300, Euler Taveira wrote:
> > On Wed, Apr 7, 2021, at 10:25 AM, Bharath Rupireddy wrote:
> >> I agree to not remove "with (oids = false)". At least shouldn't we fix
> >> the "create table ... with (oids
On Wed, Apr 07, 2021 at 11:09:41AM -0300, Euler Taveira wrote:
> On Wed, Apr 7, 2021, at 10:25 AM, Bharath Rupireddy wrote:
>> I agree to not remove "with (oids = false)". At least shouldn't we fix
>> the "create table ... with (oids = false, oids = false )" case,
>> just to be consistent with
Hi,
I was looking at InvalidateObsoleteReplicationSlots() while reviewing /
polishing the logical decoding on standby patch. Which lead me to notice that
I think there's a race in InvalidateObsoleteReplicationSlots() (because
ResolveRecoveryConflictWithLogicalSlots has a closely related one).
voi
On Wed, Apr 7, 2021 at 8:52 AM Peter Geoghegan wrote:
> All of the changes from your fixup patch are clear improvements, and
> so I'll include them in the final commit. Thanks!
I did change the defaults of the GUCs to 1.6 billion, though.
All patches in the patch series have been pushed. Hopeful
On Wed, Apr 7, 2021 at 07:01:25PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Uh, I think your patch missed a few things. First, you use "%zd"
> > (size_t) for the printf string, but calls to pgstat_get_my_queryid() in
> > src/backend/utils/error/elog.c used "%ld". Which is correct? I s
Here's a rebase, due to a conflict with 3a513067 "psql: Show all query
results by default" which moved a few things around making it harder
to use the pager for the right scope. Lacking time, I came up with
this change to PSQLexecWatch():
+ if (printQueryFout)
+ {
+ rest
I wrote:
> Greg Sabino Mullane writes:
>> * There seems to be no way (?) to limit the functions returned if they
>> share a common root. The previous incantation allowed you to pull out
>> foo(int) from foo(int, bigint). This was a big motivation for writing this
>> patch.
> Hmm, are you trying t
Bruce Momjian writes:
> Uh, I think your patch missed a few things. First, you use "%zd"
> (size_t) for the printf string, but calls to pgstat_get_my_queryid() in
> src/backend/utils/error/elog.c used "%ld". Which is correct? I see
> pgstat_get_my_queryid() as returning uint64, but I didn't thi
On Thu, Apr 8, 2021 at 05:56:25AM +0800, Julien Rouhaud wrote:
> On Wed, Apr 07, 2021 at 04:22:55PM -0400, Bruce Momjian wrote:
> > aOn Wed, Apr 7, 2021 at 04:15:50PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Patch applied. I am ready to adjust this with any improvements people
On Wed, Apr 7, 2021 at 10:15 PM Amit Kapila wrote:
>
> On Wed, Apr 7, 2021 at 1:11 PM Ajin Cherian wrote:
> >
> > Hi,
> >
> > Found that some documentation hasn't been updated for the changes made as
> > part of
> > streaming large in-progress transactions. Attached a patch that adds the
> > mi
On Thu, Apr 08, 2021 at 05:56:25AM +0800, Julien Rouhaud wrote:
>
> I also added the queryid to the csvlog output and fixed the documentation that
> mention how to create a table to access the data.
Note that I chose to output a 0 queryid if none has been computed rather that
outputting nothing.
On Wed, Apr 7, 2021 at 8:50 PM Kyotaro Horiguchi
wrote:
> I haven't changed the name "XLog reader" to "XLog decoder". I'm doing
> that but it affects somewhat wide range of code.
Thanks for the new patch set! Let's not worry about renaming it for now.
This fails in check-world as seen on cfbot;
I wrote:
> Greg Sabino Mullane writes:
>> * SQL error on \df foo a..b as well as one on \df foo (bigint bigint)
> The first one seems to be a bug, will look.
Argh, silly typo (and I'd failed to test the schema-qualified-name case).
While I was thinking about use-cases for this, I realized that
On Wed, Apr 07, 2021 at 04:22:55PM -0400, Bruce Momjian wrote:
> aOn Wed, Apr 7, 2021 at 04:15:50PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Patch applied. I am ready to adjust this with any improvements people
> > > might have. Thank you for all the good feedback we got on this,
Greg Sabino Mullane writes:
> I like the wildcard aspect, but I have a few issues with the patch:
> * It doesn't respect some common abbreviations that work elsewhere (e.g.
> CREATE FUNCTION). So while "int4" works, "int" does not. Nor does "float",
> which thus requires the mandatory-double-quot
> On Apr 7, 2021, at 2:04 PM, Alvaro Herrera wrote:
>
> On 2021-Apr-07, Mark Dilger wrote:
>
>> It seems we're debating between two designs. In the first, each
>> PostgresNode function knows about version limitations and has code
>> like:
>>
>> DoSomething() if $self->at_least_version(
I like the wildcard aspect, but I have a few issues with the patch:
* It doesn't respect some common abbreviations that work elsewhere (e.g.
CREATE FUNCTION). So while "int4" works, "int" does not. Nor does "float",
which thus requires the mandatory-double-quoted "double precision"
* Adding comma
On 2021-Apr-07, Andrew Dunstan wrote:
> Oh, you want to roll them all up into one file? That could work. It's a
> bit frowned on by perl purists, but I've done similar (see PGBuild/SCM.pm).
Ah! Yeah, pretty much exactly like that, including the "no critic" flag ...
--
Álvaro Herrera
On 2021-Apr-07, Mark Dilger wrote:
> It seems we're debating between two designs. In the first, each
> PostgresNode function knows about version limitations and has code
> like:
>
> DoSomething() if $self->at_least_version("11")
Yeah, I didn't like this approach -- it is quite messy.
> a
On 4/7/21 4:48 PM, Mark Dilger wrote:
>
>> On Apr 7, 2021, at 1:28 PM, Alvaro Herrera wrote:
>>
>> On 2021-Apr-07, Mark Dilger wrote:
>>
>>> I was commenting on the design to have the PostgresNode derived
>>> subclass hard-coded to return "10" as the version:
>>>
>>>sub version { return 10 }
> On Apr 7, 2021, at 1:28 PM, Alvaro Herrera wrote:
>
> On 2021-Apr-07, Mark Dilger wrote:
>
>> I was commenting on the design to have the PostgresNode derived
>> subclass hard-coded to return "10" as the version:
>>
>>sub version { return 10 }
>
> That seems a minor bug rather than a s
On 4/7/21 4:19 PM, Alvaro Herrera wrote:
> On 2021-Apr-07, Andrew Dunstan wrote:
>
>> b) as it stands pgaTester.pm can't be used for multiple versions in a
>> single program, which is a design goal here - it sets the single class
>> to invoke in its BEGIN block. At the very least we would need to
Hi,
On 2021-04-07 10:09:54 -0700, Andres Freund wrote:
> There's also no test for a recovery conflict due to row removal. Despite
> that being a substantial part of the patchset.
Another aspect that wasn't tested *at all*: Whether logical decoding
actually produces useful and correct results.
>
Andrew Dunstan writes:
> On 4/7/21 4:02 PM, Tom Lane wrote:
>> On further thought, that doesn't seem like the place to fix it.
>> I'd rather be able to ask the buildfarm server to send me nagmail
>> if my animal hasn't sent a report in N days (where N had better
>> be owner-configurable).
> That
On 2021-Apr-07, Mark Dilger wrote:
> I was commenting on the design to have the PostgresNode derived
> subclass hard-coded to return "10" as the version:
>
> sub version { return 10 }
That seems a minor bug rather than a showstopper design deficiency.
I agree that hardcoding the version in t
On 4/7/21 4:02 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 4/7/21 1:07 PM, Tom Lane wrote:
>>> I do use it on some of my flakier dinosaurs, and I've noticed that
>>> when it does kick in, the buildfarm run just stops dead and no report
>>> is sent to the BF server. That has advantages in
aOn Wed, Apr 7, 2021 at 04:15:50PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Patch applied. I am ready to adjust this with any improvements people
> > might have. Thank you for all the good feedback we got on this, and I
> > know many users have waited a long time for this feature.
>
Peter Eisentraut writes:
> Committed. Thanks!
Buildfarm suggests this has some issues under force_parallel_mode.
I'm wondering about missed fields in outfuncs/readfuncs, or the like.
regards, tom lane
On 2021-Apr-07, Andrew Dunstan wrote:
> b) as it stands pgaTester.pm can't be used for multiple versions in a
> single program, which is a design goal here - it sets the single class
> to invoke in its BEGIN block. At the very least we would need to replace
> that with code which would require the
On 07/04/2021 22:41, Andrey Borodin wrote:
I see there is a problem with "SET client_min_messages = DEBUG1;" on
buildfarm. I think these checks were necessary to make sure test
paths are triggered. When we know that code paths are tested, maybe
we can omit checks?
Yeah. We don't have very reliabl
On Sun, Apr 4, 2021 at 8:02 PM Mark Dilger wrote:
> v18-0001 - Finishes work started in commit 3b6c1259f9 that was overlooked
> owing to how I had separated the changes in v17-0002 vs. v17-0003
Committed.
> v18-0002 - Postpones the toast checks for a page until after the main table
> page lock
Bruce Momjian writes:
> Patch applied. I am ready to adjust this with any improvements people
> might have. Thank you for all the good feedback we got on this, and I
> know many users have waited a long time for this feature.
For starters, you could try to make the buildfarm green again.
On 4/7/21 3:09 PM, Alvaro Herrera wrote:
> On 2021-Apr-07, Andrew Dunstan wrote:
>
>> Aren't you likely to end up duplicating substantial amounts of code,
>> though?
> No — did you look at his code? Each version is child of the one just
> above, so you only need to override things where behavior
Andrew Dunstan writes:
> On 4/7/21 1:07 PM, Tom Lane wrote:
>> I do use it on some of my flakier dinosaurs, and I've noticed that
>> when it does kick in, the buildfarm run just stops dead and no report
>> is sent to the BF server. That has advantages in not cluttering the
>> BF status with run-f
Greg Sabino Mullane writes:
> [ v6-psql-df-pick-function-by-type.patch ]
I looked this over. I like the idea a lot, but not much of anything
about the implementation. I think the additional arguments should be
matched to the function types using the same rules as for \dT. That
allows patterns
On 03.04.21 05:39, Julien Rouhaud wrote:
Are you planning to run pg_indent before committing or would that add too much
noise?
Yeah, I figured I'd leave that for later, to not bloat the patch so much.
Anyway since it's only stylistic issues and the feature freeze is getting
closer I'm marking
> 7 апр. 2021 г., в 16:18, Heikki Linnakangas написал(а):
>
I see there is a problem with "SET client_min_messages = DEBUG1;" on buildfarm.
I think these checks were necessary to make sure test paths are triggered. When
we know that code paths are tested, maybe we can omit checks?
Best reg
> On Apr 7, 2021, at 12:13 PM, Alvaro Herrera wrote:
>
> On 2021-Apr-07, Mark Dilger wrote:
>
>> It's not sufficient to think about postgres versions as "10", "11",
>> etc. You have to be able to spin up nodes of any build, like "9.0.7".
>> There are specific versions of postgres with specif
On 2021/04/06 21:06, Kazutaka Onishi wrote:
Thank you for checking v13, and here is v14 patch.
1) Are we using all of these macros? I see that we are setting them
but we only use TRUNCATE_REL_CONTEXT_ONLY. If not used, can we remove
them?
These may be needed for the foreign data handler ot
On 2021-Apr-07, Mark Dilger wrote:
> It's not sufficient to think about postgres versions as "10", "11",
> etc. You have to be able to spin up nodes of any build, like "9.0.7".
> There are specific versions of postgres with specific bugs that cause
> specific problems, and later versions of postg
On Wed, Apr 07, 2021 at 02:12:11PM -0400, Bruce Momjian wrote:
> Patch applied. I am ready to adjust this with any improvements people
> might have. Thank you for all the good feedback we got on this, and I
> know many users have waited a long time for this feature.
If you support log_line_prefi
On 2021-Apr-07, Andrew Dunstan wrote:
> Aren't you likely to end up duplicating substantial amounts of code,
> though?
No — did you look at his code? Each version is child of the one just
above, so you only need to override things where behavior changes from
one version to the next.
> I'm certa
On 4/7/21 1:07 PM, Tom Lane wrote:
> Robins Tharakan writes:
>> Not sure if many agree but 2 things stood out here:
>> 1) Buildfarm never got the message that a commit broke an instance. Ideally
>> I'd have expected buildfarm to have an optimistic timeout that could have
>> helped - for e.g. rig
> On Apr 7, 2021, at 11:35 AM, Jehan-Guillaume de Rorthais
> wrote:
>
> On Wed, 7 Apr 2021 13:38:39 -0400
> Andrew Dunstan wrote:
>
>> On 4/7/21 1:19 PM, Jehan-Guillaume de Rorthais wrote:
>>> On Wed, 7 Apr 2021 12:51:55 -0400
>>> Alvaro Herrera wrote:
>>>
On 2021-Apr-07, Jehan-Guill
On Wed, 7 Apr 2021 13:38:39 -0400
Andrew Dunstan wrote:
> On 4/7/21 1:19 PM, Jehan-Guillaume de Rorthais wrote:
> > On Wed, 7 Apr 2021 12:51:55 -0400
> > Alvaro Herrera wrote:
> >
> >> On 2021-Apr-07, Jehan-Guillaume de Rorthais wrote:
> >>
> >>> When I'm creating a new node, I'm using the "
On Wed, 7 Apr 2021 10:50:26 -0700
Mark Dilger wrote:
> > On Apr 7, 2021, at 10:36 AM, Alvaro Herrera wrote:
> >
> >> Yes, it would be much saner to make PostgresNode the factory class. Plus,
> >> some more logic could be injected there to either auto-detect the version
> >> (current behavior)
1 - 100 of 200 matches
Mail list logo
