On Wed, Nov 17, 2021 at 3:52 PM vignesh C wrote:
>
> On Tue, Nov 16, 2021 at 12:01 PM Masahiko Sawada
> wrote:
> >
> > On Mon, Nov 15, 2021 at 11:43 PM vignesh C wrote:
> > >
> > > On Mon, Nov 15, 2021 at 2:48 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Mon, Nov 15, 2021 at 4:49 PM Gre
On Tue, Nov 16, 2021 at 8:45 PM Amit Kapila wrote:
>
> On Mon, Nov 15, 2021 at 12:38 PM Masahiko Sawada
> wrote:
> >
> > I've updated the patch so that ProcArrayInstallRestoredXmin() sets
> > both xmin and statusFlags only when the source proc is still running
> > and xmin doesn't go backwards.
On Wed, Nov 17, 2021 at 10:44:44AM +0900, Ken Kato wrote:
> I made a patch for this, so please have a look.
+ else if (Matches("CREATE", "TRANSFORM", "FOR", MatchAny)
+ COMPLETE_WITH("LANGUAGE")
+ else if (Matches("CREATE", "TRANSFORM", "FOR", MatchAny, "LANGUAGE")
Those
On Sun, Nov 07, 2021 at 01:22:00PM -0600, Justin Pryzby wrote:
> That may be good enough for test.sh, but if the kludges were moved to a .sql
> script which was also run by the buildfarm (in stead of its hardcoded
> kludges), then
> it might be necessary to handle the additional stuff my patch did
On Tue, Nov 16, 2021 at 12:01 PM Masahiko Sawada wrote:
>
> On Mon, Nov 15, 2021 at 11:43 PM vignesh C wrote:
> >
> > On Mon, Nov 15, 2021 at 2:48 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Nov 15, 2021 at 4:49 PM Greg Nancarrow
> > > wrote:
> > > >
> > > > On Mon, Nov 15, 2021 at 1:49
po 15. 11. 2021 v 21:23 odesílatel Justin Pryzby
napsal:
> On Mon, Nov 15, 2021 at 09:00:13PM +0100, Pavel Stehule wrote:
> > Thank you for review and fixes, I try to complete some version for next
> > work, and looks so your patch 0001 is broken
> >
> > gedit reports to me broken unicode \A0\A0\
On Wed, Nov 17, 2021 at 12:15 PM houzj.f...@fujitsu.com
wrote:
> On Wed, Nov 17, 2021 10:47 AM Amit Kapila wrote:
> > On Tue, Nov 16, 2021 at 7:21 AM houzj.f...@fujitsu.com wrote:
> > > If we decide to disallow this case, we seem need to handle some other
> > > cases as well, for example: We migh
On Tue, Nov 16, 2021 at 10:27 PM Amit Kapila wrote:
> On Mon, Nov 15, 2021 at 7:12 PM Alvaro Herrera
> wrote:
> > > On Mon, Nov 15, 2021 at 1:48 PM houzj.f...@fujitsu.com
> > > wrote:
> >
> > > > create table tbl1 (a int) partition by range (a);
> > > > create table tbl1_part1 partition of tbl1
> Are you using recent sources? The isolationtester's output hasn't
> looked like that since June (4a054069a et al).
>
> regards, tom lane
I am coding with "Stamp 14beta2" which are very close to have 4a054069a.
I have tried the newer version, the issue here is fixed perfe
On Wed, Nov 17, 2021 at 1:58 PM Amit Kapila wrote:
>
> On Wed, Nov 17, 2021 at 9:13 AM houzj.f...@fujitsu.com
> wrote:
> >
> > On Tues, Nov 16, 2021 2:31 PM Masahiko Sawada wrote:
> >
> > 2)
> > +
> > +
> > + subrelid oid
> > +
> > +
> > + OID of the relation t
On Sat, Nov 13, 2021 at 2:18 AM Robert Haas wrote:
>
> On Mon, Nov 8, 2021 at 8:20 AM Amul Sul wrote:
> > Attached is the rebased version of refactoring as well as the
> > pg_prohibit_wal feature patches for the latest master head (commit #
> > 39a3105678a).
>
> I spent a lot of time today studyi
Hi hackers!
$subj was recently observed on one of our installations.
Startup process backtrace
#0 0x7fd216660d27 in epoll_wait (epfd=525, events=0x55c688dfbde8,
maxevents=maxevents@entry=1, timeout=timeout@entry=-1)
#1 0x55c687264be9 in WaitEventSetWaitBlock (nevents=1,
occurred_event
On Tue, Nov 16, 2021 at 10:26:11PM -0500, Tom Lane wrote:
> I feel like doing an immediate exit() for these errors and not other
> ones is a pretty terrible idea, mainly because it doesn't account for
> the question of what to do with a failure that prevents us from getting
> to the fsync() call in
On Wed, Nov 17, 2021 at 9:13 AM houzj.f...@fujitsu.com
wrote:
>
> On Tues, Nov 16, 2021 2:31 PM Masahiko Sawada wrote:
>
> 2)
> +
> +
> + subrelid oid
> +
> +
> + OID of the relation that the worker is synchronizing; null for the
> + main apply worker
> +
On Wednesday, November 17, 2021 12:19 PM Masahiko Sawada
wrote:
> On Tue, Nov 16, 2021 at 9:34 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Monday, November 15, 2021 9:14 PM I wrote:
> > > I've conducted some update for this.
> > > (The rebased part is only C code and checked by pgindent)
On Wed, 2021-11-03 at 12:50 -0700, Mark Dilger wrote:
> The first two patches are virtually unchanged. The third updates the
> behavior of the apply workers, and updates the documentation to
> match.
v2-0001 corrects some surprises, but may create others. Why is renaming
allowed, but not changing
Kuroda-san,
On Thu, Nov 11, 2021 at 11:27 AM kuroda.hay...@fujitsu.com
wrote:
> I love your proposal because it will remove a bottleneck
> for PostgreSQL build-in sharding.
>
> I read your patch briefly and I think basically it's good.
Great! Thanks for reviewing!
> Currently I have only one c
On Wed, Nov 17, 2021 at 7:36 AM Michael Paquier wrote:
>
> On Tue, Nov 16, 2021 at 02:08:54AM -0500, Tom Lane wrote:
> > I think LastRec was originally referenced by multiple functions
> > in xlog.c. But it does look like it could be a local now.
>
> Thanks for double-checking, applied this one a
On Tues, Nov 16, 2021 2:31 PM Masahiko Sawada wrote:
> Right. I've fixed this issue and attached an updated patch.
Hi,
Thanks for updating the patch.
Here are few comments.
1)
+pg_stat_reset_subscription_worker (
subid oid,
relid oid )
It seems we should put '' before the comma(',
Michael Paquier writes:
> Taking the issues with fsync() aside, which could be improved as a
> separate patch, is there anything I can do for this thread? The error
> handling problems in walmethods.c introduced by the integration of LZ4
> are on me, so I'd like to fix it. 0002 depends on some p
On Tue, Nov 16, 2021 at 9:34 PM osumi.takami...@fujitsu.com
wrote:
>
> On Monday, November 15, 2021 9:14 PM I wrote:
> > I've conducted some update for this.
> > (The rebased part is only C code and checked by pgindent)
> I'll update my patches since a new skip xid patch
> has been shared in [1].
On Wed, Nov 17, 2021 10:47 AM Amit Kapila wrote:
> On Tue, Nov 16, 2021 at 7:21 AM houzj.f...@fujitsu.com
> wrote:
> >
> > On Mon, Nov 15, 2021 9:42 PM Alvaro Herrera
> wrote:
> > > > On Mon, Nov 15, 2021 at 1:48 PM houzj.f...@fujitsu.com
> > > > wrote:
> > >
> > > > > create table tbl1 (a int)
On Tue, Nov 16, 2021 at 7:21 AM houzj.f...@fujitsu.com
wrote:
>
> On Mon, Nov 15, 2021 9:42 PM Alvaro Herrera wrote:
> > > On Mon, Nov 15, 2021 at 1:48 PM houzj.f...@fujitsu.com
> > > wrote:
> >
> > > > create table tbl1 (a int) partition by range (a); create table
> > > > tbl1_part1 partition o
On Wed, Nov 10, 2021 at 02:03:11PM +0900, Michael Paquier wrote:
>> but this code seems about as fishy and ill-thought-out as anything
>> else I've touched here. Why is this different from the half-dozen
>> other fsync-error cases in the same file? Why, if fsync failure
>> here is so catastrophic
On Tue, Nov 16, 2021 at 01:26:49PM -0300, Alvaro Herrera wrote:
> My opinion is that adding these things willy-nilly is not a solution to
> any actual problem. Adding a few additional log lines that are
> low-volume at DEBUG1 might be useful, but below that (DEBUG2 etc) it's
> not good for anythin
On Tue, Nov 16, 2021 at 09:34:25AM +0530, Bharath Rupireddy wrote:
> It looks okay to be more responsive with the -f option so that the
> above commands keep emitting stats for every 1 second(the --follow
> option waits for 1 second). Should we really be emitting stats for
> every 1 second? Isn't t
On Tue, Nov 16, 2021 at 02:08:54AM -0500, Tom Lane wrote:
> I think LastRec was originally referenced by multiple functions
> in xlog.c. But it does look like it could be a local now.
Thanks for double-checking, applied this one as of f975fc3.
--
Michael
signature.asc
Description: PGP signature
Andy Fan writes:
> I'm using the isolation test to write some tests, and then I found the
> output is unclear some time.
> for example:
> a b c
> 1988-12-14 01:03:031988-12-13 22:03:03-011988-12-14
Are you using recent sources? The isolationtester's output hasn't
looke
Hi hackers,
I noticed that there are some tab completions missing for the following
commands:
-CREATE CONVERSION : missing FOR, TO, FROM
-CREATE DOMAIN : missing after AS
-CREATE LANGUAGE : missing after HANDLER
-CREATE SCHEMA : missing AUTHORIZATION, IF NOT EXISTS
-CREATE SEQUENCE : missing AS
Hi:
I'm using the isolation test to write some tests, and then I found the
output is unclear some time.
for example:
a b c
1988-12-14 01:03:031988-12-13 22:03:03-011988-12-14
Actually what I want is there are some spaces among the fields. like:
a b
On Tue, Nov 16, 2021 at 7:33 PM tanghy.f...@fujitsu.com
wrote:
>
> The second record can’t be replicated.
>
> By the way, when only applied 0001 patch, I couldn't reproduce this bug.
> So, I think it was related to the later patches.
>
The problem seems to be caused by the 0006 patch (when I remo
> On Nov 16, 2021, at 2:12 PM, Tom Lane wrote:
>
> BTW, another objection to pg_config_param as designed here is that
> a "name" is not an appropriate way to store possibly-qualified
> custom GUC names. It's not long enough (cf. valid_custom_variable_name).
I was aware of that, but figured n
> On Nov 16, 2021, at 2:12 PM, Tom Lane wrote:
>
> The question is why you need pg_config_param at all, then.
> AFAICS it just adds maintenance complexity we could do without.
> I think we'd be better off with a catalog modeled on the design of
> pg_db_role_setting, which would have entries fo
Mark Dilger writes:
> The patch already posted on this thread already works that way. Robert and
> Tom seemed to infer that all gucs need to be present in the catalog, but in
> fact, not entering them in the catalog simply means that they aren't
> grantable. I think the confusion arose from t
On 2021-11-16 16:30:27 -0500, Robert Haas wrote:
> I'm still not entirely clear on whether you prefer v1-0002, v2-0002,
> or something else.
I think it basically doesn't matter much. It's such a small piece of the cost
compared to either the cost of a single insert or the ratio between
RedoRecPtr/
On Mon, Nov 15, 2021 at 2:23 PM Robert Haas wrote:
> Yeah, that's what it should be doing. I'll commit a fix, thanks for
> the report and diagnosis.
Here's a new patch set.
0001 - When I committed the patch to add the missing 2 blocks of zero
bytes to the tar archives generated by the server, I
On Tue, Nov 16, 2021 at 3:42 PM Andres Freund wrote:
> On 2021-11-16 15:19:19 -0500, Robert Haas wrote:
> > > Hm. I think this might included a bunch of convoluting factors that make
> > > it
> > > hard to judge the actual size of the performance difference.
> >
> > Yes, I think so, too.
>
> FWIW
> On Nov 16, 2021, at 12:38 PM, Andrew Dunstan wrote:
>
> Your original and fairly simple set of patches used hardcoded role names
> and sets of GUCs they could update via ALTER SYSTEM. I suggested to you
> privately that a more flexible approach would be to drive this from a
> catalog table.
Hi,
On 2021-11-16 15:19:19 -0500, Robert Haas wrote:
> > Hm. I think this might included a bunch of convoluting factors that make it
> > hard to judge the actual size of the performance difference.
>
> Yes, I think so, too.
FWIW I ran that pgench thing I presented upthread, and I didn't see any
On 11/16/21 15:08, Mark Dilger wrote:
>
>> On Nov 16, 2021, at 12:06 PM, Andrew Dunstan wrote:
>>
>> There doesn't seem to be a CF item for it but I'm
>> inclined to commit it in a couple of days time.
> https://commitfest.postgresql.org/36/3414/
>
OK, got it, thanks.
cheers
andrew
--
Andr
On 11/16/21 14:48, Mark Dilger wrote:
>
>> On Nov 16, 2021, at 8:44 AM, Tom Lane wrote:
>>
>> My concern is not about performance, it's about the difficulty of
>> maintaining a catalog that expects to be a more-or-less exhaustive
>> list of GUCs. I think you need to get rid of that expectation.
On Tue, Nov 16, 2021 at 2:27 PM Andres Freund wrote:
> Is this with assertions enabled? Because on my workstation (which likely is
> slower on a single-core basis than your laptop) I get around half of this with
> an optimized build (and a non-optimized build rarely is worth using as a
> measuring
Greetings,
On Tue, Nov 16, 2021 at 15:12 Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2021-Nov-16, Stephen Frost wrote:
> >> Not against possibly changing that but I don’t get the point of
> including
> >> be-gssapi-common.h if it’s not enabled in the build and typically if
> GSSAPI
> >> is
Alvaro Herrera writes:
> On 2021-Nov-16, Stephen Frost wrote:
>> Not against possibly changing that but I don’t get the point of including
>> be-gssapi-common.h if it’s not enabled in the build and typically if GSSAPI
>> is possible and the reason for including be-gssapi-common.h then there’s
>> o
> On Nov 16, 2021, at 12:06 PM, Andrew Dunstan wrote:
>
> There doesn't seem to be a CF item for it but I'm
> inclined to commit it in a couple of days time.
https://commitfest.postgresql.org/36/3414/
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 11/3/21 15:50, Mark Dilger wrote:
>> On Nov 1, 2021, at 10:58 AM, Mark Dilger
>> wrote:
>>
>> ALTER SUBSCRIPTION..[ENABLE | DISABLE] do not synchronously start or stop
>> subscription workers. The ALTER command updates the catalog's subenabled
>> field, but workers only lazily respond to
> On Nov 16, 2021, at 8:44 AM, Tom Lane wrote:
>
> My concern is not about performance, it's about the difficulty of
> maintaining a catalog that expects to be a more-or-less exhaustive
> list of GUCs. I think you need to get rid of that expectation.
I'm preparing a new version of the patch
Hi,
On 2021-11-15 16:29:28 -0500, Robert Haas wrote:
> v1: 0.378 ms
> v2: 0.391 ms
> common base commit (10eae82b2): 0.376 ms
Is this with assertions enabled? Because on my workstation (which likely is
slower on a single-core basis than your laptop) I get around half of this with
an optimized bui
Greetings,
On Tue, Nov 16, 2021 at 13:16 Alvaro Herrera
wrote:
> On 2021-Nov-16, Stephen Frost wrote:
>
> > Not against possibly changing that but I don’t get the point of including
> > be-gssapi-common.h if it’s not enabled in the build and typically if
> GSSAPI
> > is possible and the reason f
Hi,
On 2021-11-11 12:15:03 -0500, Robert Haas wrote:
> The reason why RecoveryInProgress() has critical side effects is that
> it calls InitXLOGAccess(). It turns out that the only critical thing
> that InitXLOGAccess() does is call InitXLogInsert().[1] If a backend
> doesn't call InitXLogInsert()
On Tue, Nov 16, 2021 at 9:45 AM Joshua Brindle
wrote:
>
> On Mon, Nov 15, 2021 at 5:37 PM Joshua Brindle
> wrote:
> >
> > On Mon, Nov 15, 2021 at 4:44 PM Daniel Gustafsson wrote:
> > >
> > > > On 15 Nov 2021, at 20:51, Joshua Brindle
> > > > wrote:
> > >
> > > > Apologies for the delay, this d
On 2021-Nov-16, Stephen Frost wrote:
> Not against possibly changing that but I don’t get the point of including
> be-gssapi-common.h if it’s not enabled in the build and typically if GSSAPI
> is possible and the reason for including be-gssapi-common.h then there’s
> other things that need to be u
> On Nov 16, 2021, at 10:08 AM, Jeff Davis wrote:
>
> On Mon, 2021-11-01 at 10:58 -0700, Mark Dilger wrote:
>> It is unclear .
>>
>> Thoughts?
>
> What if we just say that OWNER TO must be done by a superuser, changing
> from one superuser to another, just like today? That would preserve
On Mon, 2021-11-01 at 10:58 -0700, Mark Dilger wrote:
> It is unclear that I can make ALTER SUBSCRIPTION..OWNER TO
> synchronous without redesigning the way workers respond to
> pg_subscription catalog updates generally. That may be a good
> project to eventually tackle, but I don't see that it is
On 2021-Nov-16, Stephen Frost wrote:
> I’ve not looked at this very closely but no, normally it’s the inclusion of
> be-gssapi-common.h that’s wrapped in the ifdef, not the contents of it,
> again, see auth.c
I don't think you read my original post very carefully. I'm talking
about sanitizing th
Greetings,
On Tue, Nov 16, 2021 at 12:33 Alvaro Herrera
wrote:
> On 2021-Nov-16, Stephen Frost wrote:
>
> > Short answer is yes, inclusion of be-gssapi-common.h is typically
> > wrapped in a #ifdef, see src/backend/libpq/auth.c
>
> It'd be as in the attached, then.
I’ve not looked at this very
Hi! It’s been a while since the original patch release. Let me provide a brief
overview of the current patch status.
The initial approach was to use the streaming compression to compress all
outgoing and decompress all incoming bytes. However, after the long discussion
in the thread, the initia
On 2021-Nov-16, Stephen Frost wrote:
> Short answer is yes, inclusion of be-gssapi-common.h is typically
> wrapped in a #ifdef, see src/backend/libpq/auth.c
It'd be as in the attached, then.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
>From db4a303a8a7c0c142
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> On 2021-Nov-16, Alvaro Herrera wrote:
>
> > Fix headerscheck failure in replication/worker_internal.h
>
> The other failure is in src/include/libpq/be-gssapi-common.h:
>
> In file included from /tmp/headerscheck.a6f0um/test.c:2:
> .
On 2021-Nov-16, Alvaro Herrera wrote:
> Fix headerscheck failure in replication/worker_internal.h
The other failure is in src/include/libpq/be-gssapi-common.h:
In file included from /tmp/headerscheck.a6f0um/test.c:2:
./src/include/libpq/be-gssapi-common.h:20:10: fatal error: gssapi/gssapi.h: No
Mark Dilger writes:
> On Nov 16, 2021, at 7:28 AM, Tom Lane wrote:
>> True; as long as the expectation is that entries will exist for only
>> a tiny subset of GUCs, it's probably fine.
> I understand that bloating a frequently used catalog can be pretty
> harmful to performance. I wasn't aware
Mark Dilger writes:
> You are talking about mismatches in the other direction, aren't you? I was
> responding to Robert's point that new gucs could appear, and old gucs
> disappear. That seems analogous to new functions appearing and old functions
> disappearing. If you upgrade (not downgrad
On 2021-Nov-16, Bossart, Nathan wrote:
> On 11/15/21, 7:14 PM, "Michael Paquier" wrote:
> > + ereport(DEBUG1,
> > + (errmsg_internal("streaming %X/%X",
> > +
> > LSN_FORMAT_ARGS(sentPtr;
> > Anyway, those two
On 11/14/21 21:24, Tom Lane wrote:
> ... btw, there's a fairly critical gating factor for any plan to drop
> python2 support: the buildfarm. I just counted, and there are exactly
> as many members running python 2.x as 3.x (49 apiece), not counting
> Windows machines that aren't running configur
Hi Amit
On 2021-Nov-16, Amit Langote wrote:
> AFAICS, MERGE operating on an inheritance parent that is not
> partitioned should work mostly the same as the case where it is
> partitioned (good thing that it works at all without needing any
> special code!), though only the INSERT actions would ha
On Tue, Nov 16, 2021 at 10:45 AM Mark Dilger
wrote:
> You are talking about mismatches in the other direction, aren't you? I was
> responding to Robert's point that new gucs could appear, and old gucs
> disappear. That seems analogous to new functions appearing and old functions
> disappearin
On 11/15/21 14:14, Tom Lane wrote:
> =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
>> Tom Lane writes:
>>> Based on this, I'm inclined to think we should select 0.98 as the
>>> minimum version. Anything later would inconvenience some people.
>>> OTOH, it doesn't look like there's any value
On 11/15/21, 7:14 PM, "Michael Paquier" wrote:
> + ereport(DEBUG1,
> + (errmsg_internal("streaming %X/%X",
> +
> LSN_FORMAT_ARGS(sentPtr;
> Anyway, those two ones are going to make the logs much more noisy, no
> On Nov 16, 2021, at 7:28 AM, Tom Lane wrote:
>
> True; as long as the expectation is that entries will exist for only
> a tiny subset of GUCs, it's probably fine.
I understand that bloating a frequently used catalog can be pretty harmful to
performance. I wasn't aware that the size of an
> On Nov 16, 2021, at 7:32 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> I don't think we support using a .so that is mismatched against the
>> version of the extension that is installed.
>
> You are entirely mistaken. That's not only "supported", it's *required*.
> Consider binary upgrade
Mark Dilger writes:
> I don't think we support using a .so that is mismatched against the
> version of the extension that is installed.
You are entirely mistaken. That's not only "supported", it's *required*.
Consider binary upgrades, where the SQL objects are transferred as-is
but the receiving
Robert Haas writes:
> On Tue, Nov 16, 2021 at 10:17 AM Tom Lane wrote:
>> Right. I think that any design that involves per-GUC catalog entries
>> is going to be an abysmal failure, precisely because the set of GUCs
>> is not stable enough.
> In practice it's pretty stable. I think it's just a m
> On Nov 16, 2021, at 7:03 AM, Robert Haas wrote:
>
> It's also going to be important to think about what happens with
> extension GUCs. If somebody installs an extension, we can't ask them
> to perform a manual step in order to be able to grant privileges.
The burden isn't on the installer o
On Tue, Nov 16, 2021 at 10:17 AM Tom Lane wrote:
> Right. I think that any design that involves per-GUC catalog entries
> is going to be an abysmal failure, precisely because the set of GUCs
> is not stable enough.
In practice it's pretty stable. I think it's just a matter of having a
plan that
On Mon, Nov 15, 2021 at 10:02 PM Michael Paquier wrote:
> On Mon, Nov 15, 2021 at 02:40:10PM -0500, Robert Haas wrote:
> > Having different frontend utilities each invent their own
> > slightly-different way of doing this makes it hard to reuse code, and
> > hard to understand code. We need to fin
Robert Haas writes:
> It's also going to be important to think about what happens with
> extension GUCs. If somebody installs an extension, we can't ask them
> to perform a manual step in order to be able to grant privileges. And
> if somebody then loads up a different .so for that extension, the
On Mon, Nov 15, 2021 at 4:12 PM Tom Lane wrote:
> > It'd only be an issue if they want to compile from source, right?
> > We're not speaking of changing the runtime prerequisites, IIUC.
>
> I'm not sure. Does it make sense to document that pl/python has
> a different Python version requirement th
On Mon, Nov 15, 2021 at 3:37 PM Mark Dilger
wrote:
> One disadvantage of this approach is that the GUC variables are represented
> both in the list of C structures in guc.c and in the new system catalog
> pg_config_param's .dat file. Failure to enter a GUC in the .dat file will
> result in the
On Mon, Nov 15, 2021 at 5:37 PM Joshua Brindle
wrote:
>
> On Mon, Nov 15, 2021 at 4:44 PM Daniel Gustafsson wrote:
> >
> > > On 15 Nov 2021, at 20:51, Joshua Brindle
> > > wrote:
> >
> > > Apologies for the delay, this didn't go to my inbox and I missed it on
> > > list.
> > >
> > > The bitcod
On Mon, Nov 15, 2021 at 9:34 PM Michael Paquier wrote:
> Patch 0001 means that the startup process would set up the structures
> to be able to build WAL records before running any kind of recovery
> action rather than doing it when it really needs it. That's fine by
> me.
Great, thanks. I think
> On Nov 16, 2021, at 6:31 AM, Daniel Gustafsson wrote:
>
>> On 16 Nov 2021, at 00:58, Mark Dilger wrote:
>
>> While working on a fix for dangling references to dropped roles in the
>> pg_auth_members.grantor field, I happened to notice we entirely lack
>> regression test coverage of the R
> On 16 Nov 2021, at 00:58, Mark Dilger wrote:
> While working on a fix for dangling references to dropped roles in the
> pg_auth_members.grantor field, I happened to notice we entirely lack
> regression test coverage of the REVOKE ADMIN OPTION FOR form of the
> RevokeRoleStmt. I am unaware o
> On 16 Nov 2021, at 15:04, Daniel Gustafsson wrote:
> ..or should the attached small diff be applied to fix it?
Actually it shouldn't, I realized when hitting Send that it was the wrong
version. The attached is the proposed diff.
--
Daniel Gustafsson https://vmware.com/
grant
> On 30 Jan 2021, at 09:51, Peter Eisentraut
> wrote:
>
> On 2020-12-30 13:43, Simon Riggs wrote:
>> On Thu, 10 Dec 2020 at 18:40, Peter Eisentraut
>> wrote:
>>>
>>> On 2020-06-24 20:21, Peter Eisentraut wrote:
On 2020-06-24 10:12, Vik Fearing wrote:
> On 6/24/20 8:35 AM, Peter Eisent
On Mon, Nov 15, 2021 at 7:12 PM Alvaro Herrera wrote:
>
> > On Mon, Nov 15, 2021 at 1:48 PM houzj.f...@fujitsu.com
> > wrote:
>
> > > create table tbl1 (a int) partition by range (a);
> > > create table tbl1_part1 partition of tbl1 for values from (1) to (10);
> > > create table tbl1_part2 partit
> On 15 Nov 2021, at 23:29, Peter Smith wrote:
> I noticed recently that the CREATE PUBLICATION docs page [1] does not
> have any "See Also" reference to the CREATE SUBSCRIPTION docs page
> [2].
Nice catch.
>
>
>
> +
To make it analogous with how CREATE/ALTER for SUBSCRIPTION and
On Monday, November 15, 2021 9:14 PM I wrote:
> I've conducted some update for this.
> (The rebased part is only C code and checked by pgindent)
I'll update my patches since a new skip xid patch
has been shared in [1].
This version includes some minor renames of functions
that are related to trans
> On 15 Nov 2021, at 11:50, Simon Riggs wrote:
> I have no plans on taking this patch further, but will give some help
> to anyone that wishes to do that.
>
> I suggest we Return with Feedback.
Fair enough, done that way.
--
Daniel Gustafsson https://vmware.com/
On Mon, Nov 15, 2021 at 7:20 AM houzj.f...@fujitsu.com
wrote:
>
> On Sat, Nov 13, 2021 6:50 PM Amit Kapila wrote:
> >
> > The patch looks mostly good to me. I have slightly tweaked the comments in
> > the code (as per my previous suggestion) and test. Also, I have slightly
> > modified the commit
On 2021-11-15 23:15, Bharath Rupireddy wrote:
I have another comment: isn't it a good idea that an overloaded
version of the new function pg_log_query_plan can take the available
explain command options as a text argument? I'm not sure if it is
possible to get the stats like buffers, costs etc o
On Mon, Nov 15, 2021 at 12:38 PM Masahiko Sawada wrote:
>
> I've updated the patch so that ProcArrayInstallRestoredXmin() sets
> both xmin and statusFlags only when the source proc is still running
> and xmin doesn't go backwards. IOW it doesn't happen that only one of
> them is set by this functi
On Mon, 15 Nov 2021 at 12:40, Dilip Kumar wrote:
>
> On Mon, Nov 15, 2021 at 4:46 PM Rafia Sabih wrote:
> >
> > On Mon, 15 Nov 2021 at 10:24, Dilip Kumar wrote:
> > >
> > > On Wed, Nov 10, 2021 at 1:47 PM Rafia Sabih
> > > wrote:
> > > >
> > > > > It seems that in beentry->st_idle_time, you wa
On Tue, Nov 16, 2021 at 2:50 PM Shinya Kato
wrote:
> > I'm not sure if we have "how to create an extension/a bg worker?" in
> > the core docs, if we have, it is a good idea to make note of using
> > EmitWarningsOnPlaceholders so that it will not be missed in the future
> > modules.
>
> I cannot fi
On Mon, Nov 8, 2021 at 1:13 PM Fujii Masao wrote:
> On 2021/11/07 18:06, Etsuro Fujita wrote:
> > On Mon, Nov 1, 2021 at 3:22 PM Fujii Masao
> > wrote:
> >> Could you tell me why the parameter is necessary?
> >> Can't we always enable the feature?
> > I think it might be OK to enable it by
> >
On 2021-11-15 15:14, Bharath Rupireddy wrote:
Do we need to add them in the following too?
delay_execution/delay_execution.c
ssl_passphrase_func.c
worker_spi.c
Especially, worker_spi.c is important as it works as a template for
the bg worker code.
Thank you for pointing this out! I added it.
On Mon, Nov 15, 2021 at 2:44 PM Dilip Kumar wrote:
>
> On Fri, Nov 12, 2021 at 3:49 PM Ajin Cherian wrote:
> >
> > Attaching version 39-
I have reviewed, 0001* and I have a few comments on it
---
>If you choose to do the initial table synchronization, only data that satisfies
>the row filters i
On Friday, November 12, 2021 6:20 PM Ajin Cherian wrote:
>
> Attaching version 39-
>
I met another problem when filtering out with the operator '~'.
Data can't be replicated as expected.
For example:
-- publisher
create table t (a text primary key);
create publication pub for table t where (a ~
On Fri, Nov 12, 2021 at 9:19 PM Ajin Cherian wrote:
>
> Attaching version 39-
>
Thanks for the updated patch.
Some review comments:
doc/src/sgml/ref/create_publication.sgml
(1) improve comment
+ /* Set up a pstate to parse with */
"pstate" is the variable name, better to use "ParseState".
src/
Thank you for checking the patch !
On Friday, November 12, 2021 1:49 PM Greg Nancarrow wrote:
> On Thu, Nov 11, 2021 at 8:20 PM osumi.takami...@fujitsu.com
> wrote:
> Some comments on the v4 patch:
>
> (1) Patch subject
> I think the patch subject should say "disable" instead of "disabling":
>
99 matches
Mail list logo
