On Fri, 17 Jul 2020 at 11:06, Masahiro Ikeda wrote:
>
> On 2020-07-16 13:16, Masahiko Sawada wrote:
> > On Tue, 14 Jul 2020 at 17:24, Masahiro Ikeda
> > wrote:
> >>
> >> > I've attached the latest version patches. I've incorporated the review
> >> > comments I got so far and improved locking stra
On Fri, 2020-07-17 at 05:21 +, tsunakawa.ta...@fujitsu.com wrote:
> From: Masahiko Sawada
> I have briefly checked the only oracle_fdw but in general I think that
> > if an existing FDW supports transaction begin, commit, and rollback,
> > these can be ported to new FDW transaction APIs easily
On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker wrote:
> Noah Misch writes:
> > On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
> >> Along the same line, I read at [1]
> >>
> >> Because it has been such a long time, and because some of the changes
> >> potenti
On Thu, Jul 16, 2020 at 8:44 PM Robert Haas wrote:
>
> On Wed, Jul 15, 2020 at 11:51 AM Andres Freund wrote:
> > Indeed looks like a typo. Robert, do you concur?
>
> Yes, that's definitely unintentional. Oops.
>
Pushed the fix.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprised
On Thu, Jul 16, 2020 at 6:43 PM Robert Haas wrote:
>
> On Wed, Jul 15, 2020 at 11:14 PM Amit Kapila wrote:
> > The attached patch fixes the comments. Let me know if you think I
> > have missed anything or any other comments.
>
> If it's safe now, why not remove the error check?
>
I think it is
On Fri, Jul 10, 2020 at 09:58:28AM +0530, vignesh C wrote:
> Thanks for reviewing the patch.
> This changes is already present in the document, no need to make any
> changes as shown below:
>
> COPY table_name [ ( column_name [, ...] ) ]
> FROM { 'filename' | PROGRAM 'command' | STDIN }
>
Hi,
On Fri, Jul 17, 2020 at 7:01 AM Michael Paquier wrote:
>
> On Thu, Jul 16, 2020 at 10:55:45PM -0400, Alvaro Herrera wrote:
> > Oh, ugh, I don't like that part much. If you run connections through a
> > connection pooler, it's going to be everywhere. Let's put it there only
> > if the connect
From: Masahiko Sawada
I have briefly checked the only oracle_fdw but in general I think that
> if an existing FDW supports transaction begin, commit, and rollback,
> these can be ported to new FDW transaction APIs easily.
Does oracle_fdw support begin, commit and rollback?
And most importantly,
Hi,
I applied your v15 patchset to master
ed2c7f65bd9f15f8f7cd21ad61602f983b1e72e9. Here are three feedback points
for you:
= 1. Build error when WAL_DEBUG is defined manually =
How to reproduce:
$ sed -i -E -e 's|^/\* #define WAL_DEBUG \*/$|#define WAL_DEBUG|'
src/include/pg_config_manual.h
On Tue, Jul 07, 2020 at 01:06:38PM +, ahsan hadi wrote:
> Tested the tab complete for copy command, it provides the tab
> completion after providing the "TO|FROM filename With|Where". Does
> this require any doc change?
No documentation changes are required for that, as long as they match
the
On Fri, Jul 17, 2020 at 12:13:08PM +0900, Kyotaro Horiguchi wrote:
> I checked through http:// URLs in the documentation.
It would be better to get all that fixed and backpatched. Is somebody
already looking into that?
--
Michael
signature.asc
Description: PGP signature
On Thu, Jul 16, 2020 at 10:55:45PM -0400, Alvaro Herrera wrote:
> Oh, ugh, I don't like that part much. If you run connections through a
> connection pooler, it's going to be everywhere. Let's put it there only
> if the connection *is* running a parallel query, without being too
> stressed about t
On 7/16/20 9:35 PM, Etsuro Fujita wrote:
On Thu, Jul 16, 2020 at 8:56 PM Andrey Lepikhov
wrote:
On 7/16/20 9:55 AM, Etsuro Fujita wrote:
On Tue, Jul 14, 2020 at 12:48 AM Alexey Kondratov
wrote:
Some real-life test queries show, that all single-node queries aren't
pushed-down to the require
Hi,
> AFAICS, we can already accomplish basically the same thing as what you want to
> do like this:
>
> alter table foo set unlogged;
> copy foo from ...;
> alter table foo set logged;
This didn't satisfy what I wanted.
In case that 'foo' has huge amount of rows at the beginning,
this example wo
On Wed, Jul 15, 2020 at 02:54:37PM +0200, Magnus Hagander wrote:
> Our Fine Manual (TM) specifies:
> "As an exception, when changing the type of an existing column, if the
> USING clause does not change the column contents and the old type is either
> binary coercible to the new type or an unconstr
On Sun, Jul 12, 2020 at 7:25 AM Soumyadeep Chakraborty
wrote:
> Do you mean that we should have an implementation for
> get_minimal_tuple() for the heap AM and have it return a pointer to the
> minimal tuple from the MINIMAL_TUPLE_OFFSET? And then a caller such as
> tqueueReceiveSlot() will ensure
At Thu, 16 Jul 2020 14:09:17 +0200, Daniel Gustafsson wrote
in
> > On 10 Jul 2020, at 23:55, Daniel Gustafsson wrote:
> >
> >> On 10 Jul 2020, at 23:47, Tom Lane wrote:
> >> Thomas Munro writes:
> >
> >>> The others required minor manual sleuthing to correct; I hope I found
> >>> the correc
On Thu, 16 Jul 2020 at 13:53, tsunakawa.ta...@fujitsu.com
wrote:
>
> Hi Sawada san,
>
>
> I'm reviewing this patch series, and let me give some initial comments and
> questions. I'm looking at this with a hope that this will be useful purely
> as a FDW enhancement for our new use cases, regardl
On 2020-Jul-17, Michael Paquier wrote:
> Please note that this choice comes from BecomeLockGroupLeader(), where
> a leader registers itself in lockGroupLeader, and remains set as such
> as long as the process is alive so we would always get a value for a
> process once it got involved in parallel
On Mon, Jun 22, 2020 at 7:51 AM Odin Ugedal wrote:
> Ahh, thanks. Looks like the Windows stuff isn't autogenerated, so
> maybe this new patch works..
On second thoughts, it seemed like overkill to use configure just to
detect whether macros are defined, so I dropped that and used plain
old #if de
On Fri, Jul 10, 2020 at 01:16:40PM -0400, Alvaro Herrera wrote:
> On 2020-Jul-10, Justin Pryzby wrote:
>> That's what's done.
>>
>> + Process ID of the parallel group leader if this process
>> was
>> + at some point involved in parallel query, otherwise null. For
>> a
>>
On 2020-07-16 13:16, Masahiko Sawada wrote:
On Tue, 14 Jul 2020 at 17:24, Masahiro Ikeda
wrote:
> I've attached the latest version patches. I've incorporated the review
> comments I got so far and improved locking strategy.
I want to ask a question about streaming replication with 2PC.
Are yo
On Thu, May 14, 2020 at 03:50:52PM -0400, Tom Lane wrote:
> I think there's definitely value in corrupting data in some predictable
> (reproducible) way and verifying that the check code catches it and
> responds as expected. Sure, this will not be 100% coverage, but it'll be
> a lot better than 0
On Thu, Jul 16, 2020 at 09:46:03PM +0200, Christoph Berg wrote:
> Or that, yes. (The correct German transliteration is
> "Mitteleuropaeische" with 'ae'.)
tznames/Europe.txt is iso-latin-1-unix for buffer-file-coding-system
since its introduction in d8b5c95, and tznames/Default is using ASCII
as we
Dean Rasheed writes:
> On Thu, 16 Jul 2020, 22:50 Tom Lane, wrote:
>> Actually, after staring at those results awhile longer, I decided
>> they were wrong. The results shown here seem actually sane ---
>> for instance, -Infinity shouldn't "infinitely precede" itself,
>> I think. (Maybe if you g
On Thu, Jul 16, 2020 at 07:21:27PM +0900, Michael Paquier wrote:
> The patch looks good to me.
For the sake of the archives, this has been applied as d66b23b0 and
the buildfarm is green. I have also changed the related CF entry to
reflect what has been done, with Andrew as author, etc:
https://co
On Thu, 16 Jul 2020, 22:50 Tom Lane, wrote:
> I wrote:
> > When the current row's value is +infinity, actual computation of
> > base - offset would yield NaN, making it a bit unclear whether
> > we should consider -infinity to be in-range. It seems to me that
> > we should, as that gives more na
On Thu, Jul 16, 2020 at 4:24 PM Alvaro Herrera
wrote:
> On 2020-Jul-16, David Johnston wrote:
>
> > Instead of a note maybe add a paragraph stating:
> >
> > "This setting is ignored when multiple statements are sent to the server
> as a single command (i.e., via the -c command line option or the
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, passed
James,
I'm on board with the point of pointing out explicitly the "concu
> On 17 Jul 2020, at 00:22, Joe Wildish wrote:
> Attached is a patch for supporting queries in the WHEN expression of
> statement triggers.at?
Hi!,
Please create an entry for this patch in the 2020-09 commitfest to make sure
it's properly tracked:
https://commitfest.postgresql.org/29/
On 2020-Jul-16, David Johnston wrote:
> Instead of a note maybe add a paragraph stating:
>
> "This setting is ignored when multiple statements are sent to the server as a
> single command (i.e., via the -c command line option or the \; meta-command).
> Additionally, it is possible for certain
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, passed
Fabien,
There is a minor typo (works -> work) but overall I'm not a fan
Hi Horiguchi-san,
I'll take a look at that thread and see if I can reproduce with the attached
patch.
It seems like it would directly address this issue. Thanks for taking a look.
Cheers,
John H
On Thu, Jul 16, 2020 at 11:00 AM Kyotaro Horiguchi
wrote:
Hello, John.
At Fri, 10 Jul 2020 20:44
Hi hackers,
Attached is a patch for supporting queries in the WHEN expression of
statement triggers. It is restricted so that the expression can
reference only the transition tables and the table to which the trigger
is attached. This seemed to make the most sense in that it follows what
you
Hackers,
As a reaction to this documentation comment [1] I went through the main
paragraph of the Database Management Overview and came up with the reworded
and expanded page. Proposed for HEAD only. Added to the commitfest
2020-09.
1.
https://www.postgresql.org/message-id/flat/57083a441ddd2f3b
I wrote:
> When the current row's value is +infinity, actual computation of
> base - offset would yield NaN, making it a bit unclear whether
> we should consider -infinity to be in-range. It seems to me that
> we should, as that gives more natural-looking results in the test
> cases, so that's how
Re: Tom Lane
> > MESZ 7200 D # Mitteleuropäische Sommerzeit (German)
> > # (attested in IANA comments though not their code)
>
> > It's not important for anything, just general sanity. (Spotted by
> > Debian's package checker, lintian.)
>
> Hm. TBH, my first reaction is
On Mon, Jul 6, 2020 at 2:06 PM Mark Dilger wrote:
> The v10 patch without these ideas is here:
Along the lines of what Alvaro was saying before, I think this
definitely needs to be split up into a series of patches. The commit
message for v10 describes it doing three pretty separate things, and I
Dean Rasheed questioned this longstanding behavior:
regression=# SELECT 'nan'::float8 / '0'::float8;
ERROR: division by zero
After a bit of research I think he's right: per IEEE 754 this should
yield NaN, not an error. Accordingly I propose the attached patch.
This is probably not something to
Hi
I am sending another patch that tries to allow CachedPlans for CALL
statements. I think this patch is very accurate, but it is not nice,
because it is smudging very precious reference counting for CachedPlans.
Current issue:
==
I found a problem with repeated CALL statements from DO c
Dean Rasheed pointed out that in_range for float4/float8 seems to be
doing the wrong thing for infinite offsets, and after some testing
I concur that it is. For example, a sort key of '-infinity' should
be considered to be in-range for a range specified as RANGE BETWEEN
'inf' PRECEDING AND 'inf' P
On 02.07.2020 20:11, Peter Geoghegan wrote:
On Thu, Jul 2, 2020 at 7:48 AM Daniel Gustafsson wrote:
This patch fails to apply to HEAD due to conflicts in nbtpage.c, can you please
submit a rebased version?
I attach the rebased patch series.
Thanks
It's impressive that this check helped to f
On Thu, Jul 16, 2020 at 8:52 PM Bharath Rupireddy
wrote:
>
> On Thu, Jul 16, 2020 at 7:44 PM Amit Langote wrote:
> >
> > On Wed, Jul 15, 2020 at 1:06 PM vignesh C wrote:
> > > On Wed, Jul 15, 2020 at 8:03 AM Amit Langote
> > > wrote:
> > > > On Tue, Jul 14, 2020 at 10:23 PM vignesh C wrote:
>
On 2020-07-16 19:35, Etsuro Fujita wrote:
On Thu, Jul 16, 2020 at 8:56 PM Andrey Lepikhov
wrote:
On 7/16/20 9:55 AM, Etsuro Fujita wrote:
On Tue, Jul 14, 2020 at 12:48 AM Alexey Kondratov
wrote:
> Some real-life test queries show, that all single-node queries aren't
> push
Hi:
Every pg_type has typinput/typoutput and typreceive/typsend
they are used for text format and binary format accordingly. What is
the difference between them in practice? For example, for a PG user,
shall they choose binary format or text format? Actually I don't even
know how to set this i
Dean Rasheed writes:
> I had a look at this, and I think it's mostly in good shape. It looks
> like everything from the first message in this thread has been
> resolved, except I don't know about the jsonpath stuff, because I
> haven't been following that.
Thanks for the careful review! Yeah, Al
On 2020-07-16 14:56, Andrey Lepikhov wrote:
On 7/16/20 9:55 AM, Etsuro Fujita wrote:
On Wed, Jul 15, 2020 at 9:02 PM Etsuro Fujita
wrote:
On Wed, Jul 15, 2020 at 12:12 AM Alexey Kondratov
wrote:
On 2020-07-14 15:27, Ashutosh Bapat wrote:
On Tue, Jul 14, 2020 at 12:48 AM Alexey Kondratov
wr
On Thu, Jul 16, 2020 at 8:56 PM Andrey Lepikhov
wrote:
> On 7/16/20 9:55 AM, Etsuro Fujita wrote:
> On Tue, Jul 14, 2020 at 12:48 AM Alexey Kondratov
> wrote:
> > Some real-life test queries show, that all single-node queries aren't
> > pushed-down to the required node. For exa
Andres Freund writes:
> I think it'd be a good plan to adopt the beta on master.
> We already have parts of it backpacked, there have been things we couldn't
> easily do because of bugs in 2.69. There aren't that many changes to
> configure it total, and particularly not in the back branches. S
On Thu, Jul 16, 2020 at 10:00 AM Robert Haas wrote:
> I see your point, though: the tuple has to be able to survive
> HOT-pruning in order to cause a problem when we check whether it needs
> freezing.
Here's an example where the new sanity checks fail on an invisible
tuple without any concurrent
Jesse Zhang writes:
> For more kicks, I don't even think this is restricted to volatile
> functions only. To stir the pot, it's conceivable that planner might
> produce the following plan
> Seq Scan on pg_temp_3.foo
> Output: foo.a
> Filter: (SubPlan 1)
> SubPlan 1
> -> WindowAgg
>
Hi,
On July 16, 2020 8:24:15 AM PDT, Tom Lane wrote:
>Noah Misch writes:
>> On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
>More ambitiously, we could just adopt 2.69b in HEAD and see what
>happens,
>planning to revert only if things break. The cost to that is that
>committers who wa
Andrew Dunstan writes:
> On 7/16/20 11:24 AM, Tom Lane wrote:
>> More ambitiously, we could just adopt 2.69b in HEAD and see what happens,
>> planning to revert only if things break. The cost to that is that
>> committers who want to commit configure.ac changes would have to install
>> 2.69b. Bu
Hi Tom and Zhenghua,
On Thu, Jul 16, 2020 at 8:18 AM Tom Lane wrote:
>
> Jesse Zhang writes:
> > You are right, no they are not consistent. But Neither plans is
> > incorrect:
>
> > 1. In the first query, it's semantically permissible to evaluate
> > timeofday() for each pair of (c1, c2), and th
On 7/16/20 11:24 AM, Tom Lane wrote:
> Noah Misch writes:
>> On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
>>> Maybe we should do some pro-active testing, rather than just waiting for
>>> 2.70 to get dropped on us? God knows how long it will be until 2.71.
>> Sounds good. A cheap o
Noah Misch writes:
> On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
>> Maybe we should do some pro-active testing, rather than just waiting for
>> 2.70 to get dropped on us? God knows how long it will be until 2.71.
> Sounds good. A cheap option would be to regenerate with 2.70, push
On Thu, Jul 16, 2020 at 7:44 PM Amit Langote wrote:
>
> On Wed, Jul 15, 2020 at 1:06 PM vignesh C wrote:
> > On Wed, Jul 15, 2020 at 8:03 AM Amit Langote
> > wrote:
> > > On Tue, Jul 14, 2020 at 10:23 PM vignesh C wrote:
> > > > Rest of the changes looked fine to me. Also I noticed that
> > >
Jesse Zhang writes:
> You are right, no they are not consistent. But Neither plans is
> incorrect:
> 1. In the first query, it's semantically permissible to evaluate
> timeofday() for each pair of (c1, c2), and the plan reflects that.
> (Notice that the parallel nature of the plan is just noise h
On Wed, Jul 15, 2020 at 11:51 AM Andres Freund wrote:
> Indeed looks like a typo. Robert, do you concur?
Yes, that's definitely unintentional. Oops.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> It's hardly surprising that datumCopy would segfault when given a
> Tom> null "value" and told it is pass-by-reference. However, to get to
> Tom> the datumCopy call, we must have passed the MemoryContextContains
> Tom> check on that ver
On Thu, Jul 16, 2020 at 1:16 AM Satish S wrote:
> I have a cluster of three nodes A, B, C and I'm using postgres bdr for
> replication
>
This isn’t the right mailing list for this topic. Core PostgreSQL doesn’t
have BDR so this seems like it should be directed to whichever product is
providing t
Christoph Berg writes:
> Is there any reason why src/timezone/tznames/Europe.txt is encoded in
> latin1 and not utf-8?
> The offending lines are these timezones:
> MESZ 7200 D # Mitteleuropäische Sommerzeit (German)
> # (attested in IANA comments though not their code)
On Wed, Jul 15, 2020 at 1:06 PM vignesh C wrote:
> On Wed, Jul 15, 2020 at 8:03 AM Amit Langote wrote:
> > On Tue, Jul 14, 2020 at 10:23 PM vignesh C wrote:
> > > Rest of the changes looked fine to me. Also I noticed that
> > > commit message was missing in the patch.
>>
> > Please see the attac
‐‐‐ Original Message ‐‐‐
On Saturday, July 11, 2020 3:16 PM, vignesh C wrote:
> On Mon, Jul 6, 2020 at 1:24 PM Georgios gkokola...@protonmail.com wrote:
>
> > ‐‐‐ Original Message ‐‐‐
> > On Monday, July 6, 2020 3:12 AM, Michael Paquier mich...@paquier.xyz wrote:
> >
> > > On Su
On Wed, Jul 15, 2020 at 11:41 AM Andres Freund wrote:
> > Do you have a reason for believing that INSERT ... DELETE is going to
> > be better than UPDATE? It seems to me that either way you can end up
> > with a deleted and thus invisible tuple that you still can't get rid
> > of.
>
> None of the
On Tue, 14 Jul 2020 at 22:47, Andres Freund wrote:
> Hi,
>
> On 2020-07-14 22:28:48 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > What is the gain in having these checks? recv functions need to be safe
> > > against arbitrary input, so a type crosscheck doesn't buy additional
> > > safe
On 7/15/20 7:36 PM, Tom Lane wrote:
> I guess rawhide is the RH thing that tracks the bleeding edge?
> Yup. Possibly we should recommend that buildfarm owners running on
> non-stable platforms disable autoconf result caching --- I believe
> that's "use_accache => undef" in the configuration file
On Wed, Jul 15, 2020 at 11:14 PM Amit Kapila wrote:
> The attached patch fixes the comments. Let me know if you think I
> have missed anything or any other comments.
If it's safe now, why not remove the error check?
(Is it safe? Could there be other problems?)
--
Robert Haas
EnterpriseDB: htt
On Thu, Jul 16, 2020 at 2:12 AM Prabhat Sahu
wrote:
> Hi All,
> I was testing the feature on top of v3 patch and found the "pg_upgrade"
> failure after keeping "alter system read only;" as below:
>
That's expected. You can't perform a clean shutdown without writing WAL.
--
Robert Haas
Enterpri
> On 10 Jul 2020, at 23:55, Daniel Gustafsson wrote:
>
>> On 10 Jul 2020, at 23:47, Tom Lane wrote:
>> Thomas Munro writes:
>
>>> The others required minor manual sleuthing to correct; I hope I found
>>> the correct ISN ranges page. Please see attached.
>>
>> I didn't actually check any of t
Hi Jesse,
you are right.
For the nestloop case, they are identical.
I do not come up with hash join or mergejoin case in pg now.
From: Jesse Zhang
Sent: Thursday, July 16, 2020 2:16 PM
To: Zhenghua Lyu
Cc: Amit Kapila ; PostgreSQL Hackers
Subject: Re: Volatil
On 7/16/20 9:55 AM, Etsuro Fujita wrote:
On Wed, Jul 15, 2020 at 9:02 PM Etsuro Fujita wrote:
On Wed, Jul 15, 2020 at 12:12 AM Alexey Kondratov
wrote:
On 2020-07-14 15:27, Ashutosh Bapat wrote:
On Tue, Jul 14, 2020 at 12:48 AM Alexey Kondratov
wrote:
Some real-life test queries show, th
On Thu, Jul 16, 2020 at 10:58:58AM +0200, Peter Eisentraut wrote:
> if test "$with_openssl" = yes ; then
>dnl Order matters!
> + AC_DEFINE(OPENSSL_API_COMPAT, [10001],
> +[Define to the OpenSSL API version in use. This avoids
>deprecation warnings from newer OpenSSL versions.]
On Thu, Jul 16, 2020 at 4:04 PM Masahiko Sawada
wrote:
>
> On Thu, 16 Jul 2020 at 18:16, Amit Kapila wrote:
> >
> > On Thu, Jul 16, 2020 at 1:45 PM Masahiko Sawada
> > wrote:
> > >
> > > A possible solution would be to add an in-use flag to
> > > PgStat_ReplSlotStats indicating whether the stats
Noah Misch writes:
> On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > It was mentioned elsewhere in passing that a new Autoconf release might
>> > be coming. That one will warn about the old naming "configure.in" and
>> > request "configure.ac". So w
On Thu, 16 Jul 2020 at 18:16, Amit Kapila wrote:
>
> On Thu, Jul 16, 2020 at 1:45 PM Masahiko Sawada
> wrote:
> >
> > On Thu, 16 Jul 2020 at 15:53, Amit Kapila wrote:
> > >
> > > On Fri, Jul 10, 2020 at 2:42 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Fri, Jul 10, 2020 at 7:23 AM Masahiko S
On Wed, Jul 15, 2020 at 11:04:28AM -0400, Andrew Dunstan wrote:
> This is the simplest invocation I found to be reliable on msys2 (and it
> took me a long time to find). If you have a tested alternative please
> let me know.
Having a working MSYS environment is still on my TODO list :)
> I don't
Is there any reason why src/timezone/tznames/Europe.txt is encoded in
latin1 and not utf-8?
The offending lines are these timezones:
MESZ 7200 D # Mitteleuropäische Sommerzeit (German)
# (attested in IANA comments though not their code)
MEZ 3600# Mitteleuropäis
On Thu, Jul 16, 2020 at 8:44 AM Amit Kapila wrote:
>
> On Wed, Jul 15, 2020 at 8:06 AM Amit Kapila wrote:
> >
> > On Wed, Jul 15, 2020 at 12:32 AM Robert Haas wrote:
> > >
> > > On Sat, Jul 11, 2020 at 8:37 AM Dilip Kumar wrote:
> > > > I have just notice that the parallelism is off even for th
Hi Takamichi-san,
On Tue, Jul 14, 2020 at 8:26 PM osumi.takami...@fujitsu.com
wrote:
>
> Amit san
>
>
> Hello. I've tested your patch.
Thanks for that.
> Just small comment about your patch.
> I felt the test you added in update.sql could be simpler or shorter in other
> form.
> Excuse me if I
Re: Tom Lane
> Given the apparently-can't-happen situation at the call site,
> and the fact that we're not seeing similar failures reported
> elsewhere (and note that every line shown above is at least
> five years old), I'm kind of forced to the conclusion that this
> is a compiler bug. Does adju
On Wed, Jul 15, 2020 at 6:25 PM Magnus Hagander wrote:
>
> Our Fine Manual (TM) specifies:
> "As an exception, when changing the type of an existing column, if the USING
> clause does not change the column contents and the old type is either binary
> coercible to the new type or an unconstrained
On Thu, Jul 16, 2020 at 1:45 PM Masahiko Sawada
wrote:
>
> On Thu, 16 Jul 2020 at 15:53, Amit Kapila wrote:
> >
> > On Fri, Jul 10, 2020 at 2:42 PM Amit Kapila wrote:
> > >
> > > On Fri, Jul 10, 2020 at 7:23 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Thu, 9 Jul 2020 at 12:11, Amit Kapil
Hi Andrey,
Thanks for this work. I have been reading through your patch and
here's a what I understand it does and how:
The patch aims to fix the restriction that COPYing into a foreign
table can't use multi-insert buffer mechanism effectively. That's
because copy.c currently uses the ExecForei
On 2020-07-13 15:38, Tom Lane wrote:
Peter Eisentraut writes:
where would be a good place to define
OPENSSL_API_COMPAT?
Actually, it would be most formally correct to set it using AC_DEFINE in
configure.in, so that configure tests see it.
Yeah, very good point.
New patch done that way.
On Thu, 16 Jul 2020 at 15:53, Amit Kapila wrote:
>
> On Fri, Jul 10, 2020 at 2:42 PM Amit Kapila wrote:
> >
> > On Fri, Jul 10, 2020 at 7:23 AM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, 9 Jul 2020 at 12:11, Amit Kapila wrote:
> > > >
> > > > On Wed, Jul 8, 2020 at 1:14 PM Masahiko Sawada
>
Hi,
I have a cluster of three nodes A, B, C and I'm using postgres bdr for
replication.
I have some code to execute after a value change in the table, for this I
have added a trigger.
When I call POST REST API from any one of the nodes it will execute the
code, and on all other nodes the trigger
87 matches
Mail list logo
