On 2021-10-27 14:45, Michael Paquier wrote:
On Tue, Oct 26, 2021 at 05:04:24PM +0900, Shinya Kato wrote:
Barring any objection, I will change status to Ready for Committer.
+ else if (Matches("COMMENT", "ON", "PROCEDURAL"))
+ COMPLETE_WITH("LANGUAGE");
+ else if (Matches("COMMENT", "
Hi,
Thank you for your comment.
The attached patch stops message splitting.
This patch also limits the timing of message output when huge_pages = try and
HugePages is not used.
Regards,
Noriyoshi Shinoda
-Original Message-
From: Justin Pryzby [mailto:pry...@telsasoft.com]
Sent: Friday,
On Thursday, October 21, 2021 12:59 PM Masahiko Sawada
wrote:
>
> I've attached updated patches. In this version, in addition to the
> review comments I go so far, I've changed the view name from
> pg_stat_subscription_errors to pg_stat_subscription_workers as per the
> discussion on including x
On Tue, Oct 26, 2021 at 05:04:24PM +0900, Shinya Kato wrote:
> Barring any objection, I will change status to Ready for Committer.
+ else if (Matches("COMMENT", "ON", "PROCEDURAL"))
+ COMPLETE_WITH("LANGUAGE");
+ else if (Matches("COMMENT", "ON", "PROCEDURAL", "LANGUAGE"))
+ COMPLE
On Wed, Oct 27, 2021 at 10:43 AM Masahiko Sawada wrote:
>
> On Wed, Oct 27, 2021 at 12:35 PM Amit Kapila wrote:
> >
> > On Wed, Oct 27, 2021 at 8:32 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Oct 26, 2021 at 7:29 PM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > You have a point. The
On Wed, Oct 27, 2021 at 10:32:22AM +0530, Amul Sul wrote:
> Thanks for the updated version. The patch is much better than before
> except needing minor changes to the test description that testing
> recovery_end_command_file before promotion, I did the same in the
> attached version.
ok(!-f $reco
On Wed, Oct 27, 2021 at 12:35 PM Amit Kapila wrote:
>
> On Wed, Oct 27, 2021 at 8:32 AM Masahiko Sawada wrote:
> >
> > On Tue, Oct 26, 2021 at 7:29 PM Amit Kapila wrote:
> > >
> > >
> > > You have a point. The other alternatives on this line could be:
> > >
> > > Alter Subscription SKIP ( subsc
On Wed, Oct 27, 2021 at 9:37 AM Michael Paquier wrote:
>
> On Mon, Oct 25, 2021 at 02:42:28PM +0530, Amul Sul wrote:
> > Understood, moved tests to 002_archiving.pl in the attached version.
>
> Thanks for the new patch. I have reviewed its contents, and there
> were a couple of things that caught
On Wed, Oct 27, 2021 at 2:28 PM houzj.f...@fujitsu.com
wrote:
>
> When reviewing the v18-0002 patch.
> I noticed that "RESET SYNCHRONOUS_COMMIT" does not take effect
> (RESET doesn't change the value to 'off').
>
>
> + if (!is_reset)
> + {
> +
On Mon, Oct 25, 2021 at 02:42:28PM +0530, Amul Sul wrote:
> Understood, moved tests to 002_archiving.pl in the attached version.
Thanks for the new patch. I have reviewed its contents, and there
were a couple of things that caught my attention while putting my
hands on it.
+$node_standby->append
On Wed, Oct 27, 2021 at 8:32 AM Masahiko Sawada wrote:
>
> On Tue, Oct 26, 2021 at 7:29 PM Amit Kapila wrote:
> >
> >
> > You have a point. The other alternatives on this line could be:
> >
> > Alter Subscription SKIP ( subscription_parameter [=value] [, ...
> > ] );
> >
> > where subscription_
On Thurs, Oct 21, 2021 12:59 PM Masahiko Sawada wrote:
> I've attached updated patches. In this version, in addition to the review
> comments I go so far, I've changed the view name from
> pg_stat_subscription_errors to pg_stat_subscription_workers as per the
> discussion on including xact info to
On Tue, Oct 26, 2021 at 7:29 PM Amit Kapila wrote:
>
> On Tue, Oct 26, 2021 at 2:27 PM Greg Nancarrow wrote:
> >
> > On Tue, Oct 26, 2021 at 5:16 PM Amit Kapila wrote:
> > >
> > > I agree that we will need a separate syntax for conflict resolution
> > > but there is some similarity in what I pro
On Thu, Sep 2, 2021 at 1:55 PM Zhihong Yu wrote:
>
> Hi,
> + case RI_TRIGTYPE_DELETE:
> + queryno = is_set_null
> + ? RI_PLAN_ONDELETE_SETNULL_DOUPDATE
> + : RI_PLAN_ONDELETE_SETDEFAULT_DOUPDATE;
>
> Should the new symbols be renamed ?
>
> RI_PLAN_ONDELE
At Wed, 27 Oct 2021 10:55:31 +0900, Michael Paquier wrote
in
> On Wed, Oct 27, 2021 at 10:24:05AM +0900, Kyotaro Horiguchi wrote:
> > I don't know. The fact is that it's a superuser-backend variable that
> > is silently ignored (but acutally seems to be set in the session).
> > Setting log_disco
At Wed, 27 Oct 2021 11:17:28 +0900 (JST), Kyotaro Horiguchi
wrote in
> Each pg_receivewal run stalls for about 10 or more seconds before
> finishing, which is not great from the standpoint of recently
> increasing test run time.
>
> Maybe we want to advance LSN a bit, after taking $nextlsn then
At Tue, 26 Oct 2021 11:01:46 +0200, Ronan Dunklau
wrote in
> Le mardi 26 octobre 2021, 08:27:47 CEST Ronan Dunklau a écrit :
> > Yes, I will try to simplify the logic of the patch I sent last week. I'll
> > keep you posted here soon.
>
> I was able to simplify it quite a bit, by using only one
On Tue, Oct 26, 2021 at 7:34 PM Markus Wanner
wrote:
>
> On 26.10.21 04:20, Amit Kapila wrote:
> > I agree with the points raised here and will revert this for v14.
>
> Thanks, Amit. I appreciate the revert.
>
> Note that the removed events were almost at the end of WaitEventIO enum,
> except for
On Wed, Oct 27, 2021 at 10:24:05AM +0900, Kyotaro Horiguchi wrote:
> I don't know. The fact is that it's a superuser-backend variable that
> is silently ignored (but acutally seems to be set in the session).
> Setting log_disconnection the same way works (of course the impliction
> of this is far l
On Sat, 23 Oct 2021 at 02:00, Tom Lane wrote:
> Japin Li writes:
>> On Sat, 23 Oct 2021 at 00:55, Tom Lane wrote:
>>> What if the subscriber and publisher are of different PG versions
>>> and have different ideas of the valid values of these settings?
>
>> Sorry, I'm a bit confused. Do you me
Japin Li writes:
> Why do we need likely() for base=10, however, base=16 and base=8 don't need?
Yeah, I was a little unconvinced about that too. I concur with writing
it as an if/else chain instead of a switch, but I'm not sure that likely()
adds anything to that.
regard
On Wed, 27 Oct 2021 at 04:58, Arjan van de Ven wrote:
> [PATCH v2] src/port/snprintf.c: Optimize the common base=10 case in fmtint
>
> fmtint() turns an integer into a string for a given base, and to do this
> it does a divide/modulo operation iteratively.
> The only possible base values are 8,
At Tue, 26 Oct 2021 09:39:12 -0400, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > I noticed that the following command doesn't leave connection log in
> > log file.
> >> psql "host=localhost options=-c\ log_connections=on"
>
> [ shrug... ] Why would you expect it to? Should "-c log_connec
Hi,
A while back I'd reported [1] to the wine bugs list that their popen() doesn't
quite work. Which I noticed because it made initdb.exe hang in wine.
That was just fixed. And I verified that with a bleeding edge wine the windows
initdb.exe actually succeeds (although I nuked the root/admin chec
On Tue, Oct 26, 2021 at 3:45 PM Tom Lane wrote:
> Of course, we have that today from the solution of one index with the
> extra columns "included". I think the OP has completely failed to make
> any case why that's not a good enough approach.
I think that the design that the OP is talking about
[PATCH v2] src/port/snprintf.c: Optimize the common base=10 case in fmtint
fmtint() turns an integer into a string for a given base, and to do this
it does a divide/modulo operation iteratively.
The only possible base values are 8, 10 and 16
On just about any CPU, divides are a pretty expensive
On 10/26/2021 10:51 AM, Tom Lane wrote:
Mark Dilger writes:
It appears fmtint only has three options for base, being 10, 16, and 8. Have you
profiled with either of the others special cased as well? I don't see much use in
optimizing for octal, but hexadecimal is used quite a bit in wal wit
Generally if a role is granted membership to another role with NOINHERIT
they must use SET ROLE to access the privileges of that role, however
with predefined roles the membership and privilege is conflated, as
demonstrated by:
CREATE ROLE readrole;
CREATE ROLE role2 NOINHERIT;
CREATE ROLE brindle
Mark Dilger writes:
> For three separate indexes, an update or delete of a single row in the
> indexed table would surely require changing at least three pages in the
> indexes. For some as-yet-ill-defined combined index type, perhaps the three
> entries in the index would fall on the same ind
"Jonathan S. Katz" writes:
> On 10/26/21 3:26 PM, Tom Lane wrote:
>> I think this is conflating two different things: a mapping from the
>> username given in the startup packet, and a mapping from the TLS
>> certificate CN. Using the same keyword and terminology for both
>> is going to lead to pa
> On Oct 26, 2021, at 1:43 PM, Tomas Vondra
> wrote:
>
> I'm still rather skeptical about it - for such feature to be useful the
> prefix columns must not be very selective, i.e. the posting trees are
> expected to be fairly large (e.g. 5-7k rows). It pretty much has to to
> require multip
On 10/26/21, 2:04 PM, "Jeff Davis" wrote:
> Should we just add a builtin function pg_checkpoint(), and deprecate
> the syntax?
That seems reasonable to me.
Nathan
On Tue, Oct 26, 2021 at 11:11:39PM +0200, Tomas Vondra wrote:
> BTW I'm not sure what the existing patches do, but I wonder if we should
> calculate the checksum before or after encryption. I'd say it should be
> after encryption, because checksums were meant as a protection against
> issues at the
On 10/26/21 21:43, Stephen Frost wrote:
Greetings,
* Yura Sokolov (y.soko...@postgrespro.ru) wrote:
... >>
Integrity could be based on simple non-cryptographic checksum, and it could
be checked after decryption. It would be imposible to intentionally change
encrypted page in a way it will pa
On Tue, 2021-10-26 at 23:32 +0900, Fujii Masao wrote:
> The description "This function is restricted to superusers by
> default,
> but other users can be granted EXECUTE to run the function."
> should be added into the docs?
A similar statement already exists right above the table of functions:
"
On Tue, 2021-10-26 at 16:02 -0400, Stephen Frost wrote:
> We're talking about benchmarking tools
What I had in mind was something much less formal, like a self-
contained repro case of a performance problem.
... simple schema
... data load
... maybe build some indexes
... maybe set hints
On Tue, Oct 5, 2021 at 6:50 AM Simon Riggs wrote:
> With unique data, starting at 1 and monotonically ascending, hash
> indexes will grow very nicely from 0 to 10E7 rows without causing >1
> overflow block to be allocated for any bucket. This keeps the search
> time for such data to just 2 blocks
On 10/26/21 21:39, Pavel Borisov wrote:
I've already answered OP but it seems in the wrong thread, so I copy it
here:
I think now in many cases you can effectively use covering index to have
fast index-only scans without index duplication. It will help if you
don't have great selectivity o
On 10/26/21 3:26 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
With certificate-based authentication methods and other methods, we
allow for users to specify a mapping in pg_ident, e.g. if one needs to
perform a rewrite on the CN to match the username that is specified
within PostgreSQL.
It
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Tue, 2021-10-26 at 00:07 +, Bossart, Nathan wrote:
> > It feels a bit excessive to introduce a new predefined role just for
> > this. Perhaps this could be accomplished with a new function that
> > could be granted.
>
> It would be nice
Greetings,
* Yura Sokolov (y.soko...@postgrespro.ru) wrote:
> В Пн, 25/10/2021 в 12:12 -0400, Stephen Frost пишет:
> > * Yura Sokolov (y.soko...@postgrespro.ru) wrote:
> > > В Чт, 21/10/2021 в 13:28 -0400, Stephen Frost пишет:
> > > > I really don't think this is necessary. Similar to PageSetChec
I've already answered OP but it seems in the wrong thread, so I copy it
here:
I think now in many cases you can effectively use covering index to have
fast index-only scans without index duplication. It will help if you don't
have great selectivity on the last column (most probably you don't). E.g
On Mon, 3 Aug 2020 at 15:02, Daniel Gustafsson wrote:
> This thread has stalled and the patch no longer applies, so I'm marking
> this
> Returned with Feedback. Please feel free to open a new entry if this
> patch is
> revived.
>
> cheers ./daniel
>
>
Hi all,
I took v3[1] patch from this thread
"Jonathan S. Katz" writes:
> With certificate-based authentication methods and other methods, we
> allow for users to specify a mapping in pg_ident, e.g. if one needs to
> perform a rewrite on the CN to match the username that is specified
> within PostgreSQL.
> It seems logical that we should
Hi,
Since PostgreSQL 12 (0516c61b756e39) we have allowed for the ability to
set "clientcert=verify-full" against various HBA authentication methods.
This provides the ability to provide "multi-factor authentication" e.g.
a client must provide both a valid certificate with a CN (or DN) that
ma
Hi,
On 2021-10-26 14:33:08 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-10-26 13:51:55 -0400, Tom Lane wrote:
> >> I'd be inclined to just hard-wire the three allowed cases, and not have
> >> an arbitrary-divisor code path at all.
>
> > Yea, I came to the same conclusion. But I'd im
On 10/21/21 19:21, Mark Dilger wrote:
>> Also, are we just going to strip
>> the current CREATEROLE roles of much of their powers? Maybe it's
>> worth keeping a legacy CREATEROLE role attribute for upgraded clusters
>> that could eventually be removed down the road.
> The patch as written drast
Andres Freund writes:
> On 2021-10-26 13:51:55 -0400, Tom Lane wrote:
>> I'd be inclined to just hard-wire the three allowed cases, and not have
>> an arbitrary-divisor code path at all.
> Yea, I came to the same conclusion. But I'd implement it by moving the
> division into a separate inline fun
Hi,
On 2021-10-26 11:04:54 -0700, Andres Freund wrote:
> pgbench: $(OBJS) | submake-libpq submake-libpgport submake-libpgfeutils
> $(CC) $(CFLAGS) $^ $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X)
> I unfortunately don't see a localized fix for this. Afaict we'd need to change
> all client buil
Hi,
On 2021-10-26 13:51:55 -0400, Tom Lane wrote:
> Mark Dilger writes:
> > It appears fmtint only has three options for base, being 10, 16, and 8.
> > Have you profiled with either of the others special cased as well? I don't
> > see much use in optimizing for octal, but hexadecimal is used
Hi,
our make dependencies currently are insufficient to trigger client binaries to
be relinked when pgport/pgcommon/libpq/... changes.
To reproduce, you can use something like:
touch ~/src/postgresql/src/port/snprintf.c && make -j48 2>&1|grep 'gcc.*pgbench'
which won't show anything, whereas e.g.
On 10/25/21 13:09, Tom Lane wrote:
> Andres Freund writes:
>> On 2021-10-22 19:30:25 -0400, Tom Lane wrote:
>>> Yeah. I checked into when it was that we dropped pre-8.0 support
>>> from pg_dump, and the answer is just about five years ago (64f3524e2).
>>> So moving the bar forward by five relea
Mark Dilger writes:
> It appears fmtint only has three options for base, being 10, 16, and 8. Have
> you profiled with either of the others special cased as well? I don't see
> much use in optimizing for octal, but hexadecimal is used quite a bit in wal
> with patterns like "%08X%08X%08X".
I
On 10/25/21 19:12, Justin Pryzby wrote:
> On Mon, Oct 25, 2021 at 11:38:51AM -0400, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 10/25/21 10:23, Tom Lane wrote:
(Hmmm ... but disk space could
become a problem, particularly on older machines with not so much
disk. Do we really
Hi,
On 2021-10-26 07:57:36 -0700, Arjan van de Ven wrote:
> src/port/snprintf.c: Optimize the common base=10 case in fmtint
>
> fmtint() turns an integer into a string for a given base, and to do this
> it does a divide/modulo operation iteratively.
>
> On just about any CPU, divides are a prett
> On Oct 26, 2021, at 7:57 AM, Arjan van de Ven wrote:
>
> By special casing the super common case of base==10, the (gcc) compiler can
> (and will)
> replace the divide by a multiply with 0xcccd, yielding a lot
> faster code.
> (fmtint dropped drastically in the perf profiles aft
On 2021-Oct-26, Robert Haas wrote:
> On Tue, Oct 26, 2021 at 7:54 AM Alvaro Herrera
> wrote:
> > Another point that could be made is that perhaps
> > MakeSingleTupleTableSlot should always construct a slot using virtual
> > tuples rather than passing TTSOps as a parameter?
>
> I haven't really
On 10/25/21, 6:48 PM, "Jeff Davis" wrote:
> On Tue, 2021-10-26 at 00:07 +, Bossart, Nathan wrote:
>> It feels a bit excessive to introduce a new predefined role just for
>> this. Perhaps this could be accomplished with a new function that
>> could be granted.
>
> It would be nice if the synta
On 2021/10/25 21:27, Bharath Rupireddy wrote:
On Mon, Oct 25, 2021 at 4:36 PM Fujii Masao wrote:
On 2021/10/25 16:44, Bharath Rupireddy wrote:
Yeah, let's focus on fixing the hint message here and the
alter_foreign_data_wrapper_options_v3.patch LGTM.
Thanks! But since v3 changed the error
On 2021/10/26 17:33, Yura Sokolov wrote:
Yes, AES with AES-NI is fastest. But not so much.
And, AES-CTR could be easily used instead of ChaCha12 in Adiantum.
Adiantum uses ChaCha12 as a stream cipher, and any other stream cipher will
be ok as well with minor modifications to algorithm.
not so
On Wed, May 26, 2021 at 4:01 AM Masahiko Sawada
wrote:
> On Wed, Apr 14, 2021 at 11:17 PM Mead, Scott wrote:
> >
> >
> >
> > > On Mar 1, 2021, at 8:43 PM, Masahiko Sawada
> wrote:
> > >
> > > CAUTION: This email originated from outside of the organization. Do
> not click links or open attachmen
src/port/snprintf.c: Optimize the common base=10 case in fmtint
fmtint() turns an integer into a string for a given base, and to do this
it does a divide/modulo operation iteratively.
On just about any CPU, divides are a pretty expensive operation, generally
10x to 20x or more expensive than add
> On Oct 25, 2021, at 10:09 PM, Shinya Kato
> wrote:
>
> On 2021-10-21 03:40, Mark Dilger wrote:
>> These patches have been split off the now deprecated monolithic
>> "Delegating superuser tasks to new security roles" thread at [1].
>> The purpose of these patches is to fix the CREATEROLE esc
On 10/26/21 8:49 AM, Hayk Manukyan wrote:
> ok. here is the deal if I have the following index with 6 column
>
> CREATE INDEX ON job_nlp_year_scan (job, nlp, year, scan_id, issue_flag,
> sequence);
>
> I need to specify all 6 columns in where clause in order to fully use
> this index.
What do
On Tue, Oct 26, 2021 at 7:54 AM Alvaro Herrera wrote:
> Another point that could be made is that perhaps
> MakeSingleTupleTableSlot should always construct a slot using virtual
> tuples rather than passing TTSOps as a parameter?
I haven't really looked at this issue deeply but that seems like it
On 2021/10/26 5:42, Jeff Davis wrote:
On Mon, 2021-10-25 at 16:10 +0900, Michael Paquier wrote:
Hmm. Why don't you split the patch into two parts that can be
discussed separately then? There would be one to remove all the
superuser() checks you can think of, and a potential second to grant
On Tue, Oct 26, 2021 at 4:19 AM Bharath Rupireddy
wrote:
> Can we also log the total time the startup process took to recover,
> and also the total time each stage of the recovery/redo processing
> took: 1) into a file or 2) emitting that info via a new hook 3) into a
> system catalog table (assum
On 26.10.21 04:20, Amit Kapila wrote:
I agree with the points raised here and will revert this for v14.
Thanks, Amit. I appreciate the revert.
Note that the removed events were almost at the end of WaitEventIO enum,
except for one last entry: WAIT_EVENT_WAL_WRITE.
Just as a data point: Our
Kyotaro Horiguchi writes:
> I noticed that the following command doesn't leave connection log in
> log file.
>> psql "host=localhost options=-c\ log_connections=on"
[ shrug... ] Why would you expect it to? Should "-c log_connections=off"
be able to hide a connection from the log?
On Thu, Oct 7, 2021 at 7:33 PM Robert Haas wrote:
>
> On Thu, Oct 7, 2021 at 3:24 AM Shruthi Gowda wrote:
> > Every other
> > caller/flow passes false for 'create_storage' and we still need to
> > create storage in heap_create() if relkind has storage.
>
> That seems surprising.
I have revised t
On 2021-Oct-26, Aleksander Alekseev wrote:
> > In short: I'm not okay with doing
> > s/MakeTupleTableSlot/MakeSingleTupleTableSlot/g in a patch that doesn't
> > also introduce matching ExecDropSingleTupleTableSlot calls (unless those
> > exist somewhere already; but where?). If we did clean that u
Hi Alvaro,
> Did you see the arguments at [1]?
>
> [1] https://www.postgresql.org/message-id/1632520.1613195514%40sss.pgh.pa.us
No, I missed it. Thanks for sharing.
> If you dig in the git history (see f92e8a4b5 in particular) you'll note
> that the current version of MakeTupleTableSlot originat
On Fri, 22 Oct 2021 at 10:22, Rafia Sabih wrote:
>
> Hello there hackers,
>
> We at Zalando have faced some issues around long running idle
> transactions and were thinking about increasing the visibility of
> pg_stat_* views to capture them easily. What I found is that currently
> in pg_stat_acti
On Wed, Sep 29, 2021 at 8:18 PM Daniel Gustafsson wrote:
>
> > On 28 Sep 2021, at 15:48, Magnus Hagander wrote:
>
> > Might be worth noting in one of the comments the difference in
> > behaviour if the backend process/thread *crashes* -- that is, on Unix
> > it will be detected via the signal han
On Mon, Oct 25, 2021 at 8:15 PM Robert Haas wrote:
>
> On Mon, Oct 25, 2021 at 3:05 AM Amul Sul wrote:
> > Ok, did the same in the attached 0001 patch.
> >
> > There is no harm in calling LocalSetXLogInsertAllowed() calling
> > multiple times, but the problem I can see is that with this patch use
On Tue, Oct 26, 2021 at 2:27 PM Greg Nancarrow wrote:
>
> On Tue, Oct 26, 2021 at 5:16 PM Amit Kapila wrote:
> >
> > I agree that we will need a separate syntax for conflict resolution
> > but there is some similarity in what I proposed above (On
> > Error/Conflict [1]) with the existing syntax o
В Вт, 26/10/2021 в 11:08 +0800, Sasasu пишет:
> On 2021/10/26 04:32, Yura Sokolov wrote:
> > And among others Adiantum looks best: it is fast even without hardware
> > acceleration,
>
> No, AES is fast on modern high-end hardware.
>
> on X86 AMD 3700X
> type 1024 bytes 8192 bytes
On Tue, Oct 26, 2021 at 2:31 PM Amit Kapila wrote:
>
> On Fri, Oct 15, 2021 at 1:48 AM Robert Haas wrote:
> >
> > On Tue, Oct 12, 2021 at 10:14 AM Dilip Kumar wrote:
> > > Thanks, yeah now it looks in line with other results.
> >
> > Since it seems there are no remaining concerns here, and we ha
Le mardi 26 octobre 2021, 08:27:47 CEST Ronan Dunklau a écrit :
> Yes, I will try to simplify the logic of the patch I sent last week. I'll
> keep you posted here soon.
I was able to simplify it quite a bit, by using only one standby for both test
scenarios.
This test case verify that after a ti
On Fri, Oct 15, 2021 at 1:48 AM Robert Haas wrote:
>
> On Tue, Oct 12, 2021 at 10:14 AM Dilip Kumar wrote:
> > Thanks, yeah now it looks in line with other results.
>
> Since it seems there are no remaining concerns here, and we have
> benchmarking results showing that the patch helps, I have com
On Tue, Oct 26, 2021 at 5:16 PM Amit Kapila wrote:
>
> I agree that we will need a separate syntax for conflict resolution
> but there is some similarity in what I proposed above (On
> Error/Conflict [1]) with the existing syntax of Insert ... On
> Conflict. I understand that here the context is d
> On 23 Oct 2021, at 00:47, Michael Paquier wrote:
>
> On Fri, Oct 22, 2021 at 10:49:38PM +0200, Daniel Gustafsson wrote:
>> On 22 Oct 2021, at 20:34, Tom Lane wrote:
>>> Ah, you're right, InsertPgAttributeTuples is the only other spot in
>>> that patch that's actually touching slots. I'd skimm
Hello.
I noticed that the following command doesn't leave connection log in
log file.
> psql "host=localhost options=-c\ log_connections=on"
The reason is we log connections before the options is processed. We
need to move the code from BackendInitialize to InitPostgres where
that options are p
On Mon, Oct 25, 2021 at 9:26 PM Robert Haas wrote:
>
> On Tue, Oct 19, 2021 at 9:06 AM Nitin Jadhav
> wrote:
> > Thanks for sharing the patch. Overall approach looks good to me. But
> > just one concern about using enable_timeout_every() functionality. As
> > per my understanding the caller shoul
On 2021-10-15 17:49, Ken Kato wrote:
2021-10-15 13:29 に Shinya Kato さんは書きました:
On 2021-10-14 14:30, katouknl wrote:
It is very good, but it seems to me that there are some
tab-completion
missing in COMMENT command.
For example,
- CONSTRAINT ... ON DOMAIN
- OPERATOR CLASS
- OPERATOR FAMILY
- POL
On Tue, Oct 26, 2021 at 3:24 PM Peter Smith wrote:
>
> PSA new set of patches:
>
> v34-0001 = the "main" patch from Euler. No change
>
> v34-0002 = tab auto-complete. No change
>
> v34-0003 = cache updates. Addresses Tomas review comment #3 [1].
>
> v34-0004 = filter validation replica identity. A
ok. here is the deal if I have the following index with 6 column
CREATE INDEX ON job_nlp_year_scan (job, nlp, year, scan_id, issue_flag,
sequence);
I need to specify all 6 columns in where clause in order to fully use this
index.
It will not be efficient in cases when I have 4 condition in where
87 matches
Mail list logo
