On Mon, Sep 27, 2021 at 09:27:56PM -0500, Justin Pryzby wrote:
> That's an "expanded" version of 0008.
Okay, thanks.
> It doesn't include 0012, which is primarily about fixing incorrect references
> to "index expressions" that should refer to stats expressions. Naturally 0012
> also uses the phr
Hi,
I created a patch for COMMENT tab completion.
It was missing TRANSFORM FOR where it's supposed to be.
Best wishes,
Ken Katodiff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index 5cd5838668..d18b26a4a5 100644
--- a/src/bin/psql/tab-complete.c
+++ b/src/bin/psql/tab-compl
On Wed, Sep 29, 2021 at 11:59 AM houzj.f...@fujitsu.com
wrote:
>
> On Wed, Sep 29, 2021 12:34 PM Amit Kapila
> > On Wed, Sep 29, 2021 at 9:07 AM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > On Tues, Sep 28, 2021 10:46 PM vignesh C wrote:
> > > > Attached v34 patch has the changes for the same.
On Tue, Sep 28, 2021 at 2:50 AM Thomas Munro wrote:
> On Thu, Sep 23, 2021 at 9:13 PM Juan José Santamaría Flecha
> wrote:
> > When GetTempFileName() finds a duplicated file name and the file is
> pending for deletion, it fails with an "ERROR_ACCESS_DENIED" error code.
> That may describe the si
On Wed, Sep 29, 2021 at 11:35 AM osumi.takami...@fujitsu.com
wrote:
>
> Hi,
>
>
> Thank you, Amit-san and Sawada-san for the discussion.
> On Tuesday, September 28, 2021 7:05 PM Amit Kapila
> wrote:
> > > Another idea could be to have a separate view, say
> > > pg_stat_subscription_xact but I'm
Em qua., 29 de set. de 2021 às 06:55, Drouvot, Bertrand
escreveu:
> Hi,
>
> On 9/28/21 6:50 PM, Tom Lane wrote:
> > "Drouvot, Bertrand" writes:
> >> Does it make sense (as it is currently) to set the ActiveSnapshot to
> >> NULL and not ensuring the same is done for ActivePortal->portalSnapshot?
On Tue, Sep 28, 2021 at 7:36 PM Antonin Houska wrote:
>
> Amit Kapila wrote:
>
> > On Mon, Sep 20, 2021 at 10:55 AM Antonin Houska wrote:
> > >
> > > Amit Kapila wrote:
> > >
> > > > On Thu, Sep 9, 2021 at 8:33 PM Antonin Houska wrote:
> > >
> > > > > The problem of the temporary undo log is t
> 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 handler and on Windows the whole
> process including the main thread wil
On Tue, Sep 28, 2021 at 7:04 PM Amit Kapila wrote:
>
> On Tue, Sep 28, 2021 at 11:35 AM Masahiko Sawada
> wrote:
> >
> > On Tue, Sep 28, 2021 at 1:54 PM Amit Kapila wrote:
> > >
> > > >
> > > > Then, if, we proceed in this direction,
> > > > the place to implement those stats
> > > > would be o
Em qua., 29 de set. de 2021 às 08:12, Drouvot, Bertrand
escreveu:
> Hi,
> On 9/29/21 12:59 PM, Ranier Vilela wrote:
>
>
> Em qua., 29 de set. de 2021 às 06:55, Drouvot, Bertrand <
> bdrou...@amazon.com> escreveu:
>
>> I'm also inclined to #1.
>>
> I have a stupid question, why duplicate PushActiv
On Wed, Sep 29, 2021 at 3:47 AM Tom Lane wrote:
>
> I noticed that some test scripts, instead of using wait_for_catchup
> to wait for replication catchup, use ad-hoc code like
>
> my $primary_lsn =
> $primary->safe_psql('postgres', 'select pg_current_wal_lsn()');
> $standby->poll_query_until('po
On Wed, Sep 29, 2021 at 4:49 PM Masahiko Sawada wrote:
>
> On Tue, Sep 28, 2021 at 7:04 PM Amit Kapila wrote:
> >
> > On Tue, Sep 28, 2021 at 11:35 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Sep 28, 2021 at 1:54 PM Amit Kapila
> > > wrote:
> > > >
> > > > >
> > > > > Then, if, we proce
Hi!
Nice feature, but, sorry, I see some design problem in suggested feature. AFAIK,
there is two use cases for this feature:
1 A permission / prohibition to login some users
2 Just a logging of facts of user's login
Suggested patch proposes prohibition of login only by failing of login trigge
On Wed, Sep 29, 2021 5:14 PM Amit Kapila wrote:
> On Wed, Sep 29, 2021 at 11:59 AM houzj.f...@fujitsu.com
> wrote:
> >
> > On Wed, Sep 29, 2021 12:34 PM Amit Kapila
> > > On Wed, Sep 29, 2021 at 9:07 AM houzj.f...@fujitsu.com
> > > wrote:
> > > >
> > > > On Tues, Sep 28, 2021 10:46 PM vignesh C
On 2021-Sep-28, Tom Lane wrote:
> 1. Provide a variant of PushActiveSnapshot that allows the caller
> to specify the as_level to use, and then have
> EnsurePortalSnapshotExists, as well as other places that create
> Portal-associated snapshots, use this with as_level equal to the
> Portal's create
On 2021-Sep-29, Ranier Vilela wrote:
> Em qua., 29 de set. de 2021 às 08:12, Drouvot, Bertrand
> escreveu:
> > Adding a new function prevents "updating" existing extensions making use
> > of PushActiveSnapshot().
> >
> Valid argument of course.
> But the extensions should also fit the core code.
On 2021/09/24 11:26, Fujii Masao wrote:
On 2021/09/24 7:26, Yugo NAGATA wrote:
That makes sense. Failures of setup connection or initial connection doesn't
seem 'static problems'. I rewrote this description to explain exit status 1
indicates also interal errors and early errors.
Exit st
On 2021-Sep-28, Amit Kapila wrote:
> But it is not allowed to create schema or table with the name
> CURRENT_SCHEMA, so not sure if we need to do anything special for it.
Oh? You certainly can.
alvherre=# create schema "CURRENT_SCHEMA";
CREATE SCHEMA
alvherre=# \dn
Listado de esquemas
> It is common to mention what the default is as part of the
> documentation of a GUC. I don't see why this one should be an
> exception, especially since not mentioning it reduces the length of
> the documentation by exactly one word.
>
> I don't mind the sentence you added at the end to clarify t
On 2021-Sep-24, Alvaro Herrera wrote:
> Here's the set for all branches, which I think are really final, in case
> somebody wants to play and reproduce their respective problem scenarios.
> Nathan already confirmed that his reproducer no longer shows a problem,
> and this version shouldn't affect
On 2021-Sep-24, Hannu Krosing wrote:
Hi Hannu
> In the first email you write
>
> > As mentioned in the course of thread [1], we're missing a fix for
> streaming replication to avoid sending records that the primary hasn't
> fully flushed yet. This patch is a first attempt at fixing that problem
On Tue, Sep 21, 2021 at 6:48 PM Alvaro Herrera wrote:
> Document XLOG_INCLUDE_XID a little better
>
> I noticed that commit 0bead9af484c left this flag undocumented in
> XLogSetRecordFlags, which led me to discover that the flag doesn't
> actually do what the one comment on it said it does. Impro
Amit Kapila writes:
> On Wed, Sep 29, 2021 at 3:47 AM Tom Lane wrote:
>> It seems to me that for most purposes wait_for_catchup's approach is
>> strictly worse, for two reasons:
>> 1. It continually recomputes the primary's pg_current_wal_lsn().
>> 2. It's querying the primary's view of the stand
Re: Richard Yen
> Ah, thanks for the tip. That's right -- I can't assume the user's input is
> a valid file. Updated patch here.
Hi Richard,
sorry for the very late response here.
Thanks for the patch which I just merged, and thanks Justin for the
reviews!
Christoph
James Coleman writes:
> A coworker has a space in a Postgres password and noticed .pgpass
> didn't work; escaping it fixed the issue. That requirement wasn't
> documented (despite other escaping requirements being documented), so
> I've attached a patch to add that comment.
I looked at passwordFr
> On Sep 29, 2021, at 9:01 AM, Christoph Berg wrote:
>
> Re: Richard Yen
>> Ah, thanks for the tip. That's right -- I can't assume the user's input is
>> a valid file. Updated patch here.
>
> Hi Richard,
>
> sorry for the very late response here.
>
> Thanks for the patch which I just merg
On Tue, Sep 28, 2021 at 2:49 AM Dilip Kumar wrote:
> 16k 64k 256k1024k
> Head 1232.779804.241134.723901.257
> Patch 1371.4931277.705862.598783.481
>
> So what I have noticed is that in most of th
So, I've wondered about this part all along:
> +/*
> + * Calculates the timestamp at which the next timer should expire and enables
> + * the timer accordingly.
> + */
> +static void
> +reset_startup_progress_timeout(TimestampTz now)
> +{
> + TimestampTz next_timeout;
> +
> + next_timeout
On Wed, Sep 29, 2021 at 10:08 AM Nitin Jadhav
wrote:
> Sorry. There was a misunderstanding about this and for the patch
> shared on September 27th, I had tested for the value '0' and observed
> that no progress messages were getting logged, probably the time at
> which 'enable_timeout_at' is getti
On Wed, Sep 29, 2021 at 1:36 PM Alvaro Herrera wrote:
> Why is it that we set the next timeout to fire not at "now + interval"
> but at "when-it-should-have-fired-but-didn't + interval"? As a user, if
> I request a message to be logged every N milliseconds, and one
> of them is a little bit delay
On Wed, Sep 29, 2021 at 02:36:14PM -0300, Alvaro Herrera wrote:
> Why is it that we set the next timeout to fire not at "now + interval"
> but at "when-it-should-have-fired-but-didn't + interval"? As a user, if
> I request a message to be logged every N milliseconds, and one
> of them is a little
On 2021-Sep-29, Robert Haas wrote:
> Well, this was my suggestion, because if you don't do this, you get
> drift, which I think looks weird. Like the timestamps will be:
>
> 13:41:05.012456
> 13:41:15.072484
> 13:41:25.149632
>
> ...and it gets further and further off as it goes on.'
Right ...
On 2021-Sep-29, Justin Pryzby wrote:
> Robert requested the current behavior here.
> https://www.postgresql.org/message-id/CA%2BTgmoYkS1ZeWdSMFMBecMNxWonHk6J5eoX4FEQrpKtvEbXqGQ%40mail.gmail.com
>
> It's confusing (at least) to get these kind of requests to change the behavior
> back and forth.
W
Alvaro Herrera writes:
> On 2021-Sep-29, Ranier Vilela wrote:
>> Em qua., 29 de set. de 2021 às 08:12, Drouvot, Bertrand
>> escreveu:
>> Duplicating functions is very bad for maintenance and bloats the code
>> unnecessarily, IMHO.
> Well, there are 42 calls of PushActiveSnapshot currently, and o
Alvaro Herrera writes:
> On 2021-Sep-29, Robert Haas wrote:
>> Well, this was my suggestion, because if you don't do this, you get
>> drift, which I think looks weird. Like the timestamps will be:
>>
>> 13:41:05.012456
>> 13:41:15.072484
>> 13:41:25.149632
>>
>> ...and it gets further and furthe
Em qua., 29 de set. de 2021 às 15:01, Tom Lane escreveu:
> Alvaro Herrera writes:
> > On 2021-Sep-29, Ranier Vilela wrote:
> >> Em qua., 29 de set. de 2021 às 08:12, Drouvot, Bertrand <
> bdrou...@amazon.com>
> >> escreveu:
> >> Duplicating functions is very bad for maintenance and bloats the co
System catalog indexes do not support deduplication as a matter of
policy. I chose to do things that way during the Postgres 13
development cycle due to the restriction on using storage parameters
with system catalog indexes. At the time I felt that *forcing* the use
of deduplication with system ca
On Mon, May 3, 2021 at 5:24 PM Melanie Plageman
wrote:
> On Thu, Jan 21, 2021 at 5:51 PM Andres Freund wrote:
> > On 2021-01-21 23:54:04 +0200, Heikki Linnakangas wrote:
> > > On 21/01/2021 22:36, Andres Freund wrote:
> > > >
> > > > Thinking through the correctness of replacing smgrimmedsync() w
On Wed, Sep 29, 2021 at 1:52 PM Alvaro Herrera wrote:
> I think one person casting an opinion on one aspect does not set that
> aspect in stone.
Of course not. I was just explaining that how the patch ended up like it did.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi,
I found a crash (segmentation fault) on jsonb.
This is the best I could do to reduce the query:
"""
select
75 as c1
from
public.pagg_tab_ml as ref_0,
lateral (select
ref_0.a as c5
from generate_series(1, 300) as sample_0
fetch first 78 rows only
) as subq
Em qua., 29 de set. de 2021 às 15:55, Jaime Casanova <
jcasa...@systemguards.com.ec> escreveu:
> Hi,
>
> I found a crash (segmentation fault) on jsonb.
> This is the best I could do to reduce the query:
>
> """
> select
> 75 as c1
> from
> public.pagg_tab_ml as ref_0,
> lateral (select
>
Jean-Christophe Arnu writes:
> [ empty_string_in_tsvector_v4.patch ]
I looked through this patch a bit. I don't agree with adding
these new error conditions to tsvector_setweight_by_filter and
tsvector_delete_arr. Those don't prevent bad lexemes from being
added to tsvectors, so AFAICS they can
Jaime Casanova writes:
> I found a crash (segmentation fault) on jsonb.
> This is the best I could do to reduce the query:
> """
> select
> 75 as c1
> from
> public.pagg_tab_ml as ref_0,
> lateral (select
> ref_0.a as c5
> from generate_series(1, 300) as sample_0
>
"Drouvot, Bertrand" writes:
> But make check is now failing on join_hash.sql, I have been able to
> repro with:
Oh, duh, should have thought a bit harder. createSubid is a sequential
subtransaction number; it's not the same as the as_level nesting level.
Probably the most effective way to hand
I wrote:
> I think this must be a memoize bug. AFAICS, nowhere in this query
> can we be processing a non-null JSONB value, so what are we doing
> in jsonb_hash? Something down-stack must have lost the information
> that the Datum is actually null.
After further inspection, "what are we doing in
On 9/29/21 4:00 PM, Tom Lane wrote:
> Jaime Casanova writes:
>> I found a crash (segmentation fault) on jsonb.
>> This is the best I could do to reduce the query:
>> """
>> select
>> 75 as c1
>> from
>> public.pagg_tab_ml as ref_0,
>> lateral (select
>> ref_0.a as c5
>>
Alvaro Herrera writes:
> Pushed. Watching for buildfarm fireworks now.
jacana didn't like it:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2021-09-29%2018%3A25%3A53
The relevant info seems to be
# Running: pg_basebackup -D
/home/pgrunner/bf/root/REL_14_STABLE/pgsql.build
On Mon, Sep 27, 2021 at 2:58 PM Melanie Plageman
wrote:
>
> On Fri, Sep 24, 2021 at 5:58 PM Melanie Plageman
> wrote:
> >
> > On Thu, Sep 23, 2021 at 5:05 PM Melanie Plageman
> > wrote:
> > The only remaining TODOs are described in the commit message.
> > most critical one is that the reset mess
On Thu, 30 Sept 2021 at 09:24, Tom Lane wrote:
> After further inspection, "what are we doing in jsonb_hash?" is
> indeed a relevant question, but it seems like it's a type mismatch
> not a nullness issue. EXPLAIN VERBOSE shows
I think you're right here. It should be hashing text. That seems to
On Wed, Sep 29, 2021 at 2:06 PM Tom Lane wrote:
> The real comment I'd have here, though, is that writing one-off
> code for this purpose is bad. If we have a need for a repetitive
> timeout, it'd be better to add the feature to timeout.c explicitly.
> That would probably also remove the need for
Tom Lane writes:
> [ a couple of random thoughts after quickly scanning this thread ... ]
>
> David Christensen writes:
>> I assume this would look something like:
>> ALTER TABLE foo ALTER CONSTRAINT my_fkey ON UPDATE CASCADE ON DELETE RESTRICT
>> with omitted referential_action implying prese
On 9/29/21 4:33 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Pushed. Watching for buildfarm fireworks now.
> jacana didn't like it:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2021-09-29%2018%3A25%3A53
>
> The relevant info seems to be
>
> # Running: pg_basebackup -
David Rowley writes:
> On Thu, 30 Sept 2021 at 09:24, Tom Lane wrote:
>> After further inspection, "what are we doing in jsonb_hash?" is
>> indeed a relevant question, but it seems like it's a type mismatch
>> not a nullness issue. EXPLAIN VERBOSE shows
> I think you're right here. It should be
Robert Haas writes:
> On Wed, Sep 29, 2021 at 2:06 PM Tom Lane wrote:
>> The real comment I'd have here, though, is that writing one-off
>> code for this purpose is bad. If we have a need for a repetitive
>> timeout, it'd be better to add the feature to timeout.c explicitly.
>> That would probab
On Thu, 30 Sept 2021 at 10:09, Tom Lane wrote:
>
> David Rowley writes:
> > Maybe we can cache the left and the right type's hash function and use
> > the correct one in paraminfo_get_equal_hashops().
>
> Um ... it seems to have correctly identified the cache key expressions,
> so why isn't it ju
David Rowley writes:
> On Thu, 30 Sept 2021 at 10:09, Tom Lane wrote:
>> Um ... it seems to have correctly identified the cache key expressions,
>> so why isn't it just doing exprType on those? The jsonb_exists operator
>> seems entirely irrelevant here.
> This is down to the caching stuff I ad
On 2021-Sep-29, Andrew Dunstan wrote:
> > The relevant info seems to be
> >
> > # Running: pg_basebackup -D
> > /home/pgrunner/bf/root/REL_14_STABLE/pgsql.build/src/test/recovery/tmp_check/t_026_overwrite_contrecord_primary2_data/backup/backup
> > -h 127.0.0.1 -p 59502 --checkpoint fast --no-syn
Andrew Dunstan writes:
> On 9/29/21 4:33 PM, Tom Lane wrote:
>> which looks like a pretty straightforward bogus-connection-configuration
>> problem, except why wouldn't other BF members show it?
> This:
> ...
> doesn't have "allows_streaming => 1".
Oh, and that only breaks things on Windows, cf
On Thu, 30 Sept 2021 at 10:20, Tom Lane wrote:
>
> David Rowley writes:
> > On Thu, 30 Sept 2021 at 10:09, Tom Lane wrote:
> >> Um ... it seems to have correctly identified the cache key expressions,
> >> so why isn't it just doing exprType on those? The jsonb_exists operator
> >> seems entirel
On 2021-Sep-29, Tom Lane wrote:
> ... although I wonder why the fact that sub init otherwise sets
> wal_level = minimal doesn't cause a problem for this test.
> Maybe the test script is cowboy-ishly overriding that?
It is. (I claim that it should be set otherwise when has_archiving=>1).
--
Álv
On 9/29/21 5:27 PM, Alvaro Herrera wrote:
> On 2021-Sep-29, Andrew Dunstan wrote:
>
>>> The relevant info seems to be
>>>
>>> # Running: pg_basebackup -D
>>> /home/pgrunner/bf/root/REL_14_STABLE/pgsql.build/src/test/recovery/tmp_check/t_026_overwrite_contrecord_primary2_data/backup/backup
>>> -
On Thu, 30 Sept 2021 at 09:48, David Rowley wrote:
> Maybe we can cache the left and the right type's hash function and use
> the correct one in paraminfo_get_equal_hashops().
Here's a patch of what I had in mind for the fix. It's just hot off
the press, so really only intended to assist discuss
David Rowley writes:
> On Thu, 30 Sept 2021 at 10:20, Tom Lane wrote:
>> I'm still confused. AFAICS, the top-level operator of the qual clause has
>> exactly nada to do with the cache keys, as this example makes plain.
> You're right that it does not. The lateral join condition could be
> anyth
Hello, Antonin.
> I'm trying to continue the review, sorry for the delay. Following are a few
> question about the code:
Thanks for the review :) And sorry for the delay too :)
> * Does the masking need to happen in the AM code, e.g. _bt_killitems()?
> I'd expect that the RmgrData.rm_fpi_mask
I wrote:
> So I'm now thinking you weren't that far wrong to be looking at
> hashability of the top-level qual operator. What is missing is
> that you have to restrict candidate cache keys to be the *direct*
> arguments of such an operator. Looking any further down in the
> expression introduces
On Wed, Sep 29, 2021 at 11:27 AM Peter Geoghegan wrote:
> I would like to enable deduplication within system catalog indexes for
> Postgres 15.
I decided to run a simple experiment, to give us some idea of what
benefits my proposal gives users: I ran "make installcheck" on a newly
initdb'd databa
On Thu, 30 Sept 2021 at 11:20, Tom Lane wrote:
>
> I wrote:
> > So I'm now thinking you weren't that far wrong to be looking at
> > hashability of the top-level qual operator. What is missing is
> > that you have to restrict candidate cache keys to be the *direct*
> > arguments of such an operato
Andrew Dunstan writes:
> On 9/29/21 5:27 PM, Alvaro Herrera wrote:
>> So, do we take the stance that we have no right to expect pg_basebackup
>> to work if we didn't pass allow_streaming => 1? If so, the fix is to
>> add it. But my preferred fix would be to call set_replication_conf if
>> either
David Rowley writes:
> On Thu, 30 Sept 2021 at 11:20, Tom Lane wrote:
>> Hmm ... I think that actually, a correct statement of the semantic
>> restriction is
>> To be eligible for memoization, the inside of a join can use the
>> passed-in parameters *only* as direct arguments of hashable equality
At Mon, 27 Sep 2021 17:31:03 +1300, Thomas Munro wrote
in
> On Thu, Jul 15, 2021 at 4:48 PM Kyotaro Horiguchi
> wrote:
> > Gah... Thank you for noticing me. I thought that I have sent the
> > rebased version. This is the rebased version on the current master.
>
> Hi Kyotaro,
>
> Did you see
Forking this thread in which Thomas implemented syncfs for the startup process
(61752afb2).
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BSG9jSW3ekwib0cSdC0yD-jReJ21X4bZAmqxoWTLTc2A%40mail.gmail.com
Is there any reason that initdb/pg_basebackup/pg_checksums/pg_rewind shouldn't
use syncfs(
On Wed, Aug 25, 2021 at 04:16:08PM +0900, Michael Paquier wrote:
> I was just looking at your patch, and I think that you should move all
> the past compatibility tests into a separate test file, in a way
> consistent to what we do in contrib/pageinspect/ for
> oldextversions.sql. I would suggest
On Wed, Sep 29, 2021 at 10:14 PM Teodor Sigaev wrote:
>
> Nice feature, but, sorry, I see some design problem in suggested feature.
> AFAIK,
> there is two use cases for this feature:
> 1 A permission / prohibition to login some users
> 2 Just a logging of facts of user's login
>
> Suggested patc
On Wed, Sep 29, 2021 at 8:55 PM Amit Kapila wrote:
>
> On Wed, Sep 29, 2021 at 4:49 PM Masahiko Sawada wrote:
> >
> > On Tue, Sep 28, 2021 at 7:04 PM Amit Kapila wrote:
> > >
> > > On Tue, Sep 28, 2021 at 11:35 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Tue, Sep 28, 2021 at 1:54 PM Ami
On Wed, Sep 29, 2021 at 5:48 PM houzj.f...@fujitsu.com
wrote:
>
> On Wed, Sep 29, 2021 5:14 PM Amit Kapila wrote:
> > On Wed, Sep 29, 2021 at 11:59 AM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > On Wed, Sep 29, 2021 12:34 PM Amit Kapila
> > > > On Wed, Sep 29, 2021 at 9:07 AM houzj.f...@fujit
On Thu, Sep 30, 2021 at 8:18 AM Masahiko Sawada wrote:
>
> On Wed, Sep 29, 2021 at 8:55 PM Amit Kapila wrote:
> >
> > On Wed, Sep 29, 2021 at 4:49 PM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Sep 28, 2021 at 7:04 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Tue, Sep 28, 2021 at 11:35 A
>Thank you for your feedback.
>I might have added whitespace when I was checking the patch file.
>I attach a new patch to this mail.
Thank you for the update!
> else if (Matches("LOCK", MatchAny, "IN", "ACCESS|ROW") ||
>- Matches("LOCK", "TABLE", MatchAny, "IN", "ACCESS
On Wed, Sep 29, 2021 at 07:43:41PM -0500, Justin Pryzby wrote:
> Forking this thread in which Thomas implemented syncfs for the startup process
> (61752afb2).
> https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BSG9jSW3ekwib0cSdC0yD-jReJ21X4bZAmqxoWTLTc2A%40mail.gmail.com
>
> Is there any reas
On Thu, Sep 30, 2021 at 4:49 PM Michael Paquier wrote:
> fsync_pgdata() is going to manipulate many inodes anyway, because
> that's a code path designed to do so. If we know that syncfs() is
> just going to be better, I'd rather just call it by default if
> available and not add new switches to a
On Thu, Sep 30, 2021 at 8:22 AM Hou, Zhijie/侯 志杰 wrote:
>
> On Tues, Sep 28, 2021 6:05 PM Amit Kapila wrote:
> >
> > Can't we keep the current and new stats both in-memory and persist on
> > disk? So, the persistent stats data will be used to fill the in-memory
> > counters after restarting of wo
On Wed, Sep 29, 2021 at 9:29 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Wed, Sep 29, 2021 at 3:47 AM Tom Lane wrote:
> >> It seems to me that for most purposes wait_for_catchup's approach is
> >> strictly worse, for two reasons:
> >> 1. It continually recomputes the primary's pg_current_w
On Mon, Sep 27, 2021 at 2:55 PM Amit Kapila wrote:
>
> On Mon, Sep 27, 2021 at 11:02 AM Masahiko Sawada
> wrote:
> >
> > On Mon, Sep 27, 2021 at 12:50 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Sep 27, 2021 at 12:24 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Mon, Sep 27, 2021 at 6
On Thu, Sep 30, 2021 at 8:49 AM Hou, Zhijie/侯 志杰 wrote:
>
> I noticed another patch that Horiguchi-San posted earlier[1].
>
> The approach in that patch is to splits the sleep into two
> pieces. If the first sleep reaches the timeout then send a keepalive
> then sleep for the remaining time.
>
> I
On Thu, Sep 30, 2021 at 3:56 PM Amit Kapila wrote:
>
> I am not able to understand some parts of that patch.
>
> + If the sleep is shorter
> + * than KEEPALIVE_TIMEOUT milliseconds, we skip sending a keepalive to
> + * prevent it from getting too-frequent.
> + */
> + if (MyWalSnd->flush < sentPtr
Hello Takahashi-san,
On Wed, 22 Sep 2021 18:53:43 +0900
Yugo NAGATA wrote:
> Hello Takahashi-san,
>
> On Thu, 5 Aug 2021 08:53:47 +
> "r.takahash...@fujitsu.com" wrote:
>
> > Hi Nagata-san,
> >
> >
> > Thank you for your reply.
> >
> > > I'll investigate this more, but we may have to p
Today, I noticed that we have mentioned pg_stat_replication_slots
under "Dynamic Statistics Views". I think it should be under
"Collected Statistics Views"?
--
With Regards,
Amit Kapila.
fix_pg_stat_replication_slots_doc.patch
Description: Binary data
On Thu, Sep 30, 2021 at 05:08:24PM +1300, Thomas Munro wrote:
> If we want this it should be an option, because it flushes out data
> other than the pgdata dir, and it doesn't report errors on old
> kernels.
Oh, OK, thanks. That's the part about 5.8. The only option
controlling if sync is used n
87 matches
Mail list logo
