On Wed, 2021-06-30 at 12:25 -0400, Robert Haas wrote:
> I am not sure whether this works or not. Holding off cancel
> interrupts
> across possible network I/O seems like a non-starter. We have to be
> able to kill off connections that have wedged.
I was following a pattern that I saw in
Hi,
I found a strange behavior when there is an insert after renaming the
schema. The test steps for the same are given below, Here after the
schema is renamed, the renamed schema table data should not be sent,
but the data was being sent. I felt the schema invalidation was not
called, attached a
On Wednesday, June 30, 2021 7:43 PM vignesh C wrote:
>
> Thanks for reporting this issue, the attached v9 patch fixes this issue. This
> also fixes the other issue you reported at [1].
A comment on v9:
src/bin/psql/describe.c
+ if (pset.sversion >=
On Fri, 2 Jul 2021 at 00:19, Simon Riggs
wrote:
> > So yeah. I think it'd be better to log the info you want at start-of-txn
> unless there's a compelling reason not so, and I don't see one yet.
>
> AFAIK, XLOG_XACT_ASSIGNMENT does not occur for normal top-level
> transactions, only for
On Mon, Jun 28, 2021 at 08:21:06PM +0530, Bharath Rupireddy wrote:
> The recoveryWakeupLatch and procLatch/MyLatch are being used for WAL
> replay and recovery conflict, respectively. Actually, I was earlier
> using procLatch/MyLatch, but came across the commit 00f690a23 which
> says that the two
On Wed, Jun 30, 2021 at 01:43:52PM +0500, Ahsan Hadi wrote:
> Sure I will also take a look at this patch.
>
> +1 for avoiding the backpatching burden.
From what I recall of this thread, nobody has really complained about
this stuff either, so a backpatch would be off the table. I agree
that
At Thu, 01 Jul 2021 18:45:25 +0900 (JST), Kyotaro Horiguchi
wrote in
> I'll post the test part later.
A version incluedes the test part.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 6ef902608483f395983da5063db3e0af8d61ed4e Mon Sep 17 00:00:00 2001
From: Kyotaro
On Thu, Jul 1, 2021 at 8:24 PM Richard Guo wrote:
>
> On Thu, Jul 1, 2021 at 3:18 PM Ronan Dunklau
> wrote:
>
>> Le jeudi 1 juillet 2021, 09:09:38 CEST Ronan Dunklau a écrit :
>> > > Yes, thanks! I was making a big mistake here thinking the executor can
>> > > stop after the first match. That's
"Schneider (AWS), Jeremy" writes:
>> On Jul 1, 2021, at 18:57, Tom Lane wrote:
>> But I wonder why
>> print the parent's OID, when we have access to its name.
> Seems like a few people do schema-based multi-tenancy with similarly named
> relations in different namespaces, so I’d have a
On Thu, Jul 1, 2021 at 3:18 PM Ronan Dunklau wrote:
> Le jeudi 1 juillet 2021, 09:09:38 CEST Ronan Dunklau a écrit :
> > > Yes, thanks! I was making a big mistake here thinking the executor can
> > > stop after the first match. That's not true. We need to use each outer
> > > tuple to find all
On 2021-Jul-02, Amit Kapila wrote:
> Yeah, that makes sense. I have removed its usage from
> CreateSubscription but I think we can get rid of it entirely as well.
Nod.
> The latest patch sent by Bharath looks good to me. Would you like to
> commit it or shall I take care of it?
Please, go
On Fri, Jul 2, 2021 at 7:08 AM Michael Paquier wrote:
>
> On Thu, Jul 01, 2021 at 09:29:01PM -0400, Bruce Momjian wrote:
> > Should we reserve the next commit fest for vignesh C?
>
> If Vignesh is willing to help here, I'd say yes to that.
I'm interested in assisting Ibrar Ahmed.
Regards,
On Thu, Jul 1, 2021 at 10:19 PM Thomas Munro wrote:
>
> Spotted in the "Hashing" section:
>
> "Use "lazy" hash tables to look up only the tuples that are actually
requested"
>
> David Rowley has knocked that one off. He called it Result Cache.
Thanks, I'll take care of that one also.
--
John
On Thu, Jul 1, 2021 at 6:10 PM Thomas Munro wrote:
> One thing I'm wondering about is whether it's worth having stuff to
> support future experimentation like ST_SORT_SMALL_THRESHOLD and
> ST_COMPARE_RET_TYPE in the tree, or whether we should pare it back to
> the minimal changes that definitely
Spotted in the "Hashing" section:
"Use "lazy" hash tables to look up only the tuples that are actually requested"
David Rowley has knocked that one off. He called it Result Cache.
> On Jul 1, 2021, at 18:57, Tom Lane wrote:
>
> But I wonder why
> print the parent's OID, when we have access to its name.
Seems like a few people do schema-based multi-tenancy with similarly named
relations in different namespaces, so I’d have a preference for OID over an
unqualified
On Thu, Jul 1, 2021 at 8:00 PM Alvaro Herrera wrote:
>
> I find the business with OPT_NONE a bit uselessly verbose. It's like we
> haven't completely made up our minds that zero means no options set.
> Wouldn't it be simpler to remove that #define and leave the variable
> uninitialized until we
On Fri, Jul 2, 2021 at 1:39 AM Tom Lane wrote:
>
> Amit Langote writes:
> > [ v6-0001-Allow-batching-of-inserts-during-cross-partition-.patch ]
>
> Per the cfbot, this isn't applying anymore, so I'm setting it back
> to Waiting on Author.
Rebased patch attached. Thanks for the reminder.
--
Jeremy Schneider writes:
> Nonetheless, in the process of troubleshooting it occurred to me that
> this error message would be more useful in general if it included the
> base relation OID in the error message. Amit suggested a separate thread
> - so here we are. :)
> Anyone have thoughts?
On Thu, Jul 01, 2021 at 10:03:10AM -0400, Greg Sabino Mullane wrote:
> Searching about the TAP tests often leads to this page, but there is no
> easy link or mention of the fact that the sample invocations will not work
> without the special config flag.
This is mentioned on a different page,
On Fri, Jul 2, 2021 at 5:24 AM Jacob Champion wrote:
> On Tue, 2021-06-08 at 17:32 +0800, Quan Zongliang wrote:
> > In the KnownAssignedTransactionIdes sub-module, two lines of unused code
> > were found in a previous change.
>
> Huh. Looks like this code died as part of 2fc7af5e966?
>
> CC'ing
On Thu, Jul 01, 2021 at 12:26:55AM +0500, Ibrar Ahmed wrote:
> Yes, I want to do that for sure.
Thanks. Please note that I have switched the CF as "In Progress" in
the app, and added a couple of future CFs while on it to cover the
development cycle for 15.
--
Michael
signature.asc
Description:
On Thu, Jul 01, 2021 at 09:29:01PM -0400, Bruce Momjian wrote:
> Should we reserve the next commit fest for vignesh C?
If Vignesh is willing to help here, I'd say yes to that.
--
Michael
signature.asc
Description: PGP signature
On Wed, Jun 30, 2021 at 07:00:31PM -0400, Tom Lane wrote:
> If this code were new in v14, I'd be +1, but it looks like it was
> there in 13 too. So maybe there's somebody external depending on
> it, which would make it a bit unfriendly to remove it post-beta.
> Let's just add the #ifndef in HEAD.
On Thu, Jul 1, 2021 at 12:26:55AM +0500, Ibrar Ahmed wrote:
> Hi,
> Yes, I want to do that for sure.
Should we reserve the next commit fest for vignesh C?
---
>
> On Wed, Jun 30, 2021 at 6:33 PM Daniel Gustafsson wrote:
>
On Mon, Jun 28, 2021 at 11:01:57AM -0400, Tom Lane wrote:
> Dunno ... I cannot recall ever having had that as a debugging requirement
> in a couple of decades worth of PG bug-chasing. If the postmaster is
> dying, you generally want to deal with that before bothering with child
> processes.
On Mon, Jun 28, 2021 at 05:41:50PM -0400, John Naylor wrote:
> Here I'm just reviewing a couple items in the Sorting section:
>
> https://wiki.postgresql.org/wiki/Todo#Sorting
>
> - Consider whether duplicate keys should be sorted by block/offset
>
>
On Thu, Jul 01, 2021 at 02:10:17PM +, gkokola...@pm.me wrote:
> Micheal suggested on the same thread to move my entry in the help output so
> that
> the output remains ordered. I would like the options for the compression
> method and
> the already existing compression level to next to each
On Thu, Jul 1, 2021 at 11:54 PM Jesper Pedersen
wrote:
> On 6/30/21 4:43 PM, Tom Lane wrote:
> > The Core Team would like to extend our congratulations to
> > Daniel Gustafsson and John Naylor, who have accepted invitations
> > to become our newest Postgres committers.
> >
> > Please join me in
On Fri, Jul 2, 2021 at 12:45 AM Tom Lane wrote:
> Amit Langote writes:
> > The problem is that it loops over the entire range table even though
> > only one or handful of those entries actually need their permissions
> > checked. Most entries, especially those of partition child tables
> > have
On Mon, Jun 28, 2021 at 09:25:47PM -0500, Justin Pryzby wrote:
> On Mon, Jun 28, 2021 at 09:01:40PM -0400, Bruce Momjian wrote:
> > so we are talking about scans in parallel, so I think it is plural. Wrong?
>
> I think the "type" of scan being referenced is a "parallel" type, right ?
> So
I have found an interesting result from patched pgbench (I have set
the isolation level to REPEATABLE READ):
$ pgbench -p 11000 -c 10 -T 30 --max-tries=0 test
pgbench (15devel, server 13.3)
starting vacuum...end.
transaction type:
scaling factor: 1
query mode: simple
number of clients: 10
On Thu, Jul 01, 2021 at 09:13:25AM -0400, Andrew Dunstan wrote:
> OK, done.
Thanks!
--
Michael
signature.asc
Description: PGP signature
On Thu, Jul 1, 2021 at 03:13:30PM +0100, Simon Riggs wrote:
> On Wed, Jun 30, 2021 at 11:20 PM Bruce Momjian wrote:
> > > * "row expiration" is a term not currently used in PG docs, so we
> > > should probably look for something else.
> >
> > Yeah, I changed that to "removing dead rows" which
On Wed, Jun 30, 2021 at 12:21 PM Andrey Lepikhov
wrote:
> On 12/3/21 12:05, Hywel Carver wrote:
> > I've built and tested this, and it seems to function correctly to me.
> One question I have is whether the added "IS NOT NULL" filters can be
> omitted when they're unnecessary. Some of the
On Fri, Jul 2, 2021 at 4:39 AM John Naylor wrote:
> For item pointers, it made sense to try doing math to reduce the number of
> branches. That made things worse, so let's try the opposite: Increase the
> number of branches so we do less math. In the attached patch (applies on top
> of your
> On 1 Jul 2021, at 22:40, Peter Eisentraut
> wrote:
>
> On 30.06.21 22:46, Daniel Gustafsson wrote:
>> I think consistency is the interesting aspect here. We already have a mix of
>> SSL, TLS and SSL/TLS (although heavily skewed towards SSL) so we should
>> settle
>> on one and stick to it.
Hello Dean,
I haven't looked at the patch in detail, but one thing I object to is
the code to choose a random integer in an arbitrary range.
Thanks for bringing up this interesting question!
Currently, this is done in pgbench by getrand(), which has its
problems.
Yes. That is one of the
On 7/1/21 4:29 PM, Peter Eisentraut wrote:
> On 01.07.21 22:22, Andrew Dunstan wrote:
>>
>> On 7/1/21 3:39 PM, Peter Eisentraut wrote:
>>> On 01.07.21 16:47, Andrew Dunstan wrote:
On 6/2/21 4:21 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I'm inclined to agree with Alvaro
On 30.06.21 22:46, Daniel Gustafsson wrote:
I think consistency is the interesting aspect here. We already have a mix of
SSL, TLS and SSL/TLS (although heavily skewed towards SSL) so we should settle
on one and stick to it. The arguments in the NSS thread which led to this
pointed to SSL/TLS.
Hello Tom,
Indeed. Here is a blind attempt at fixing the build, I'll check later to
see whether it works. It would help me if the cfbot results were
integrated into the cf app.
Hmm, not there yet per cfbot, not sure why not.
I'll investigate.
Anyway, after taking a very quick look at
On 01.07.21 22:22, Andrew Dunstan wrote:
On 7/1/21 3:39 PM, Peter Eisentraut wrote:
On 01.07.21 16:47, Andrew Dunstan wrote:
On 6/2/21 4:21 PM, Tom Lane wrote:
Andrew Dunstan writes:
I'm inclined to agree with Alvaro that the messages are at best an
oddity. Standard Unix practice is to be
On 30.06.21 20:43, Jacob Champion wrote:
On Wed, 2021-06-30 at 20:20 +0200, Peter Eisentraut wrote:
I note that popular places such as the Apache and nginx SSL/TLS modules
just use SSL in their documentation, and they are probably under much
more scrutiny in this area.
For Apache, that's not
On 7/1/21 3:39 PM, Peter Eisentraut wrote:
> On 01.07.21 16:47, Andrew Dunstan wrote:
>>
>> On 6/2/21 4:21 PM, Tom Lane wrote:
>>> Andrew Dunstan writes:
I'm inclined to agree with Alvaro that the messages are at best an
oddity. Standard Unix practice is to be silent on success.
>>>
On Fri, 2 Jul 2021 at 01:13, Ranier Vilela wrote:
>
> Hi,
>
> The function FreePageManagerPutInternal can access an uninitialized
variable,
> if the following conditions occur:
Patch looks good to me.
> 1. fpm->btree_depth != 0
> 2. relptr_off == 0 inside function (FreePageBtreeSearch)
>
>
On Thu, 1 Jul 2021 at 19:41, Tom Lane wrote:
>
> Anyway, after taking a very quick look at the patch itself, I've
> got just one main objection: I don't approve of putting this in
> port.h or src/port/.
I haven't looked at the patch in detail, but one thing I object to is
the code to choose a
Hi,
The function FreePageManagerPutInternal can access an uninitialized
variable,
if the following conditions occur:
1. fpm->btree_depth != 0
2. relptr_off == 0 inside function (FreePageBtreeSearch)
Perhaps this is a rare situation, but I think it's worth preventing.
/* Search the btree. */
On 01.07.21 16:47, Andrew Dunstan wrote:
On 6/2/21 4:21 PM, Tom Lane wrote:
Andrew Dunstan writes:
I'm inclined to agree with Alvaro that the messages are at best an
oddity. Standard Unix practice is to be silent on success.
We've been steadily moving towards less chatter during builds.
I'd
Peter Eisentraut writes:
> On 01.07.21 20:14, Tom Lane wrote:
>> The problem then is, what happens when the extra action fails?
>> Without .DELETE_ON_ERROR, the shlib is still there and the next
>> make run will think everything's good.
> Right. .DELETE_ON_ERROR is already set in
On 01.07.21 20:14, Tom Lane wrote:
The variant of this I'd been thinking of was
$(shlib): $(OBJS) | $(SHLIB_PREREQS)
$(LINK.shared) -o $@ $(OBJS) $(LDFLAGS) $(LDFLAGS_SL) $(SHLIB_LINK)
+ifneq (,$(SHLIB_EXTRA_ACTION))
+ $(SHLIB_EXTRA_ACTION)
+endif
(and similarly in several
Fabien COELHO writes:
>> Although this patch is marked RFC, the cfbot shows it doesn't
>> even compile on Windows. I think you missed updating Mkvcbuild.pm.
> Indeed. Here is a blind attempt at fixing the build, I'll check later to
> see whether it works. It would help me if the cfbot results
On Thu, 2021-07-01 at 14:14 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Somewhere in the $(shlib) rule would seem most appropriate. But I don't
> > understand the rest: What ifeq, and why .DELETE_ON_ERROR?
>
> The variant of this I'd been thinking of was
>
> $(shlib): $(OBJS) |
Peter Eisentraut writes:
> On 01.07.21 00:41, Jacob Champion wrote:
>> Spitballing -- if you don't like the stamp file, you could add the
>> check to the end of the $(shlib) rule, surrounded by an ifeq check.
>> Then .DELETE_ON_ERROR should take care of the rest, I think.
> Somewhere in the
On 01.07.21 00:41, Jacob Champion wrote:
On Wed, 2021-06-30 at 18:29 -0400, Tom Lane wrote:
I wrote:
Peter Eisentraut writes:
Could we set this rule up a little bit differently so that it is only
run when the library is built.
Right now, make world on a built tree makes 17 calls to this "nm"
On Tue, 2021-06-08 at 17:32 +0800, Quan Zongliang wrote:
> Hi,
>
> In the KnownAssignedTransactionIdes sub-module, two lines of unused code
> were found in a previous change.
Huh. Looks like this code died as part of 2fc7af5e966?
CC'ing Thomas just in case we're missing something, but I'll
Andrew Dunstan writes:
> On 7/1/21 11:01 AM, Tom Lane wrote:
>> I'm inclined to argue that it's okay to sneak the initdb change into
>> v14, on the grounds that it's needed to fully exploit the change
>> from CLOBBER_CACHE_ALWAYS to debug_invalidate_system_caches_always.
>> Without it, there is
On 7/1/21 11:01 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 6/22/21 5:11 PM, Tom Lane wrote:
>>> Here's a couple of draft-quality patches --- one for initdb, one
>>> for the buildfarm --- to implement this idea. These are just
>>> lightly tested; in particular I've not had the patience
On 2021-Jun-30, Alexander Pyhalov wrote:
> Looks good. It seems this comment refers to line 455.
Ah, so it does.
I realized that we don't need to do vac_open_indexes for partitioned
tables: it is sufficient to know whether there are any indexes at all.
So I replaced that with
"kuroda.hay...@fujitsu.com" writes:
>> The test portion bloats the patch so it would be easier to read if
>> that part is separated from the code part.
> Right, I'll separate and attach again few days. Sorry for inconvenience;-(.
Please also ensure that you're generating the patch against git
Although this patch is marked RFC, the cfbot shows it doesn't
even compile on Windows. I think you missed updating Mkvcbuild.pm.
Indeed. Here is a blind attempt at fixing the build, I'll check later to
see whether it works. It would help me if the cfbot results were
integrated into the cf
Nicolas CHAHWEKILIAN writes:
> As far as I am concerned, I am totally awaiting for this kind of feature
> exposed here, for one single reason at this time : the extension
> pg_statement_rollback will be much more valuable with the ability of
> processing "rollback to savepoint" without the need
Amit Langote writes:
> [ v6-0001-Allow-batching-of-inserts-during-cross-partition-.patch ]
Per the cfbot, this isn't applying anymore, so I'm setting it back
to Waiting on Author.
regards, tom lane
I wrote:
> One of the points of the talk I linked to is "if doing the sensible thing
makes things worse, try something silly instead".
For item pointers, it made sense to try doing math to reduce the number of
branches. That made things worse, so let's try the opposite: Increase the
number of
On Thu, Jul 1, 2021 at 8:23 AM Simon Riggs wrote:
> Definitely some good ideas here.
I have been meaning to come up with some kind of solution to the
problem of "self-blocking" LP_DEAD bit setting within the
kill_prior_tuple mechanism. It's hard to argue against that.
> I'm out of time to do
Although this patch is marked RFC, the cfbot shows it doesn't
even compile on Windows. I think you missed updating Mkvcbuild.pm.
regards, tom lane
On Tue, Jun 22, 2021 at 6:32 AM Craig Ringer
wrote:
> IIRC the restart_lsn horizon already ensures that we can't miss the
> xl_xact_assignment at the start of a txn. We would ensure that the desired
> info is available throughout decoding of the txn, including at commit record
> processing
On Thu, Jun 24, 2021 at 7:15 PM Fabien COELHO wrote:
>
>
> Hello Simon,
>
> Indeed.
>
> There is already a "ready" patch in the queue, see:
>
> https://commitfest.postgresql.org/33/3034/
Ah, my bad. I withdraw this patch, apologies Tatsuo-san.
--
Simon Riggs
On Wed, Jun 30, 2021, at 5:46 PM, Daniel Gustafsson wrote:
> > On 30 Jun 2021, at 20:20, Peter Eisentraut
> > wrote:
>
> > I am not in favor of this direction. I think it just adds tediousness and
> > doesn't really help anyone. If we are worried about correct terminology,
> > then we
On Thu, Jul 1, 2021 at 6:32 PM Amit Kapila wrote:
> > 3) There's an whitespace introduced making the SUBOPT_SLOT_NAME,
> > SUBOPT_SYNCHRONOUS_COMMIT and SUBOPT_STREAMING not falling line with
> > the SUBOPT_CONNECT
> >
>
> okay, will fix it.
PSA v11 patch which also has the cleanup patch shared
Fabien COELHO writes:
> Hello Greg,
>
> Some quick feedback about the patch and the arguments.
>
> Filling: having an empty string/NULL has been bothering me for some time.
> However there is a
> significant impact on the client/server network stream while initializing or
> running queries,
Andrew Dunstan writes:
>> Shouldn't these new targets be documented somewhere?
> Good point. See attached.
+1, but spell check: "documantation"
regards, tom lane
Amit Langote writes:
> The problem is that it loops over the entire range table even though
> only one or handful of those entries actually need their permissions
> checked. Most entries, especially those of partition child tables
> have their requiredPerms set to 0, which David pointed out to
On 7/1/21 10:50 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> OK, I think on reflection new targets will be cleaner. What I suggest is
>> the attached, applied to all branches, followed by removal of the four
>> noise messages in just HEAD.
> Shouldn't these new targets be documented
On Fri, Jun 25, 2021 at 4:44 PM Peter Geoghegan wrote:
>
> On Fri, Jun 25, 2021 at 1:43 AM Simon Riggs
> wrote:
> > Seems a little bizarre to have _bt_check_unique() call back into the
> > heap block we literally just unpinned.
>
> I suppose it is a little bizarre.
>
> > This is another case of
Andrew Dunstan writes:
> On 6/22/21 5:11 PM, Tom Lane wrote:
>> Here's a couple of draft-quality patches --- one for initdb, one
>> for the buildfarm --- to implement this idea. These are just
>> lightly tested; in particular I've not had the patience to run
>> full BF cycles to see how much is
On 6/30/21 4:43 PM, Tom Lane wrote:
The Core Team would like to extend our congratulations to
Daniel Gustafsson and John Naylor, who have accepted invitations
to become our newest Postgres committers.
Please join me in wishing them much success and few bugs.
regards,
On Wed, Jun 30, 2021 at 04:43:58PM -0400, Tom Lane wrote:
> The Core Team would like to extend our congratulations to
> Daniel Gustafsson and John Naylor, who have accepted invitations
> to become our newest Postgres committers.
>
> Please join me in wishing them much success and few bugs.
>
Andrew Dunstan writes:
> OK, I think on reflection new targets will be cleaner. What I suggest is
> the attached, applied to all branches, followed by removal of the four
> noise messages in just HEAD.
Shouldn't these new targets be documented somewhere?
regards, tom
Alvaro Herrera writes:
> I think this means the rule should use $(GREP), which is /usr/bin/ggrep
> in wrasse,
I didn't install this change, because it isn't actually needed at the
moment, and we aren't using $(GREP) anywhere else. Might be a bridge
to cross in future.
On 6/2/21 4:21 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I'm inclined to agree with Alvaro that the messages are at best an
>> oddity. Standard Unix practice is to be silent on success.
> We've been steadily moving towards less chatter during builds.
> I'd be good with dropping these
Noah Misch writes:
> On Thu, Jul 01, 2021 at 01:20:48AM -0400, Tom Lane wrote:
>> I've just re-read the POSIX spec for "nm", and I do not see anything there
>> that would support that interpretation.
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html says:
> nm [-APv] [-g|-u]
I find the business with OPT_NONE a bit uselessly verbose. It's like we
haven't completely made up our minds that zero means no options set.
Wouldn't it be simpler to remove that #define and leave the variable
uninitialized until we want to set the options we want, and then use
plain assignment
On Wed, Jun 30, 2021 at 11:20 PM Bruce Momjian wrote:
>
> On Tue, Jun 29, 2021 at 07:36:47PM +0100, Simon Riggs wrote:
> > Perhaps we should also add this text from the commit message to ensure
> > the importance is understood:
> > "This is extremely useful in cases where CIC/RC can run for a
‐‐‐ Original Message ‐‐‐
On Thursday, July 1st, 2021 at 15:58, Magnus Hagander
wrote:
> On Thu, Jul 1, 2021 at 3:39 PM gkokola...@pm.me wrote:
>
> > ‐‐‐ Original Message ‐‐‐
> >
> > On Thursday, July 1st, 2021 at 12:28, Magnus Hagander mag...@hagander.net
> > wrote:
> >
> >
Quick patch to add mention of the need for compiling with
--enable-tap-tests on the TAP section page
https://www.postgresql.org/docs/current/regress-tap.html
Searching about the TAP tests often leads to this page, but there is no
easy link or mention of the fact that the sample invocations will
On Thu, Jul 1, 2021 at 3:39 PM wrote:
>
>
>
> ‐‐‐ Original Message ‐‐‐
>
> On Thursday, July 1st, 2021 at 12:28, Magnus Hagander
> wrote:
>
> > On Wed, Jun 30, 2021 at 8:34 AM Dilip Kumar dilipbal...@gmail.com wrote:
> >
> > > On Tue, Jun 29, 2021 at 8:15 PM gkokola...@pm.me wrote:
> >
‐‐‐ Original Message ‐‐‐
On Thursday, July 1st, 2021 at 12:28, Magnus Hagander
wrote:
> On Wed, Jun 30, 2021 at 8:34 AM Dilip Kumar dilipbal...@gmail.com wrote:
>
> > On Tue, Jun 29, 2021 at 8:15 PM gkokola...@pm.me wrote:
> >
> > > Hi,
> > >
> > > The program pg_receivewal can use
On Thu, Jul 1, 2021 at 5:43 PM Bharath Rupireddy
wrote:
>
> On Tue, Jun 22, 2021 at 10:11 AM Bharath Rupireddy
> wrote:
> >
> > On Tue, Jun 22, 2021 at 9:45 AM vignesh C wrote:
> > > I have removed the skip table patches to keep the focus on the main
> > > patch, once this patch gets into
On Thu, Jul 1, 2021 at 1:06 AM Rahila Syed wrote:
>
> Hi,
>
> Filtering of columns at the publisher node will allow for selective
> replication of data between publisher and subscriber. In case the updates on
> the publisher are targeted only towards specific columns, the user will have
> an
On Tue, 29 Jun 2021 at 12:08, Dean Rasheed wrote:
>
> Numeric x^y is supported for x < 0 if y is an integer, but this
> currently fails if y is outside the range of an int32
>
I've been doing some more testing of this, and I spotted another
problem with numeric_power().
This is what happens
On 6/21/21 8:23 PM, Michael Paquier wrote:
> On Sun, Jun 20, 2021 at 01:24:04PM -0400, Andrew Dunstan wrote:
>> Tests pass with the attached patch, which puts the setting in the
>> Makefile for the recovery tests. The script itself doesn't need any
>> changing.
>
On Thu, Jul 1, 2021 at 5:37 PM Bharath Rupireddy
wrote:
>
> On Thu, Jul 1, 2021 at 4:38 PM Amit Kapila wrote:
> >
> > On Wed, Jun 30, 2021 at 7:38 PM Bharath Rupireddy
> > wrote:
> > >
> > > PFA v9 patch set for further review.
> > >
> >
> > The first patch looks mostly good to me. I have made
On Thu, Jul 1, 2021 at 12:56 PM Amit Kapila wrote:
>
> On Wed, Jun 30, 2021 at 4:35 PM Amit Kapila wrote:
> >
> > On Mon, Jun 28, 2021 at 10:12 AM Masahiko Sawada
> > wrote:
> > >
> > >
> > > 0003 patch adds pg_stat_logical_replication_error statistics view
> > > discussed on another
Dear Horiguchi-san,
Thank you for replying!
> (Maybe by consulting the code.. Anyway, )
I noticed the patch cannot be applied...
> The follwoing commands don't.
> DESCRIBE
> DEALLOCATE
> DECLARE CURSOR .. FOR
> CREATE TABLE AS EXECUTE
I'm not sure about `CREATE TABLE AS EXECUTE`(I'll check
On Thu, Jul 1, 2021 at 6:07 PM Fujii Masao wrote:
>
> On 2021/07/01 13:16, Bharath Rupireddy wrote:
> > On Thu, Jul 1, 2021 at 8:23 AM Fujii Masao
> > wrote:
> >> The recent commit 61d599ede7 documented that the type of those options is
> >> floating point. But the docs still use "is a numeric
On 2021/07/01 13:16, Bharath Rupireddy wrote:
On Thu, Jul 1, 2021 at 8:23 AM Fujii Masao wrote:
The recent commit 61d599ede7 documented that the type of those options is
floating point. But the docs still use "is a numeric value" in the descriptions
of them. Probably it should be replaced
On Thu, 1 Jul 2021 at 06:43, David Rowley wrote:
>
> Master @ 3788c6678
>
> Execution Time: 8306.319 ms
> Execution Time: 8407.785 ms
> Execution Time: 8491.056 ms
>
> Master + numeric-agg-sumX2-overflow-v2.patch
> Execution Time: 6633.278 ms
> Execution Time: 6657.350 ms
> Execution Time:
On Tue, Jun 22, 2021 at 10:11 AM Bharath Rupireddy
wrote:
>
> On Tue, Jun 22, 2021 at 9:45 AM vignesh C wrote:
> > I have removed the skip table patches to keep the focus on the main
> > patch, once this patch gets into committable shape, I will focus on
> > the skip table patch.
>
> IMO it's a
On Thu, Jul 1, 2021 at 4:38 PM Amit Kapila wrote:
>
> On Wed, Jun 30, 2021 at 7:38 PM Bharath Rupireddy
> wrote:
> >
> > PFA v9 patch set for further review.
> >
>
> The first patch looks mostly good to me. I have made some minor
> modifications to the 0001 patch: (a) added/edited few comments,
On Thu, Jul 1, 2021 at 1:24 PM Masahiko Sawada wrote:
>
> On Wed, Jun 30, 2021 at 8:05 PM Amit Kapila wrote:
>
> > If so, in which cases are you imagining the files to be
> > created, is it in the case of relation message
> > (LOGICAL_REP_MSG_RELATION)? Assuming the previous two statements are
>
1 - 100 of 124 matches
Mail list logo
