Le mer. 30 juin 2021 à 22:44, Tom Lane a écrit :
> 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.
>
>
Congrats to
> 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 the matches and mark the corresponding hashtable
> entries. I have updated the patch with the fix.
It looks OK to me.
> > > I think
> 1 июля 2021 г., в 01:43, Tom Lane написал(а):
>
> 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.
Congratul
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 the matches and mark the corresponding hashtable
> > entries. I
On Thu, Jul 1, 2021 at 9:06 AM Guillaume Lelarge wrote:
>
> Le mer. 30 juin 2021 à 22:44, Tom Lane a écrit :
>>
>> 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.
>>
>> Pleas
On Wed, Jun 30, 2021 at 8:05 PM Amit Kapila wrote:
>
> On Mon, Jun 28, 2021 at 10:12 AM Masahiko Sawada
> wrote:
> >
> > On Thu, Jun 17, 2021 at 6:20 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Jun 17, 2021 at 3:24 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > > Now, if this function
On 2021/06/30 0:12, Julien Rouhaud wrote:
Enabling this parameter may incur a noticeable performance penalty,
- especially when a fewer kinds of queries are executed on many
- concurrent connections.
+ especially when queries with identical structure are executed by many
At Fri, 25 Jun 2021 12:02:22 +, "kuroda.hay...@fujitsu.com"
wrote in
> Dear Hackers,
>
> I checked about DECLARE STATEMENT(added from ad8305a), and I noticed that
> this connection-control feature cannot be used for DEALLOCATE and DESCRIBE
> statement.
>
> I attached the patch that fixes
Hello Thomas,
After looking at it again, here is an update which ensure 64 bits on
epoch_shift computation.
The code in pgbench 13 aggregates into buckets that begin on the
boundaries of wall clock seconds, because it is triggered by changes
in time_t. In the current patch, we aggregate data
On 17.05.21 23:01, Bruce Momjian wrote:
On Mon, May 17, 2021 at 10:56:54PM +0200, Peter Eisentraut wrote:
The fix is like what we used to use for plperl back then:
diff --git a/src/include/utils/pg_locale.h b/src/include/utils/pg_locale.h
index f3e04d4d8c..499ada2b69 100644
--- a/src/include/ut
At Thu, 01 Jul 2021 17:48:49 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 25 Jun 2021 12:02:22 +, "kuroda.hay...@fujitsu.com"
> wrote in
> The following commands handle the liked connection.
> DECLARE
> PREPARE
> EXECUTE
>
> The follwoing commands don't.
> DESCRIBE
> DEALLOCATE
> DE
It seems like a few too many years of an SQL standard without any
standardised way to LIMIT the number of records in a result set caused
various applications to adopt some strange ways to get this behaviour.
Over here in the PostgreSQL world, we just type LIMIT n; at the end of
our queries. I beli
čt 1. 7. 2021 v 11:11 odesílatel David Rowley napsal:
> It seems like a few too many years of an SQL standard without any
> standardised way to LIMIT the number of records in a result set caused
> various applications to adopt some strange ways to get this behaviour.
> Over here in the PostgreSQL
On Thu, 1 Jul 2021 at 02:00, David Rowley wrote:
>
> I kinda disagree with the send/recv naming since all you're using them
> for is to serialise/deserialise the NumericVar. Functions named
> *send() and recv() I more expect to return a bytea so they can be used
> for a type's send/recv function.
Hello.
While I looked a patch, I found that the following ECPG statement
generates uncompilable .c source.
EXEC SQL CREATE TABLE t AS stmt;
ecpgtest.c:
#line 42 "ecpgtest.pgc"
printf("1:dbname=%s\n", dbname);
{ ECPGdo(__LINE__, 0, 1, NULL, 0, ECPGst_execute, crea
On Thu, 1 Jul 2021 at 10:27, Dean Rasheed wrote:
>
> I'll post an update in a while. Thanks for the review.
>
One other thing I'm wondering about is back-patching. I was originally
thinking of these as back-patchable bug fixes, but changing the binary
format of the aggregate serialization states
Hello David,
This patch adds the concept of "multiconnect" to pgbench (better
terminology welcome).
Good. I was thinking of adding such capability, possibly for handling
connection errors and reconnecting…
The basic idea here is to allow connections made with pgbench to use
different auth
On Wed, Jun 30, 2021 at 8:34 AM Dilip Kumar wrote:
>
> On Tue, Jun 29, 2021 at 8:15 PM wrote:
> >
> > Hi,
> >
> > The program pg_receivewal can use gzip compression to store the received
> > WAL.
> > This patch teaches it to be able to use lz4 compression if the binary is
> > build
> > using th
On Thu, 1 Jul 2021 at 22:03, Dean Rasheed wrote:
> One other thing I'm wondering about is back-patching. I was originally
> thinking of these as back-patchable bug fixes, but changing the binary
> format of the aggregate serialization states feels dodgy for a
> back-patch.
I was wondering about t
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, which means that pgbench older
perfor
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, (b)
there is no need to initialize supported_opts variable in
CreateS
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
>
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 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 g
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: 6568.18
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 wi
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 v
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 you
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 thread[1].
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 s
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.
> +REGRESS_SHLIB=$(abs_top_builddir
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 when
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 o
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 commit
‐‐‐ 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 g
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:
> > >
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 n
‐‐‐ 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:
> >
> >
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 very
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 in
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]
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 messag
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.
re
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 lane
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.
>
Con
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, tom
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 a
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 t
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 somewhere?
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 me
Andrew Dunstan writes:
>> Shouldn't these new targets be documented somewhere?
> Good point. See attached.
+1, but spell check: "documantation"
regards, tom lane
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, wh
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 b
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 should
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 Riggshttp://www.En
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 tim
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 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 any
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 bra
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
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 fo
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 a
"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 HE
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 RelationGetIndexLis
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 t
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 no
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 mark
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"
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 $(shl
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) | $(SH
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 w
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 other
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 Makefile.global
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
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. */
Fre
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 ran
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)
>
> Perha
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.
>>> We
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 s
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
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 the
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.
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 t
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 m
> 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.
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 001
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 resulti
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 see
On Thu, Jul 01, 2021 at 09:13:25AM -0400, Andrew Dunstan wrote:
> OK, done.
Thanks!
--
Michael
signature.asc
Description: PGP signature
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
numbe
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 there's
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 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 wi
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 o
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
>
> https://www.postgresql.org/message-id/flat/23
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. Moreo
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 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 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 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:
1 - 100 of 127 matches
Mail list logo
