On 1 June 2018 at 16:56, Ashutosh Bapat wrote:
> On Fri, Jun 1, 2018 at 11:10 AM, Simon Riggs wrote:
>>
>> Using a central coordinator also allows multi-node transaction
>> control, global deadlock detection etc..
>
> But that becomes an SPOF and then we have to configure a standby for
> that. I
Congratulations Everyone!!!
Thanks.
--
Regards,
Neha Sharma
On Sat, Jun 2, 2018 at 12:12 PM, Ashutosh Sharma
wrote:
> Congrats everyone and special congratulations to Amit for becoming the
> first Indian PostgreSQL committer !!
>
> On Sat, Jun 2, 2018 at 9:40 AM, Nikolay Samokhvalov > wrote:
>
Congratulations everyone! Indeed great achievement.
Regards,
Haroon
On Sat, Jun 2, 2018, 02:05 Tom Lane wrote:
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Micha
Hi Tom,
Thanks for your comments, I do forget create type shell.
But even if I add this line still does not work.
Here is the commit that can demo my bug (
https://github.com/charles-cui/pg_thrift/commit/8b43f3e2172f4a1b4e61211f7d76b061a90c38f7
)
To see it, download the repo and do make install
On 28/05/18 15:08, Michael Paquier wrote:
On Mon, May 28, 2018 at 12:26:37PM +0300, Heikki Linnakangas wrote:
Sounds good.
Okay. Done this way as attached. If the backend forces anything else
than SCRAM then the client gets an immediate error if channel binding is
required, without waiting f
On 29/05/18 17:15, Michael Paquier wrote:
Hi all,
While reviewing the MSVC code, I have noticed that pg_config.h.win32 is
forgetting about a couple of flags defined in pg_config.h.in for v11
development. Forgetting some of them is problematic, and here are the
ones I spotted:
- HAVE_LDAP_INITIA
Heikki Linnakangas writes:
> But yeah, clearly those are missing from pg_config.h.win32 at the
> moment. It's not actually clear to me, when that file is (supposed to
> be) updated. Are you supposed to remember to update it, whenever you
> update pg_config.h.in? Or does someone update it with t
> "Charles" == Charles Cui writes:
Charles> Hi Tom,
Charles>Thanks for your comments, I do forget create type shell.
Charles> But even if I add this line still does not work.
Charles> Here is the commit that can demo my bug (
Charles>
https://github.com/charles-cui/pg_thrift/commit/
Thanks Andrew, that should be the reason!
Forget thrift_binary_in is not a simple function, it is always coupled with
output function.
2018-06-02 10:44 GMT-07:00 Andrew Gierth :
> > "Charles" == Charles Cui writes:
>
> Charles> Hi Tom,
> Charles>Thanks for your comments, I do forget cr
On Sat, Jun 02, 2018 at 01:19:41PM -0400, Heikki Linnakangas wrote:
> I wouldn't be too sorry to just bump our minimum requirements for Windows,
> in v11. Assuming that recent-enough versions of OpenLSAP and OpenSSL are
> readily available on Windows.
s/OpenLSAP/OpenLDAP/.
It may be better to loo
On Sat, Jun 02, 2018 at 01:24:41PM -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
>> But yeah, clearly those are missing from pg_config.h.win32 at the
>> moment. It's not actually clear to me, when that file is (supposed to
>> be) updated. Are you supposed to remember to update it, whenever
Awesome!
Michael
On Sat, Jun 2, 2018 at 6:06 AM, Haroon . wrote:
> Congratulations everyone! Indeed great achievement.
>
> Regards,
> Haroon
>
> On Sat, Jun 2, 2018, 02:05 Tom Lane wrote:
>
>> The core team is pleased to announce the appointment of seven
>> new Postgres committers:
>>
>> Etsur
On 08/03/18 14:13, Peter Eisentraut wrote:
There are two failures in the SSL tests that I cannot explain. The
tests are for some rather obscure configurations, so the changed
behaviors are not obviously wrong, perhaps legitimate implementation
differences. But someone wrote those tests with a p
Hi,
Patrick Francelle and I encountered this situation where there was a check
constraint on a table using a function to enforce a constraint across two
different tables. When using pg_dump to dump structure and data we found
out we couldn't restore it because tables weren't dumped in the right or
Michael Paquier writes:
> Navigating through the logs of the buildfarm, it is actually not really
> easy to find out which version of OpenSSL a build is using at compile
> time. Perhaps we would want first to report this information?
+1 if we can figure a way to do it. ISTR having looked for a
=?UTF-8?Q?L=C3=A6titia_Avrot?= writes:
> ... By looking at the constraint documentation page, we found out there was
> nothing about it. So we decided to write a first version of a patch.
Hi Lætitia! Please add this thread to the open commitfest to make
sure we don't forget about it. (The open
On 02/06/18 17:09, Tom Lane wrote:
Michael Paquier writes:
... Making HAVE_X509_GET_SIGNATURE_NID a hard requirement bumps the
minimal version of OpenSSL supported to 1.0.2, which is something I
would not feel much sorry about either like Heikki, as I have heard of
many vendors maintaining Open
On Fri, Jun 1, 2018 at 11:53 AM, Tom Lane wrote:
>
> I agree though that it seems strange to special-case SQLValueFunction
> rather than any-stable-expression. As long as the evaluation happens
> at executor start (i.e. with the query's run-time snapshot) it should
> be reasonable to simplify an
Hi Amit
On Mon, May 28, 2018 at 4:25 AM, Amit Kapila wrote:
>
> This is one way, but I think there are other choices as well. We can
> identify and flush all the dirty (local) buffers for the relation
> being accessed parallelly. Now, once the parallel operation is
> started, we won't allow per
Heikki Linnakangas writes:
> On 02/06/18 17:09, Tom Lane wrote:
>> More concerning is that RHEL6 is on 1.0.1e:
> I was only thinking of requiring 1.0.2 on Windows.
Ah. Personally, I don't care about that case, but maybe somebody
else wants to speak for it?
regards, tom
On Sat, Jun 2, 2018 at 4:05 AM, Simon Riggs wrote:
> On 1 June 2018 at 16:56, Ashutosh Bapat
> wrote:
>> On Fri, Jun 1, 2018 at 11:10 AM, Simon Riggs wrote:
>>>
>>> Using a central coordinator also allows multi-node transaction
>>> control, global deadlock detection etc..
>>
>> But that becomes
On Sat, Jun 2, 2018 at 5:16 PM, Jeff Janes wrote:
> On Fri, Jun 1, 2018 at 11:53 AM, Tom Lane wrote:
>>
>>
>> I agree though that it seems strange to special-case SQLValueFunction
>> rather than any-stable-expression. As long as the evaluation happens
>> at executor start (i.e. with the query's
Jeff Janes writes:
> On Fri, Jun 1, 2018 at 11:53 AM, Tom Lane wrote:
>> It's worth questioning whether this is a bug fix or an improvement.
>> If the latter, it probably ought to wait for v12.
> If explaining the change requires reference to tokens from the source code,
> rather than something
Some assorted comments:
1.
-When a column is added with ADD COLUMN, all existing
-rows in the table are initialized with the column's default value
-(NULL if no DEFAULT clause is specified).
-If there is no DEFAULT clause, this is merely a
metadata
-change and does not require
Resending to -hackers
https://www.postgresql.org/message-id/20180527022401.GA20949%40telsasoft.com
Is that considered an actionable problem?
Encountered consistently while trying to reproduce the vacuum full
pg_statistic/toast_2619 bug; while running a loop around VAC FULL and more in
another ses
On 29 May 2018 at 07:28, Vik Fearing wrote:
> The tab completion for the TABLE command includes indexes but that's a
> bug. Attached is a trivial patch to fix it.
Looks correct to me.
You lose tab completion for "TABLE pg_toast.pg_toast_xyz" but that
seems reasonable. If people want to query t
On 2 June 2018 at 22:46, Ashutosh Bapat wrote:
And that is why both XL and "FDW approach" rely on a central coordinator.
>>>
>>> I don't think we ever specified that "FDW approach" "relies" on a
>>> central coordinator. One could configure and setup a cluster with
>>> multiple coordinators u
27 matches
Mail list logo
