On Fri, Apr 17, 2020 at 2:12 PM Thomas Munro wrote:
> What about a contrib function that lets you clobber
> oldSnapshotControl->current_timestamp? It looks like all times in
> this system come ultimately from GetSnapshotCurrentTimestamp(), which
> uses that variable to make sure that time never g
On Fri, Apr 17, 2020 at 10:09:07PM +0900, Amit Langote wrote:
> On Thu, Apr 16, 2020 at 11:19 PM Justin Pryzby wrote:
> > On Thu, Apr 16, 2020 at 06:16:45PM +0900, yuzuko wrote:
> > I don't think that adequately allows what's needed.
...(paragraph with my typos elided)...
> > For example, say a ne
On Fri, Apr 17, 2020 at 6:45 PM Peter Eisentraut
wrote:
>
> On 2020-04-14 05:57, Amit Kapila wrote:
> > Peter E, others, any suggestions on how to move forward? I think here
> > we should follow the rule "follow the style of nearby code" which in
> > this case would be to have one space after eac
On Sat, Apr 18, 2020 at 12:14 AM Juan José Santamaría Flecha
wrote:
>
>
> We can get a match for those locales in non-ISO format by enumerating
> available locales with EnumSystemLocalesEx(), and trying to find a match.
>
> Please find a new patch for so.
>
I have not reviewed or tested the new
pá 17. 4. 2020 v 23:29 odesílatel Justin Pryzby
napsal:
> On Fri, Apr 17, 2020 at 07:47:15PM +0200, Pavel Stehule wrote:
> > I propose new function string_to_table. This function is significantly
>
> +1
>
> > +/*
> > + * Add text to result set (table or array). Build a table when set is a
> expec
On Sat, 18 Apr 2020 at 00:31, Tom Lane wrote:
>
> Kyotaro Horiguchi writes:
> > At Fri, 17 Apr 2020 16:03:34 +0900, Fujii Masao
> > wrote in
> >> I agree that it might be worth considering the removal of am_sync for
> >> the master branch or v14. But I think that it should not be
> >> back-patc
I've recently been thinking about some optimizations to scalar array
op expression evaluation [1], and Tom mentioned that I might want to
consider looking into previous efforts into caching stable
subexpressions as a component of that (particularly if I wanted it to
be useful for more than constant
On Mon, Apr 13, 2020 at 10:40 AM James Coleman wrote:
>
> I've read through all of the previous discussions related to stable
> subexpression caching, and I'm planning to send a summary email with
> all of those links in one place.
>
> But I also happened to stumble upon mention in the TODO of som
"David G. Johnston" writes:
> On Fri, Apr 17, 2020 at 4:17 PM Tom Lane wrote:
>> We do have some postfix operators still ... although it looks like
>> there's only one in core. In any case, the signature line is *the*
>> thing that is supposed to specify what the syntax is, so I'm not
>> too ple
Hi,
On 2020-04-17 12:19:32 -0400, Robert Haas wrote:
> On Thu, Apr 16, 2020 at 10:22 PM Robert Haas wrote:
> > Hmm. Could we learn what we need to know about this by doing something
> > as taking a basebackup of a cluster with some data in it (say, created
> > by pgbench -i -s 400 or something) a
On Fri, Apr 17, 2020 at 4:17 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Fri, Apr 17, 2020 at 4:04 PM Tom Lane wrote:
> >> Especially not for unary operators, where
> >> ALTER OPERATOR would have us write "- (NONE, integer)".
>
> > I'd drop the parens for unary and just write "- int
On 2020-Apr-17, Jeremy Morton wrote:
> How could the ORM use timestamptz when that doesn't actually store both a
> datetime and an offset?
There are lots of ways in which timestamptz can be used. The most
typical one is to rely on the TimeZone configuration parameter; another
very typical one is
"David G. Johnston" writes:
> On Fri, Apr 17, 2020 at 4:04 PM Tom Lane wrote:
>> Especially not for unary operators, where
>> ALTER OPERATOR would have us write "- (NONE, integer)".
> I'd drop the parens for unary and just write "- integer"
We do have some postfix operators still ... although i
How could the ORM use timestamptz when that doesn't actually store
both a datetime and an offset?
--
Best regards,
Jeremy Morton (Jez)
Tom Lane wrote:
Jeremy Morton writes:
Surely the fact that you'll lose data if you try to store a common
.NET datatype with any kind of ORM (eg. EF, which is
On Fri, Apr 17, 2020 at 4:04 PM Tom Lane wrote:
> Especially not for unary operators, where
> ALTER OPERATOR would have us write "- (NONE, integer)".
>
I'd drop the parens for unary and just write "- integer"
It is a bit geeky but then again SQL writers are not typically computer
language novic
"David G. Johnston" writes:
> I feel like writing them as:
> + (date, integer) -> date
> makes more sense as they are mainly sorted on the operator symbol as
> opposed to the left operand.
Hmm ... we do use that syntax in some fairly-obscure places like
ALTER OPERATOR, but I'm afraid that novice
On Fri, Apr 17, 2020 at 11:38 AM Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Apr 16, 2020 at 8:25 PM Tom Lane wrote:
> >> Attached are screenshots of the same segment of table 9.10 as before
> >> and of the initial portion of 9.30, the patch against HEAD to produce
> >> these, and a hacky
On Sat, Apr 18, 2020 at 2:00 AM Ants Aasma wrote:
> On Thu, 16 Apr 2020 at 10:33, Pavel Stehule wrote:
> > what I know, pgbench cannot be used for testing spinlocks problems.
> >
> > Maybe you can see this issue when a) use higher number clients - hundreds,
> > thousands. Decrease share memory,
On Fri, Apr 17, 2020 at 07:47:15PM +0200, Pavel Stehule wrote:
> I propose new function string_to_table. This function is significantly
+1
> +/*
> + * Add text to result set (table or array). Build a table when set is a
> expected or build
> + * a array
as expected (??)
*an* array
> +select st
On Tue, Apr 7, 2020 at 12:14 PM Thomas Munro wrote:
> On Sun, Apr 5, 2020 at 11:31 AM Thomas Munro wrote:
> > On Sun, Apr 5, 2020 at 10:34 AM Mark Dilger
> > wrote:
> > > The "xid8_" warts are partly motivated by having a type named "xid8",
> > > which is a bit of a wart in itself.
> >
> > Just
On Sat, Apr 18, 2020 at 12:19 AM Robert Haas wrote:
> On Thu, Apr 16, 2020 at 11:37 PM Thomas Munro wrote:
> > Then of course frozenXID can be advanced with eg update pg_database
> > set datallowconn = 't' where datname = 'template0', then vacuumdb
> > --freeze --all, and checked before and afte
Robert Haas writes:
> On Fri, Apr 17, 2020 at 3:58 PM Tom Lane wrote:
>> On the other point of dispute about the operator tables: for the
>> moment I'm leaning towards keeping the text descriptions.
> I mostly suggested nuking them just to try to make the table more
> readable. But since you've
Robert Haas writes:
> pq_putmessage() is a macro which calls a function that is normally
> socket_putmessage(), which returns either 0 on success or EOF in the
> case of failure. Most callers ignore the return value, sometimes with
> an explicit cast to void, and other times without such a cast. A
On Fri, Apr 17, 2020 at 3:58 PM Tom Lane wrote:
> On the other point of dispute about the operator tables: for the
> moment I'm leaning towards keeping the text descriptions.
I mostly suggested nuking them just to try to make the table more
readable. But since you've found another (and better) so
Robert Haas writes:
> On Fri, Apr 17, 2020 at 2:38 PM Tom Lane wrote:
>> Glad you like 'em ;-). Do you have an opinion about what to do
>> with the operator tables --- ie do we need a column with the operator
>> name at the left?
> Well, if the first row says date + date -> date, then I don't t
pq_putmessage() is a macro which calls a function that is normally
socket_putmessage(), which returns either 0 on success or EOF in the
case of failure. Most callers ignore the return value, sometimes with
an explicit cast to void, and other times without such a cast. As far
as I can see, the only
On 2020-Apr-17, Andres Freund wrote:
> Yes? But that type doesn't exist in isolation. Having yet another
> significantly different representation of 64bit xids (as plain 64 bit
> integers, and as some 32/32 epoch/xid split) would make an already
> confusing situation even more complex.
On the con
On Fri, Apr 17, 2020 at 2:38 PM Tom Lane wrote:
> Glad you like 'em ;-). Do you have an opinion about what to do
> with the operator tables --- ie do we need a column with the operator
> name at the left?
Well, if the first row says date + date -> date, then I don't think we
also need another co
We choose a split point in nbtsplitloc.c primarily based on evenly
dividing space among left and right halves of the split, while giving
secondary consideration to suffix truncation (there is other logic
that kicks in when there are many duplicates, which isn't related to
what I want to talk about)
On 4/17/20 9:56 AM, Andrew Dunstan wrote:
> On 4/17/20 5:18 AM, Lin, Cuiping wrote:
>> Hi all
>>
>> I build postgers with VS in windows, and the following message output
>>
>> “ Unable to determine Visual Studio version: The nmake version could not be
>> determined.”
>>
>> I investigated the VSO
On Fri, Apr 17, 2020 at 10:33 AM Amit Kapila
wrote:
>
> I see some differences in the output when _create_locale() is used vs.
> when GetLocaleInfoEx() is used. Forex.
>
Thanks for the thorough review.
> The function IsoLocaleName() header comment says "Convert a Windows
> setlocale() argumen
Hi,
On 2020-04-17 14:07:07 -0400, Robert Haas wrote:
> On Fri, Apr 17, 2020 at 1:45 PM Andres Freund wrote:
> > You seem to be entirely disregarding my actual point, namely that
> > txid_current(), as well as some other txid_* functions, have returned
> > 64bit xids for many many years. txid_curr
Robert Haas writes:
> On Thu, Apr 16, 2020 at 8:25 PM Tom Lane wrote:
>> Attached are screenshots of the same segment of table 9.10 as before
>> and of the initial portion of 9.30, the patch against HEAD to produce
>> these, and a hacky patch on the website's main.css to get it to go
>> along. W
On Thu, Apr 16, 2020 at 8:25 PM Tom Lane wrote:
> Attached are screenshots of the same segment of table 9.10 as before
> and of the initial portion of 9.30, the patch against HEAD to produce
> these, and a hacky patch on the website's main.css to get it to go
> along. Without the last you just ge
On Thu, Apr 16, 2020 at 6:49 PM Andres Freund wrote:
> Yea. _bt_vacuum_needs_cleanup() needs to check if
> metad->btm_oldest_btpo_xact is older than the FreezeLimit computed by
> vacuum_set_xid_limits() and vacuum the index if so even if INDEX_CLEANUP
> false.
I'm still fairly unclear on what the
On Fri, Apr 17, 2020 at 1:45 PM Andres Freund wrote:
> You seem to be entirely disregarding my actual point, namely that
> txid_current(), as well as some other txid_* functions, have returned
> 64bit xids for many many years. txid_current() is the only function to
> get the current xid in a reaso
Hi
I propose new function string_to_table. This function is significantly
faster (and simpler) variant of regexp_split_to_array function. There was
same process years ago when we implemented string_agg as faster variant of
array_to_string(array_agg()). string_to_table is faster variant (and little
Fujii Masao writes:
> Thanks for the report and the patch! It looks good to me.
> Barring any objection, I will commit this patch.
It might be worth writing "pg_promote() is called"
(adding parentheses) to make it clearer that a function is being
referred to. No objection otherwise.
Hi,
On 2020-04-17 13:33:53 -0400, Robert Haas wrote:
> On Thu, Apr 2, 2020 at 5:13 PM Andres Freund wrote:
> > Given that txid_current() "always" has been a plain 64 bit integer, and
> > the various txid_* functions always have returned 64 bit integers, I
> > really don't think arguing for some 3
On Thu, Apr 2, 2020 at 5:13 PM Andres Freund wrote:
> Given that txid_current() "always" has been a plain 64 bit integer, and
> the various txid_* functions always have returned 64 bit integers, I
> really don't think arguing for some 32bit/32bit situation now makes
> sense.
I'm not sure what the
On Thu, Apr 16, 2020 at 3:18 AM Amit Khandekar wrote:
> Not relevant to the PAUSE stuff Note that when the parallel
> clients reach from 24 to 32 (which equals the machine CPUs), the TPS
> shoots from 454189 to 1097592 which is more than double speed gain
> with just a 30% increase in paralle
Kyotaro Horiguchi writes:
> Recently a cache reference leak was reported then fixed [1].
> I happened to notice a similar possible leakage in
> removeEtObjInitPriv. I haven't found a way to reach the code, but can
> be forcibly caused by tweaking the condition.
> Please find the attached.
Ugh. r
Kyotaro Horiguchi writes:
> At Fri, 17 Apr 2020 17:03:11 +0900, Masahiko Sawada
> wrote in
>> On Fri, 17 Apr 2020 at 14:58, Kyotaro Horiguchi
>> wrote:
>> Just for confirmation, since the new approach doesn't change that
>> walsenders reload new config at their convenient timing, it still can
On Thu, Apr 16, 2020 at 10:22 PM Robert Haas wrote:
> Hmm. Could we learn what we need to know about this by doing something
> as taking a basebackup of a cluster with some data in it (say, created
> by pgbench -i -s 400 or something) and then comparing the speed of cat
> < base.tar | gzip > base.
Nikita Glukhov writes:
> I found a problem with selectivity estimation for NULL-returning operators.
> matchingsel() is not ready to use as a restriction selectivity estimator for
> operators like our jsonpath operators @? and @@, because it calls operator
> function on values obtained from pg_sta
On 4/16/20 9:57 PM, Michael Paquier wrote:
> On Thu, Apr 16, 2020 at 02:17:33PM +0200, Daniel Gustafsson wrote:
>> Commit 896fcdb230e72 (sorry for chiming in too late, I missed that thread)
>> added a TLS init hook which is OpenSSL specific: openssl_tls_init_hook.
>> Since
>> the rest of the TL
Hi, hackers!
I found a problem with selectivity estimation for NULL-returning operators.
matchingsel() is not ready to use as a restriction selectivity estimator for
operators like our jsonpath operators @? and @@, because it calls operator
function on values obtained from pg_statistic through p
Kyotaro Horiguchi writes:
> At Fri, 17 Apr 2020 16:03:34 +0900, Fujii Masao
> wrote in
>> I agree that it might be worth considering the removal of am_sync for
>> the master branch or v14. But I think that it should not be
>> back-patched.
> Ah! Agreed.
Yeah, that's not necessary to fix the b
On 2020/04/17 14:41, Noah Misch wrote:
On Mon, Apr 13, 2020 at 09:45:16PM -0400, Tom Lane wrote:
Noah Misch writes:
This seems to have made the following race condition easier to hit:
https://www.postgresql.org/message-id/flat/20200206074552.GB3326097%40rfd.leadboat.com
https://www.postgres
On Fri, Apr 17, 2020 at 10:23 PM Peter Eisentraut
wrote:
> On 2020-04-09 09:28, Amit Langote wrote:
> > While figuring this out, I thought the nearby code could be rearranged
> > a bit, especially to de-duplicate the code. Also, I think
> > get_rel_sync_entry() may be a better place to set the ma
On Thu, 16 Apr 2020 at 10:33, Pavel Stehule wrote:
> what I know, pgbench cannot be used for testing spinlocks problems.
>
> Maybe you can see this issue when a) use higher number clients - hundreds,
> thousands. Decrease share memory, so there will be press on related spin lock.
There really ar
Kyotaro Horiguchi writes:
> At Thu, 16 Apr 2020 22:41:46 -0700, Noah Misch wrote in
>> I'm favoring (1). Other preferences?
> Starting from the current shape, I think 1 is preferable, since that
> waiting logic is no longer shared between logical and physical
> replications. But I'm not sure
On 4/17/20 5:18 AM, Lin, Cuiping wrote:
> Hi all
>
> I build postgers with VS in windows, and the following message output
>
> “ Unable to determine Visual Studio version: The nmake version could not be
> determined.”
>
> I investigated the VSObjectFactory.pm, and found the match string “if
> (
On Tue, 14 Apr 2020 at 22:41, tushar wrote:
>
> Hi ,
>
> We have a sql file called 'generated.sql' under src/test/regress/sql
> folder . if we run this file on psql , take the dump and try to restore
> it on another db
> we are getting error like -
>
> psql:/tmp/x:434: ERROR: column "b" of relat
On Fri, Apr 17, 2020 at 3:57 AM Patrick REED wrote:
>
> Hi Julien,
>
> Sorry for the late reply. I was able to solve the issue. It had to do with
> the extra syntax I had introduced in gram.y. However, since you mentioned the
> utility command, can you elaborate a bit more on that?
Utility comm
On 2020-04-09 09:28, Amit Langote wrote:
This patch makes the tests pass for me:
diff --git a/src/backend/replication/pgoutput/pgoutput.c
b/src/backend/replication/pgoutput/pgoutput.c
index 5fbf2d4367..cf6e8629c1 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replicat
Jeremy Morton writes:
> Surely the fact that you'll lose data if you try to store a common
> .NET datatype with any kind of ORM (eg. EF, which is pretty popular)
> right now, using "the world's most advanced open source relational
> database", is reason enough to support it?
If the ORM somehow
On 2020-04-14 05:57, Amit Kapila wrote:
Peter E, others, any suggestions on how to move forward? I think here
we should follow the rule "follow the style of nearby code" which in
this case would be to have one space after each field as we would like
it to be closer to the "Buffers" format. It w
Peter Eisentraut writes:
> On 2020-04-15 02:15, Tom Lane wrote:
>> In the meantime could we at least say "ALTER TABLE action cannot
>> be performed"?
> We don't know whether ALTER TABLE was the command. For example, in one
> of the affected regression test cases, the command is ALTER VIEW.
May
On Thu, Apr 16, 2020 at 11:19 PM Justin Pryzby wrote:
> On Thu, Apr 16, 2020 at 06:16:45PM +0900, yuzuko wrote:
> > The latest patch lets users set different autovacuum configuration for
> > each partitioned
> > tables like this,
> > create table p3(i int) partition by range(i) with
> >(auto
Hi Wenjing,
Please check below scenario, we are getting a server crash with "ALTER
TABLE" add column with default value as sequence:
-- Create gtt, exit and re-connect the psql prompt, create sequence, alter
table add a column with sequence.
postgres=# create global temporary table gtt1 (c1 int);
On 2020-04-15 02:15, Tom Lane wrote:
In the meantime could we at least say "ALTER TABLE action cannot
be performed"?
We don't know whether ALTER TABLE was the command. For example, in one
of the affected regression test cases, the command is ALTER VIEW.
--
Peter Eisentraut http
On Thu, Apr 16, 2020 at 11:37 PM Thomas Munro wrote:
> Then of course frozenXID can be advanced with eg update pg_database
> set datallowconn = 't' where datname = 'template0', then vacuumdb
> --freeze --all, and checked before and after with Robert's
> pg_old_snapshot_time_mapping() SRF to see t
On Fri, Apr 17, 2020 at 2:44 PM 曾文旌 wrote:
>
> I improved the logic of the warning message so that when the gap between
> relfrozenxid of GTT is small,
> it will no longer be alarmed message.
>
Hi Wenjing,
Thanks for the patch(v26), I have verified the previous related issues, and
are working fi
I alluded to this in [0], but it's better discussed in its own thread.
I think the check that makes pgstattuple_approx reject TOAST tables is a
mistake. They have visibility and free space map, and it works just
fine if the check is removed.
Attached is a patch to fix this and add some tests
On 4/17/20 11:00 AM, Jeremy Morton wrote:
I am not saying there isn't a use case for something like
datetimeoffset, I think that there is. For example in some kind of
Surely the fact that you'll lose data if you try to store a common .NET
datatype with any kind of ORM (eg. EF, which is pretty
On 2020/04/15 22:24, Robert Haas wrote:
On Tue, Apr 14, 2020 at 11:49 PM Fujii Masao
wrote:
While reading the document that you pushed, I thought that it's better
to define index term for backup manifest, so that we can easily reach
this document from the index page. Thought? Patch attached.
Hi all
I build postgers with VS in windows, and the following message output
“ Unable to determine Visual Studio version: The nmake version could not be
determined.”
I investigated the VSObjectFactory.pm, and found the match string “if ($output
=~ /(\d+)\.(\d+)\.\d+(\.\d+)?$/m)”
It works fine
On Fri, Apr 17, 2020 at 7:13 AM Tomas Vondra
wrote:
> On Thu, Apr 16, 2020 at 08:44:16PM +0200, Tomas Vondra wrote:
> >
> >Yeah, that's not entirely close to me. But maybe it shows us where we to
> >get the unprocessed target list?
> >
>
> I think at the very least this needs to apply the same ch
Andreas Karlsson wrote:
On 4/10/20 3:19 PM, Jeremy Morton wrote:
Oh well. Guess I keep using SQL Server then. datetimeoffset makes
it impossible for developers to make the mistake of forgetting to
use UTC instead of local datetime, and for that reason alone it
makes it invaluable in my opini
At Fri, 17 Apr 2020 17:03:11 +0900, Masahiko Sawada
wrote in
> On Fri, 17 Apr 2020 at 14:58, Kyotaro Horiguchi
> wrote:
> > The attached is baed on syncrep-fixes-1.patch + am_sync elimination.
> >
>
> Just for confirmation, since the new approach doesn't change that
> walsenders reload new co
On Fri, Apr 17, 2020 at 2:44 AM Tomas Vondra
wrote:
> On Thu, Apr 16, 2020 at 12:04:03PM -0400, James Coleman wrote:
> >On Thu, Apr 16, 2020 at 8:22 AM Richard Guo
> wrote:
> >> On Thu, Apr 16, 2020 at 6:35 PM Richard Guo
> wrote:
> >>
> >> Attached is what I'm thinking about this optimization.
On Wed, Apr 15, 2020 at 11:58 PM Juan José Santamaría Flecha
wrote:
>
> On Wed, Apr 15, 2020 at 4:46 PM Ranier Vilela wrote:
>>
>> Em qua., 15 de abr. de 2020 às 03:08, davinder singh
>> escreveu:
>>>
>>>
5. Why call _create_locale if _WIN32_WINNT >= 0x0600 is true and loct is
not us
At Fri, 17 Apr 2020 16:03:34 +0900, Fujii Masao
wrote in
> I agree that it might be worth considering the removal of am_sync for
> the master branch or v14. But I think that it should not be
> back-patched.
Ah! Agreed.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Sorry , I wrote something wrong.
At Fri, 17 Apr 2020 17:00:15 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 16 Apr 2020 22:41:46 -0700, Noah Misch wrote in
> > On Mon, Apr 13, 2020 at 09:45:16PM -0400, Tom Lane wrote:
> > > Noah Misch writes:
> > > > This seems to have made the following
On Fri, 17 Apr 2020 at 14:58, Kyotaro Horiguchi wrote:
>
> At Thu, 16 Apr 2020 11:39:06 -0400, Tom Lane wrote in
> > Kyotaro Horiguchi writes:
> > > [ syncrep-fixes-4.patch ]
> >
> > I agree that we could probably improve the clarity of this code with
> > further rewriting, but I'm still very op
At Thu, 16 Apr 2020 22:41:46 -0700, Noah Misch wrote in
> On Mon, Apr 13, 2020 at 09:45:16PM -0400, Tom Lane wrote:
> > Noah Misch writes:
> > > This seems to have made the following race condition easier to hit:
> > > https://www.postgresql.org/message-id/flat/20200206074552.GB3326097%40rfd.lea
On 2020/04/17 3:00, Tom Lane wrote:
Fujii Masao writes:
On 2020/04/14 22:52, Tom Lane wrote:
*Yes it does*. The existing code can deliver entirely broken results
if some walsender exits between where we examine the priorities and
where we fetch the WAL pointers.
IMO that the broken resul
On Tue, Apr 14, 2020 at 5:33 PM Asif Rehman wrote:
>
>
> On Wed, Apr 8, 2020 at 6:53 PM Kashif Zeeshan <
> kashif.zees...@enterprisedb.com> wrote:
>
>>
>>
>> On Tue, Apr 7, 2020 at 9:44 PM Asif Rehman
>> wrote:
>>
>>> Hi,
>>>
>>> Thanks, Kashif and Rajkumar. I have fixed the reported issues.
>>>
On Wed, Apr 15, 2020 at 4:18 PM David Rowley wrote:
> I'm a bit divided on what the correct fix is. If I blame Parallel
> Append for not trying hard enough to pull up the lower Append in
> accumulate_append_subpath(), then clearly the parallel append code is
> to blame.
I spent some time trying
On 2020/04/17 14:58, Kyotaro Horiguchi wrote:
At Thu, 16 Apr 2020 11:39:06 -0400, Tom Lane wrote in
Kyotaro Horiguchi writes:
[ syncrep-fixes-4.patch ]
I agree that we could probably improve the clarity of this code with
further rewriting, but I'm still very opposed to the idea of having
On Fri, 2020-04-17 at 13:54 +0900, Michael Paquier wrote:
> On Fri, Apr 17, 2020 at 01:40:02PM +0900, Fujii Masao wrote:
> > Thanks for the report and the patch! It looks good to me.
> > Barring any objection, I will commit this patch.
>
> +1.
+1. That was my omission in the original patch.
You
82 matches
Mail list logo
