On Mon, 10 Jun 2019 at 10:37, Amit Khandekar wrote:
>
> On Tue, 4 Jun 2019 at 21:28, Andres Freund wrote:
> >
> > Hi,
> >
> > On 2019-06-04 15:51:01 +0530, Amit Khandekar wrote:
> > > After giving more thought on this, I think it might make sense to
> > > arrange for the xl_running_xact record to
Hi,
On 2019-06-11 14:56:36 +0900, Michael Paquier wrote:
> On Mon, Jun 10, 2019 at 10:33:37PM -0700, Andres Freund wrote:
> > Yea, that's where the default_table_access_method code originates from,
> > obviously. I'll backpatch the default_text_search_config fix separately
> > (and first).
>
> So
Hello Andres,
I noticed that pgbench's -R influences not just the computation of lag,
but also of latency. That doesn't look right to me, but maybe I'm just
missing something?
It's quite easy to demonstrate when running pgbench with/without
progress report at a transaction rate that's around
Hi,
While working on fixing [1] I noticed that 2dedf4d9a899 "Integrate
recovery.conf into postgresql.conf" added two non-rethrowing PG_CATCH
uses. That's not OK. See
https://www.postgresql.org/message-id/1676.1548726280%40sss.pgh.pa.us
https://postgr.es/m/20190206160958.GA22304%40alvherre.pgsql
e
On Fri, Jun 7, 2019 at 4:33 AM Tomas Vondra
wrote:
> 2) 0002 - update sgml docs to reflect changes from 0001
There is some copypasta here in the new section referring to the old catalog:
+
+ pg_statistic_ext_data
+
+
+ pg_statistic_ext
+
+
+
+ The catalog pg_statistic_ext
+ holds e
On Mon, Jun 10, 2019 at 10:33:37PM -0700, Andres Freund wrote:
> Yea, that's where the default_table_access_method code originates from,
> obviously. I'll backpatch the default_text_search_config fix separately
> (and first).
So you are just planning to add a check on MyDatabaseId for both? No
ob
On Mon, Jun 10, 2019 at 07:56:12PM +0530, Kuntal Ghosh wrote:
> On Mon, Jun 10, 2019 at 7:19 PM Robert Haas wrote:
>> This whole thing looks like a nonissue to me. If you set it up wrong,
>> it won't work. So don't do that.
+1.
--
Michael
signature.asc
Description: PGP signature
Hi,
On 2019-06-10 16:37:33 +0900, Michael Paquier wrote:
> On Sat, Jun 08, 2019 at 08:26:07AM -0700, Andres Freund wrote:
> > We have plenty other callbacks that aren't bulletproof, so I don't think
> > this is really something we should / can change in isolation here.
>
> Good point. I was look
Hi
On 2019-06-10 21:56:31 -0700, Andres Freund wrote:
> I noticed that pgbench's -R influences not just the computation of lag,
> but also of latency. That doesn't look right to me, but maybe I'm just
> missing something?
I apparently did:
> -P sec
> --progress=sec
>
> Show progress report
Hi,
I noticed that pgbench's -R influences not just the computation of lag,
but also of latency. That doesn't look right to me, but maybe I'm just
missing something?
It's quite easy to demonstrate when running pgbench with/without
progress report at a transaction rate that's around the limit of w
On Tue, Jun 11, 2019 at 1:02 PM Michael Paquier wrote:
>
> On Mon, Jun 10, 2019 at 06:09:53PM +0900, Masahiko Sawada wrote:
> > We already have the following line in action part but you mean we need
> > an extra line for that?
> >
> >ADD [ COLUMN ] [ IF NOT EXISTS ] column_name data_type [ COL
Hello Dmitry,
Given that it's an open item for PostgreSQL 12,
I'm working on it, but slowly.
I've decided to take a look.
Thanks!
Indeed, looks like 6e5f8d4 introduced a subtle behaviour change, when
hostaddr changes are not picked up for subsequent \connect's, and I
don't see any men
Alvaro,
On Mon, Jun 10, 2019 at 11:19 PM Alvaro Herrera
wrote:
> On 2019-Jun-10, Etsuro Fujita wrote:
> > Here is a small patch to reorder header files in postgres_fdw.c and
> > connection.c in alphabetical order.
>
> Looks good.
Pushed. Thanks for reviewing!
Best regards,
Etsuro Fujita
Hello Ibrar,
Does both client/server side data generation in a single command make
sense?
I think yes, especially with the other patch which adds timing measures to
the initialization phases. It really depends what you want to test.
With client-side generation you test the libpq COPY inte
> On Tue, Jun 11, 2019 at 10:51 AM Etsuro Fujita
> wrote:
> > On Tue, Jun 11, 2019 at 10:30 AM Amit Langote
> > wrote:
> > > On Mon, Jun 10, 2019 at 9:04 PM Etsuro Fujita
> > > wrote:
> > > > > On Tue, May 28, 2019 at 12:54 PM Amit Langote
> > > > > wrote:
> > > > > > On 2019/05/27 22:02, To
Hi
> But I wonder if it is safe that the old cursor_name is forgotten.
old cursor_name is not assigned to other pointers, so it is safe that the old
cursor_name is forgotten.
Best Regards!
-Original Message-
From: Matsumura, Ryo/松村 量
Sent: Monday, June 10, 2019 5:52 PM
To: Zhang, Jie/张
On Mon, Jun 10, 2019 at 06:09:53PM +0900, Masahiko Sawada wrote:
> We already have the following line in action part but you mean we need
> an extra line for that?
>
>ADD [ COLUMN ] [ IF NOT EXISTS ] column_name data_type [ COLLATE
> collation ] [ column_constraint [ ... ] ]
I was looking at
Hi,
I've talked a few times about a bgwriter replacement prototype I'd
written a few years back. That happened somewhere deep in another thread
[1], and thus not easy to fix.
Tomas Vondra asked me for a link, but there was some considerable bitrot
since. Attached is a rebased and slightly improve
Hello.
At Mon, 10 Jun 2019 16:48:42 +0900, Michael Paquier
wrote in <20190610074842.gh2...@paquier.xyz>
> On Mon, Jun 10, 2019 at 01:57:14PM +0900, Kyotaro Horiguchi wrote:
> > If we don't do that, translation lines in po files are
> > useless. prep_stauts must be removed from TETTEXT_TRIGGERS, a
On Tue, Jun 11, 2019 at 11:43 AM Alvaro Herrera
wrote:
>
> On 2019-Jun-11, David Rowley wrote:
>
> > Changes attached.
>
> Unreserved +1 to these patches.
The latest version looks good to me too.
Thanks,
Amit
On 2019-Jun-11, David Rowley wrote:
> Changes attached.
Unreserved +1 to these patches.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-May-30, Andres Freund wrote:
> Hi,
>
>
> On 2019-05-30 16:31:39 +0530, Ashutosh Sharma wrote:
> > Here are some more details on the crash reported in my previous e-mail for
> > better clarity:
>
> I'll look into this once pgcon is over... Thanks for finding!
Ping?
--
Álvaro Herrera
I forgot to send this by "Reply ALL".
On Tue, Jun 11, 2019 at 10:51 AM Etsuro Fujita wrote:
>
> Amit-san,
>
> On Tue, Jun 11, 2019 at 10:30 AM Amit Langote wrote:
> > On Mon, Jun 10, 2019 at 9:04 PM Etsuro Fujita
> > wrote:
> > > > On Tue, May 28, 2019 at 12:54 PM Amit Langote
> > > > wrote:
On Tue, 11 Jun 2019 at 11:15, Justin Pryzby wrote:
>
> On Mon, Jun 10, 2019 at 06:11:35PM -0400, Alvaro Herrera wrote:
> > On 2019-Jun-09, Justin Pryzby wrote:
> >
> > > I think it should say:
> > >
> > > |Choosing the target number of partitions into which the table should
> > > be
> > > |
Fujita-san,
Thanks for the comments.
On Mon, Jun 10, 2019 at 9:04 PM Etsuro Fujita wrote:
> > On Tue, May 28, 2019 at 12:54 PM Amit Langote
> > wrote:
> > > On 2019/05/27 22:02, Tom Lane wrote:
> > > > Perhaps, if the table has relevant BEFORE triggers, we should just
> > > > abandon
> > > > o
On 6/11/19 2:33 AM, Alexander Korotkov wrote:
On Sat, Jun 8, 2019 at 8:17 PM Alexander Korotkov
wrote:
On Fri, Jun 7, 2019 at 6:02 PM Ian Barwick wrote:
On 6/7/19 9:00 PM, Michael Paquier wrote:
On Fri, Jun 07, 2019 at 03:44:14PM +0900, Masahiko Sawada wrote:
> Or is that not worth bother
On Mon, Jun 10, 2019 at 2:56 PM Andres Freund wrote:
> > Currently, all AM needs to build HeapTuple in
> > index_build_range_scan function. I looked into all the callback functions
> > and only htup->t_self is used from heaptuple in all the functions
> (unless I
> > missed something). So, if seem
On Fri, Jun 7, 2019 at 8:52 PM Michael Paquier wrote:
>
> On Fri, Jun 07, 2019 at 03:30:35PM +0900, Masahiko Sawada wrote:
> > Agreed. Please find an attached patch.
>
> Thanks, committed.
Thank you!
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software
On Mon, Jun 10, 2019 at 06:11:35PM -0400, Alvaro Herrera wrote:
> On 2019-Jun-09, Justin Pryzby wrote:
>
> > I think it should say:
> >
> > |Choosing the target number of partitions into which the table should be
> > |divided is also a critical decision to make. Not having enough
>
> I
On 2019-Jun-07, Alvaro Herrera wrote:
> I looked for other cases that could have been broken by changing the
> partition creation methodology in pg_dump, and didn't find anything.
> That part of pg_dump (dumpTableSchema) is pretty spaghettish, though;
> the fact that shouldPrintColumn makes some p
On 2019-Jun-09, Justin Pryzby wrote:
> I think it should say:
>
> |Choosing the target number of partitions into which the table should be
> |divided is also a critical decision to make. Not having enough
I opined elsewhere in the thread that this phrase can be made into more
straightfo
On Mon, Jun 10, 2019 at 5:35 AM Asim R P wrote:
> My understanding is smgr pendingDeletes infrastructure will be replaced by
> these patches. I still see CommitTransaction() calling
> smgrDoPendingDeletes() in the latest patch set. Am I missing something?
Hi Asim,
Thanks for looking at the p
Hi,
On 2019-06-10 13:48:54 -0700, Ashwin Agrawal wrote:
> While at it might be helpful and better to also decouple HeapTuple
> dependency for IndexBuildCallback.
Indeed.
> Currently, all AM needs to build HeapTuple in
> index_build_range_scan function. I looked into all the callback functions
>
Thanks for looking at this.
On Tue, 11 Jun 2019 at 01:44, Alvaro Herrera wrote:
>
> part_doc_pg10_v5.patch :
> +query planning and execution. The query planner is generally able to
> +handle partition hierarchies up a few hundred partition. Planning times
>
> "up TO a few hundred partit
On Fri, Jun 7, 2019 at 1:19 PM Robert Haas wrote:
> I spent some time today studying heapam_index_build_range_scan and
> quickly reached the conclusion that it's kind of a mess.
>
While at it might be helpful and better to also decouple HeapTuple
dependency for
IndexBuildCallback. Currently, all
On 2019-Jun-10, Robert Haas wrote:
> On Fri, Jun 7, 2019 at 6:42 PM Daniel Gustafsson wrote:
> > The commit message still refers to it as estimate_rel_size though. The
> > comment on
> > table_block_relation_estimate_size does too but that one might be
> > intentional.
>
> Oops. New version
On Fri, Jun 7, 2019 at 6:42 PM Daniel Gustafsson wrote:
> > Good catch, and now I notice that the callback is not called
> > estimate_rel_size but relation_estimate_size. Updated patch attached;
> > thanks for the review.
>
> The commit message still refers to it as estimate_rel_size though. The
Sorry for previous messup.> Hm, I'd like to know more about that corruption. Did you report it when> it occured?Thanks Andres for explanations. I didn't reported the corruption when itoccured as it was my fault, not a PG bug, as the main cause was that I wasusing network drive, knowingly it's unre
Hi!
After 5f32b29c explain of Hash Join sometimes triggers an error.
Simple reproduction case is below.
# create table t (x int);
CREATE TABLE
# set enable_sort = off;
SET
# explain select * from t a, t b where a.x = (select 1 where b.x = 1);
ERROR: bogus varno: 65000
Before 5f32b29c the same
> On Mon, May 27, 2019 at 10:38 PM Noah Misch wrote:
>
> On Mon, Nov 19, 2018 at 12:53:15PM -0300, Alvaro Herrera wrote:
> > commit 6e5f8d4
> > Commit: Alvaro Herrera
> > CommitDate: Mon Nov 19 14:34:12 2018 -0300
> >
> > psql: Show IP address in \conninfo
>
> > Discussion:
> > https
> Hm, I'd like to know more about that corruption. Did you report it when> it occured?Thanks Andres for explanations. I didn't reported the corruption when itoccured as it was my fault, not a PG bug, as the main cause was that I was using network drive, knowingly it's unreliable for DB but managem
On Sat, Jun 8, 2019 at 8:17 PM Alexander Korotkov
wrote:
> On Fri, Jun 7, 2019 at 6:02 PM Ian Barwick
> wrote:
> > On 6/7/19 9:00 PM, Michael Paquier wrote:
> > > On Fri, Jun 07, 2019 at 03:44:14PM +0900, Masahiko Sawada wrote:
> > > Or is that not worth bothering except on HEAD? Thoughts?
> >
The proposals I see above are "commontype", "supertype", "anycommontype",
and various abbreviations of those. I would humbly add "compatibletype".
Fwiw I kind of like commontype.
Alternately an argument could be made that length and typing convenience
isn't really a factor here since database use
Hello
> Does anyone think we shouldn't change the INFO message in ATTACH
> PARTITION to a DEBUG1 in PG12?
Seems no one wants to vote against this change.
My proposed patch was here: https://commitfest.postgresql.org/23/2076/
regards, Sergei
Does both client/server side data generation in a single command make sense?
On 2019-Jun-08, Euler Taveira wrote:
> While fixing the breakage caused by the default number of trailing
> digits output for real and double precision, I noticed that first
> random() call after setseed(0) doesn't return the same value as 10 and
> earlier (I tested 9.4 and later). It changed an e
On 6/10/19 12:58 AM, Noah Misch wrote:
> Several TAP test suites have a need to translate from an msys path to a
> Windows path. They currently use two ways to do that:
>
> 1. TestLib::real_dir, new in v11, is sound but works for directories only.
> 2. The $vfs_path approach is semi-private to P
On Mon, Jun 10, 2019 at 7:19 PM Robert Haas wrote:
>
> On Mon, Jun 10, 2019 at 7:08 AM Kuntal Ghosh
> wrote:
> > This can surely be fixed from the script. While configuring the old
> > master as a standby server, clear/modify the settings in
> > postgresql.auto.conf. But, it contradicts with the
On Mon, Jun 10, 2019 at 5:26 PM Tom Lane wrote:
>
> Kuntal Ghosh writes:
> >> 2. If we only support "Read Committed" isolation level, is there a safe
> >> way to not index such data?
>
> > I can't think of a case where the RECENTLY_DELETED tuple needs to be
> > indexed in "Read Committed" cas
On 2019-Jun-10, Etsuro Fujita wrote:
> Here is a small patch to reorder header files in postgres_fdw.c and
> connection.c in alphabetical order.
Looks good.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, Jun 10, 2019 at 7:08 AM Kuntal Ghosh wrote:
> This can surely be fixed from the script. While configuring the old
> master as a standby server, clear/modify the settings in
> postgresql.auto.conf. But, it contradicts with the comment in the file
> which forbids the user from editing the fi
part_doc_pg10_v5.patch :
+query planning and execution. The query planner is generally able to
+handle partition hierarchies up a few hundred partition. Planning times
"up TO a few hundred partition*S*" ?
part_doc_master_v5.patch:
+Choosing the target number of partitions into whic
On Thu, 6 Jun 2019 at 21:33, Tomas Vondra wrote:
>
> Hi,
>
> Attached are three patches tweaking the stats - two were already posted
> in this thread, the third one is just updating docs.
>
> 1) 0001 - split pg_statistic_ext into definition + data
>
> This is pretty much the patch Dean posted some
My understanding is smgr pendingDeletes infrastructure will be replaced by
these patches. I still see CommitTransaction() calling
smgrDoPendingDeletes() in the latest patch set. Am I missing something?
Asim
On Tue, May 28, 2019 at 3:40 PM Etsuro Fujita wrote:
> On Tue, May 28, 2019 at 12:54 PM Amit Langote
> wrote:
> > On 2019/05/27 22:02, Tom Lane wrote:
> > > Amit Langote writes:
> > >> On 2019/05/27 10:52, Shohei Mochizuki wrote:
> > >>> I noticed returning a modified record in a row-level BEFOR
Kuntal Ghosh writes:
>> 2. If we only support "Read Committed" isolation level, is there a safe
>> way to not index such data?
> I can't think of a case where the RECENTLY_DELETED tuple needs to be
> indexed in "Read Committed" case.
I think you're making dangerously optimistic assumptions a
> On 9 Jun 2019, at 20:05, Siarhei Siniak wrote:
>
> I've been using cube extension recompiled with
> #define MAX_DIM 256.
>
> But with a version 11.3 I'm getting the following error:
> failed to add item to index page in
This sounds like a variant of the issue reported on -bugs in
am6pr06mb57
Hi,
On 10/06/2019 13:27, Dave Cramer wrote:
> So back to binary output.
>
> From what I can tell the place to specify binary options would be in the
> create publication and or in replication slots?
>
> The challenge as I see it is that the subscriber would have to be able
> to decode binary out
So back to binary output.
>From what I can tell the place to specify binary options would be in the
create publication and or in replication slots?
The challenge as I see it is that the subscriber would have to be able to
decode binary output.
Any thoughts on how to handle this? At the moment I'
Hello,
On Wed, Jun 5, 2019 at 11:55 AM tushar wrote:
I can see two different problems in this setup.
> > 2)Slave Setup -> ./pg_basebackup -PR -X stream -c fast -h 127.0.0.1
> > -U centos -p 5432 -D slave
> > restore_command='cp %p /tmp/archive_dir1/%f'
> > "
> > 7)Modify old master/postgresql.
Thanks! Appreciate it for your time!
On Mon, Jun 10, 2019 at 5:34 PM Kuntal Ghosh
wrote:
> On Mon, Jun 10, 2019 at 2:12 PM Alex wrote:
> > On Mon, Jun 10, 2019 at 4:10 PM Kuntal Ghosh
> wrote:
> >> I think what I'm trying to say is different.
> >>
> >> For my case, the sequence is as following
Hi
On Mon. June. 10, 2019 at 09:54 AM Zhang, Jie
< zhangj...@cn.fujitsu.com > wrote:
>
> Memory leaks occur when the ecpg_update_declare_statement() is called the
> second time.
Certainly it is.
But I wonder if it is safe that the old cursor_name is forgotten.
Regards
Ryo Matsumura
> -Ori
Le dim. 9 juin 2019 à 04:27, Michael Paquier a écrit :
> On Sat, Jun 08, 2019 at 04:23:55PM +0200, Guillaume Lelarge wrote:
> > We might find more typos, but it will take time. Applying this patch now
> > (if it fits you) is probably better.
>
> I can imagine that it is a daunting task... Ok, fo
On Mon, Jun 10, 2019 at 2:12 PM Alex wrote:
> On Mon, Jun 10, 2019 at 4:10 PM Kuntal Ghosh
> wrote:
>> I think what I'm trying to say is different.
>>
>> For my case, the sequence is as following:
>> 1. Transaction A has deleted a tuple, say t1 and got committed.
>> 2. Index A has been created s
On Mon, 10 Jun 2019 at 20:11, Amit Langote wrote:
>
> On Sun, Jun 9, 2019 at 5:29 AM David Rowley
> > I also split this out into its own paragraph since it's talking about
> > something quite different from the previous paragraph.
>
> Did you miss to split? In v4 patches, I still see this point
>
On Mon, Jun 10, 2019 at 5:05 PM Michael Paquier wrote:
>
> On Fri, Jun 07, 2019 at 06:07:34PM +0900, Masahiko Sawada wrote:
> > We support ALTER TABLE ADD COLUMN .. GENERATED ALWAYS AS .. but the
> > doc is missing it. Attached small patch fixes this.
>
> Your patch updates the section related to
Here is a small patch to reorder header files in postgres_fdw.c and
connection.c in alphabetical order.
Best regards,
Etsuro Fujita
reorder-c-includes.patch
Description: Binary data
Thanks so much.
I understand now.
Best Regards,
Zhenghua Lyu
On Mon, Jun 10, 2019 at 3:22 PM Kuntal Ghosh
wrote:
> On Mon, Jun 10, 2019 at 12:42 PM Etsuro Fujita
> wrote:
>
>> Hi,
>>
>> On Mon, Jun 10, 2019 at 3:50 PM Kuntal Ghosh
>> wrote:
>> > On Mon, Jun 10, 2019 at 11:31 AM Zhenghua Lyu
On Mon, Jun 10, 2019 at 4:10 PM Kuntal Ghosh
wrote:
> On Mon, Jun 10, 2019 at 1:30 PM Alex wrote:
> >
> >
> >
> > On Mon, Jun 10, 2019 at 3:28 PM Kuntal Ghosh
> wrote:
> >>
> >> On Mon, Jun 10, 2019 at 12:15 PM Alex wrote:
> >>>
> >>> HEAPTUPLE_RECENTLY_DEAD, /* tuple is dead, but not deletab
On Thu, Jun 6, 2019 at 5:58 PM Etsuro Fujita wrote:
> I made stricter an assertion test I added on retrieved_rows. Also, I
> did some editorialization further and added the commit message.
> Attached is an updated version of the patch. If there are no
> objections, I'll commit the patch.
I noti
Hi,
Thanks for the updated patches.
On Sun, Jun 9, 2019 at 5:29 AM David Rowley
wrote:
> On Fri, 7 Jun 2019 at 19:00, Amit Langote wrote:
> > Maybe:
> >
> > ...Removal of unwanted data is also a factor to consider when
> > planning your partitioning strategy as an entire partition can be
>
On Mon, Jun 10, 2019 at 1:30 PM Alex wrote:
>
>
>
> On Mon, Jun 10, 2019 at 3:28 PM Kuntal Ghosh
> wrote:
>>
>> On Mon, Jun 10, 2019 at 12:15 PM Alex wrote:
>>>
>>> HEAPTUPLE_RECENTLY_DEAD, /* tuple is dead, but not deletable yet */
>>>
>>> It is a tuple which has been deleted AND committed b
On Fri, Jun 07, 2019 at 06:07:34PM +0900, Masahiko Sawada wrote:
> We support ALTER TABLE ADD COLUMN .. GENERATED ALWAYS AS .. but the
> doc is missing it. Attached small patch fixes this.
Your patch updates the section related to constraint_name. Don't you
need an extra line for the "action" par
On Mon, Jun 10, 2019 at 3:28 PM Kuntal Ghosh
wrote:
> On Mon, Jun 10, 2019 at 12:15 PM Alex wrote:
>
>> HEAPTUPLE_RECENTLY_DEAD, /* tuple is dead, but not deletable yet */
>>
>> It is a tuple which has been deleted AND committed but before the delete
>> there is a transaction started but not c
On Mon, Jun 10, 2019 at 01:57:14PM +0900, Kyotaro Horiguchi wrote:
> If we don't do that, translation lines in po files are
> useless. prep_stauts must be removed from TETTEXT_TRIGGERS, and a
> comment that explains the reason for not translating.
>
> Any opinions?
I agree with your point that it
On Sat, Jun 08, 2019 at 08:26:07AM -0700, Andres Freund wrote:
> We have plenty other callbacks that aren't bulletproof, so I don't think
> this is really something we should / can change in isolation here.
Good point. I was looking at the check callbacks in guc.c for similar
changes, and missed
On Mon, Jun 10, 2019 at 12:15 PM Alex wrote:
> HEAPTUPLE_RECENTLY_DEAD, /* tuple is dead, but not deletable yet */
>
> It is a tuple which has been deleted AND committed but before the delete
> there is a transaction started but not committed. Let call this transaction
> as Transaction A.
>
> i
On Mon, Jun 10, 2019 at 12:42 PM Etsuro Fujita
wrote:
> Hi,
>
> On Mon, Jun 10, 2019 at 3:50 PM Kuntal Ghosh
> wrote:
> > On Mon, Jun 10, 2019 at 11:31 AM Zhenghua Lyu wrote:
> >> 2. Is the case above a bug or a feature?
> >>
> > IMHO, it looks like an expected behaviour of a correct transactio
Hi,
On Mon, Jun 10, 2019 at 3:50 PM Kuntal Ghosh wrote:
> On Mon, Jun 10, 2019 at 11:31 AM Zhenghua Lyu wrote:
>> 2. Is the case above a bug or a feature?
>>
> IMHO, it looks like an expected behaviour of a correct transaction management
> implementation.
This is documented behavior; see the C
79 matches
Mail list logo
