On Thu, May 4, 2017 at 8:37 PM, Heikki Linnakangas wrote:
> On 05/03/2017 08:40 PM, Tom Lane wrote:
>>
>> The other question I can think to ask is what will happen during
>> pg_upgrade, given an existing installation with one or more passwords
>> stored plain. If the answer is "silently convert t
On Fri, May 5, 2017 at 6:10 PM, MauMau wrote:
> The pgoutput is not built with MSVC. The attached patch fixes this.
> I confirmed that a few INSERTs were replicated correctly.
>
> Should I add this matter in the PostgreSQL 10 Open Items page?
Yes, with Peter as committer and Petr as owner.
+
On Fri, May 5, 2017 at 5:33 PM, Pavan Deolasee wrote:
>
>
> On Fri, May 5, 2017 at 10:56 AM, Michael Paquier
> wrote:
>>
>> On Wed, May 3, 2017 at 12:25 AM, Peter Eisentraut
>>
>>
>> >>> Can we prevent HOT pruning during logical decoding?
On Wed, May 3, 2017 at 12:25 AM, Peter Eisentraut
wrote:
> On 5/2/17 10:08, Michael Paquier wrote:
>> On Tue, May 2, 2017 at 9:30 PM, Peter Eisentraut
>> wrote:
>>> On 5/2/17 03:11, Petr Jelinek wrote:
>>>> logical decoding can theoretically
>>>&
On Wed, May 3, 2017 at 9:57 PM, Magnus Hagander wrote:
>
>
> On Wed, May 3, 2017 at 2:25 PM, Michael Paquier
> wrote:
>>
>> On Wed, May 3, 2017 at 8:38 PM, Magnus Hagander
>> wrote:
>> > On Wed, May 3, 2017 at 1:31 PM, Heikki Linnakangas
>> >
onn and that would be a couple of extra lines in any
applications. But honestly, people will appreciate a way to rely on
what the backend uses automatically.
> On 04/27/2017 07:03 AM, Michael Paquier wrote:
>> I think that it is a mistake to move SASLprep out of
>> scram_build_veri
On Wed, May 3, 2017 at 8:38 PM, Magnus Hagander wrote:
> On Wed, May 3, 2017 at 1:31 PM, Heikki Linnakangas wrote:
>> In various threads on SCRAM, we've skirted around the question of whether
>> we should still allow storing passwords in plaintext. I've avoided
>> discussing that in those other t
On Tue, May 2, 2017 at 9:30 PM, Peter Eisentraut
wrote:
> On 5/2/17 03:11, Petr Jelinek wrote:
>> logical decoding can theoretically
>> do HOT pruning (even if the chance is really small) so it's not safe to
>> start logical replication either.
>
> This seems a bit impossible to resolve. On the o
On Tue, May 2, 2017 at 9:27 PM, Peter Eisentraut
wrote:
> On 5/2/17 03:43, Michael Paquier wrote:
>>> I don't think the code covers all because a) the SQL queries are not
>>> covered at all that I can see and b) logical decoding can theoretically
>>> do HOT pr
On Tue, May 2, 2017 at 6:12 PM, Mahi Gurram wrote:
> I'm building some custom extension on top of postgres 9.6.1. As part of
> that, I would like to read Heap Tuple directly from my extension using
> Primary Key.
>
> By default, postgres table index(B-Tree) its PrimaryKey(PK). So, i would
> like t
On Tue, May 2, 2017 at 6:35 PM, zosrothko wrote:
> Hi
>
> I made an extension of VisualStudio that precompiles automaticaly C or
> C++ source with PostgreSQL Embedded SQL. The extension is made of the 3
> files joined and I have no idea where they should be placed in the
> PostgreSQL source tree.
On Tue, May 2, 2017 at 4:11 PM, Petr Jelinek
wrote:
> On 02/05/17 05:35, Michael Paquier wrote:
>> On Tue, May 2, 2017 at 7:07 AM, Peter Eisentraut
>> wrote:
>>> On 4/25/17 21:47, Michael Paquier wrote:
>>>> Attached is an updated patch to reflect that.
>&g
On Tue, May 2, 2017 at 7:07 AM, Peter Eisentraut
wrote:
> On 4/25/17 21:47, Michael Paquier wrote:
>> Attached is an updated patch to reflect that.
>
> I edited this a bit, here is a new version.
Thanks, looks fine for me.
> A variant approach would be to prohibit *all*
On Fri, Apr 28, 2017 at 4:54 PM, Kyotaro HORIGUCHI
wrote:
> I noticed that the precedence between host and hostaddr in a
> connection string is reversed in regard to .pgpass lookup in
> devel.
>
> For example the following connection string uses a .pgpass entry
> with "127.0.0.1", not "hoge".
>
>
On Thu, Apr 27, 2017 at 4:33 PM, Masahiko Sawada wrote:
> On Thu, Apr 27, 2017 at 1:58 PM, Huong Dangminh
> wrote:
>>> On Thu, Apr 27, 2017 at 11:48 AM, Masahiko Sawada
>>> wrote:
>>> > Thank you for updating the patch. Also maybe we can update line in
>>> > PostgresNode.pm where hot_standby is
On Thu, Apr 27, 2017 at 1:25 PM, Ashesh Vashi
wrote:
> - Do we need to provide the method here?
> We have connection object itself, it can decide from the type of connection,
> which method to be used.
Providing the method is not mandatory. If you look upthread... If the
caller of this routine sp
On Thu, Apr 27, 2017 at 11:48 AM, Masahiko Sawada wrote:
> Thank you for updating the patch. Also maybe we can update line in
> PostgresNode.pm where hot_standby is set to on explicitly.
I would refrain from doing that, having some parameters listed in the
tests makes the intention behind those p
On Wed, Apr 26, 2017 at 7:22 PM, Heikki Linnakangas wrote:
> We talked about the alternative where PQencryptPasswordConn() would not look
> at password_encryption, but would always use the strongest possible
> algorithm supported by the server. That would avoid querying the server. But
> then I st
On Thu, Apr 27, 2017 at 2:25 AM, Tom Lane wrote:
> Simon Riggs writes:
>> I've added code following Michael and Tom's comments to the previous
>> patch. New patch attached.
>
> Couple of minor suggestions:
>
> * Rather than deleting the comment for SubTransSetParent entirely,
> maybe make it say
On Thu, Apr 27, 2017 at 7:02 AM, Tom Lane wrote:
> Petr Jelinek writes:
>> On 26/04/17 18:59, Bruce Momjian wrote:
>>> ... it just hangs. My server logs say:
>
>> Yes that's result of how logical replication slots work, the transaction
>> that needs to finish is your transaction. It can be worke
On Wed, Apr 26, 2017 at 10:56 AM, Bruce Momjian wrote:
> First, I don't think RFC references belong in the release notes, let
> alone RFC links.
>
> Second, there seems to be some confusion over what SCRAM-SHA-256 gives
> us over MD5. I think there are a few benefits:
>
> o packets cannot be rep
On Wed, Apr 26, 2017 at 4:53 AM, Simon Riggs wrote:
> On 25 April 2017 at 16:28, Tom Lane wrote:
>> Simon Riggs writes:
>>> I can't see any reason now why overwriteOK should exist at all. I'm
>>> guessing that the whole "overwriteOK" idea was an incorrect response
>>> to xids appearing where the
On Wed, Apr 26, 2017 at 3:17 AM, Peter Eisentraut
wrote:
> On 4/21/17 00:11, Michael Paquier wrote:
>> Hmm. I have been actually looking at this solution and I am having
>> doubts regarding its robustness. In short this would need to be
>> roughly a two-
On Wed, Apr 26, 2017 at 4:26 AM, Peter Eisentraut
wrote:
> On 4/20/17 11:30, Peter Eisentraut wrote:
>> We have a possible solution but need to work out a patch. Let's say
>> next check-in on Monday.
>
> Update: We have a patch that looks promising, but we haven't made much
> progress in reviewin
On Wed, Apr 26, 2017 at 12:26 AM, Heikki Linnakangas wrote:
> Yeah, there is that. But we simply cannot change the signature of an
> existing function. It would not only produce compile-time errors when
> building old applications, which would arguably be a good thing, but it
> would also cause ol
On Wed, Apr 26, 2017 at 12:20 AM, Bruce Momjian wrote:
> On Tue, Apr 25, 2017 at 02:39:40PM +0900, Michael Paquier wrote:
>>
>> Add SCRAM-SHA-256
>> support for password negotiation and storage (Michael
>> Paquier, Heikki Linnakangas)
>>
>>
>> This
On Wed, Apr 26, 2017 at 1:45 AM, David G. Johnston
wrote:
> The first write to a page after a checkpoint is always recorded in the WAL
> as a full page write. Every WAL file since the checkpoint must also be
> copied to the backed up system. The replay of those WAL files is what
> brings the rem
On Tue, Apr 25, 2017 at 2:57 PM, Andres Freund wrote:
> Any chance of formulating these in a version agnostic way, instead of
> copying the same stanza for every version? E.g. using a wildcard or
> such...
Using glob() would be enough for this purpose.
--
Michael
--
Sent via pgsql-hackers ma
stem catalog to store sequence metadata (Andreas
>> +Karlsson)
>> +
>
> OK, fixed. I also moved some "incompatibility" items into the right
> section. FYI, you can see the most recent doc build here:
>
> http://momjian.us/pgsql_docs/release-10.html
Here
On Sat, Apr 22, 2017 at 7:20 AM, Michael Paquier
wrote:
> Do we really want to add a new function or have a hard failure? Any
> application calling PQencryptPassword may trap itself silently if the
> server uses scram as hba key or if the default is switched to that,
> from this p
On Mon, Apr 24, 2017 at 10:03 AM, Vitaly Burovoy
wrote:
> On 4/23/17, Robert Haas wrote:
>> On Thu, Apr 20, 2017 at 12:05 AM, Vitaly Burovoy
>> wrote:
>> But why do we need it? Instead of:
>>
>> ADD GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY
>> SET GENERATED { ALWAYS | BY DEFAULT }
>> DROP I
On Sun, Apr 23, 2017 at 10:15 AM, Petr Jelinek
wrote:
> On 21/04/17 06:11, Michael Paquier wrote:
>> On Fri, Apr 21, 2017 at 12:29 AM, Peter Eisentraut
>> wrote:
>> Hmm. I have been actually looking at this solution and I am having
>> doubts regarding its robustness.
On Mon, Apr 24, 2017 at 7:29 AM, Andrew Dunstan
wrote:
>
> AFAICT, unlike the pg_regress checks, which in the installcheck case run
> against a running instance of postgres, for TAP tests the only
> difference is that that for the check case a temp install is done,
> possibly with some extra contr
On Sun, Apr 23, 2017 at 10:05 PM, Craig Ringer
wrote:
> On 23 Apr. 2017 10:32, "Michael Paquier" wrote:
> On Sun, Apr 23, 2017 at 7:48 AM, Daniel Gustafsson wrote:
>> Skipping the tempdir and instead using ${testname}_data_${name} without a
>> random suffix, we can
On Sun, Apr 23, 2017 at 7:48 AM, Daniel Gustafsson wrote:
> Skipping the tempdir and instead using ${testname}_data_${name} without a
> random suffix, we can achieve this with something along the lines of the
> attached PoC. It works as now (retain of failure, remove on success unless
> overridde
On Sat, Apr 22, 2017 at 11:12 PM, Pierre Ducroquet wrote:
> Following your advice, I went through the source tree and cleaned up most
> instances of that pattern.
> I have attached the corresponding patch to this mail.
> If you think this patch is indeed interesting, what would be the next way to
On Sat, Apr 22, 2017 at 5:04 AM, Heikki Linnakangas wrote:
> I'll continue reviewing the rest of the patch on Monday, but one glaring
> issue is that we cannot add an argument to the existing libpq
> PQencryptPassword() function, because that's part of the public API. It
> would break all applicat
On Fri, Apr 21, 2017 at 9:25 PM, Stephen Frost wrote:
> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>> I think we should adopt that exact format, so that our verifiers are
>> compatible with RFC 5803. It doesn't make any immediate difference,
>> but since there is a standard out there, might as
On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs wrote:
> On 21 April 2017 at 10:20, Heikki Linnakangas wrote:
>> But looking more closely, I think I misunderstood RFC 5803. It *does* in
>> fact specify a single string format to store the verifier in. And the format
>> looks like:
>>
>> SCRAM-SHA-25
On Fri, Apr 21, 2017 at 12:29 AM, Peter Eisentraut
wrote:
> On 4/20/17 07:52, Petr Jelinek wrote:
>> On 20/04/17 05:57, Michael Paquier wrote:
>>> 2nd thoughts here... Ah now I see your point. True that there is no
>>> way to ensure that an unwanted command is
On Fri, Apr 21, 2017 at 11:34 AM, Petr Jelinek
wrote:
> On 20/04/17 23:30, Peter Eisentraut wrote:
>> On 4/20/17 10:19, Petr Jelinek wrote:
>>> Hmm well since this only affects the synchronization of table
>>> states/names, I guess we could just simply do that before we create the
>>> slot as ther
On Thu, Apr 20, 2017 at 8:47 PM, Petr Jelinek
wrote:
> Or you can drop the slot manually on upstream.
Sure, but the point here is that if for example users have
client_min_messages set at least at warning, they may have no idea
that an underlying slot has been created. This is a confusing
experie
On Thu, Apr 20, 2017 at 4:22 PM, Michael Paquier
wrote:
> I am adding an open item.
Just adding something... When a subscription is created, if the step
synchronizing tables fails then CREATE SUBSCRIPTION fails but the slot
remains present on the publisher side, so trying to re-create the s
Hi,
I have noticed the following behavior with DROP SUBSCRIPTION followed
by a cancel request. If the remote replication slot is dropped, the
subscription may still be present locally:
=# CREATE SUBSCRIPTION mysub CONNECTION 'port=5432 user=mpaquier
dbname=mpaquier' PUBLICATION mypub, insert_only;
On Thu, Apr 20, 2017 at 12:40 PM, Michael Paquier
wrote:
> On Thu, Apr 20, 2017 at 4:57 AM, Peter Eisentraut
> wrote:
>> I think the problem with a signal-based solution is that there is no
>> feedback. Ideally, you would wait for all walsenders to acknowledge the
>>
On Thu, Apr 20, 2017 at 4:57 AM, Peter Eisentraut
wrote:
> On 4/19/17 01:45, Michael Paquier wrote:
>> On Tue, Apr 18, 2017 at 3:27 AM, Peter Eisentraut
>> wrote:
>>> I'd imagine the postmaster would tell the walsender that it has started
>>> shutdow
On Wed, Apr 19, 2017 at 7:03 AM, Michael Paquier
wrote:
> On Wed, Apr 19, 2017 at 12:48 AM, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> Tom Lane wrote:
>>>> FWIW, I'm a bit suspicious of relocating the temp stats directory as
>>>> being a rel
On Wed, Apr 19, 2017 at 1:52 PM, Masahiko Sawada wrote:
> On Wed, Apr 19, 2017 at 12:34 PM, Noah Misch wrote:
>> On Sun, Apr 16, 2017 at 07:25:28PM +0900, Fujii Masao wrote:
>>> On Sun, Apr 16, 2017 at 1:19 PM, Noah Misch wrote:
>>> > On Fri, Apr 14, 2017 at 11:58:23PM -0400, Noah Misch wrote:
>
On Tue, Apr 18, 2017 at 3:27 AM, Peter Eisentraut
wrote:
> I'd imagine the postmaster would tell the walsender that it has started
> shutdown, and then the walsender would reject $certain_things. But I
> don't see an existing way for the walsender to know that shutdown has
> been initiated. SIGI
On Wed, Apr 19, 2017 at 12:36 PM, David Rowley
wrote:
> In favour of "location" -> "lsn": Tom, Stephen, David Steel
> In favour of "lsn" -> "location": Peter, Kyotaro
I vote for "location" -> "lsn". I would expect complains about the
current inconsistency at some point, and the function names hav
On Wed, Apr 19, 2017 at 11:09 AM, Jeff Janes wrote:
> Would this bug have been seen in a replica server in the absence of crashes,
> or was it only vulnerable during crash recovery rather than streaming
> replication?
This issue could have been seen on a streaming standby as well,
letting around
On Wed, Apr 19, 2017 at 12:48 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> FWIW, I'm a bit suspicious of relocating the temp stats directory as
>>> being a reliable fix for this.
>
>> It's an SD card (the kind typically used in cameras and phones), not SSD.
>> Saying it's s
On Tue, Apr 18, 2017 at 9:35 PM, Andrew Dunstan
wrote:
>
>
> On 04/18/2017 08:23 AM, Michael Paquier wrote:
>> On Tue, Apr 18, 2017 at 9:13 PM, Andrew Dunstan
>> wrote:
>>> Yeah, but the way you have done it could also to lead to errors unless
>>> you
On Tue, Apr 18, 2017 at 9:13 PM, Andrew Dunstan
wrote:
> Yeah, but the way you have done it could also to lead to errors unless
> you're very careful, as I found on axolotl (which died recently,
> unfortunately). There I had to set the stats_temp directory to a
> branch-specific name so a crash on
On Tue, Apr 18, 2017 at 7:54 PM, Simon Riggs wrote:
> Yeh, this is better. Pushed.
I have been outraced on this one, the error is obvious once you see it ;)
Thanks for the investigation and the fix! I have spent a couple of
hours reviewing the interactions between the shmem entries of 2PC
state
On Tue, Apr 18, 2017 at 7:05 PM, Simon Riggs wrote:
> I've added a recheck in ProcessTwoPhaseBuffer() after we acquire the lock.
>
> If its worth acquiring the lock its worth checking we don't have a race.
I see. No objections to that.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-
On Tue, Apr 18, 2017 at 4:15 PM, Andres Freund wrote:
> Hi,
>
> On 2017-04-18 16:07:38 +0900, Michael Paquier wrote:
>> Some of you may have noticed that hamster is heavily red on the
>> buildfarm. I have done a bit of investigation, and I am able to
>> reproduc
Hi all,
Some of you may have noticed that hamster is heavily red on the
buildfarm. I have done a bit of investigation, and I am able to
reproduce the failure manually. But actually after looking at the logs
the error has obviously showed up:
2017-04-16 05:07:19.650 JST [18282] LOG: database syste
On Tue, Apr 18, 2017 at 12:33 AM, Jeff Janes wrote:
> On Sun, Apr 16, 2017 at 6:59 PM, Michael Paquier
> wrote:
>>
>>
>>
>> Jeff, does this patch make the situation better? The fix is rather
>> simple as it just makes sure that the next XID never gets
On Sun, Apr 16, 2017 at 6:02 PM, Simon Riggs wrote:
> On 15 April 2017 at 21:30, Jeff Janes wrote:
>> On Fri, Apr 14, 2017 at 9:33 PM, Pavan Deolasee
>> wrote:
>>
>>>
>>> Since all those offsets fall on a page boundary, my guess is that we're
>>> somehow failing to handle a new page correctly.
>
On Fri, Apr 14, 2017 at 9:19 PM, Petr Jelinek
wrote:
> I am not quite sure adding more GUCs is all that great option. When
> writing the patches I was wondering if we should perhaps rename the
> wal_receiver_timeout and wal_retrieve_retry_interval to something that
> makes more sense for both phys
On Fri, Apr 14, 2017 at 8:28 PM, Craig Ringer
wrote:
> There's no point advertising scram-512 if only -256 can work for 'bob'
> because that's what we have in pg_authid.
The possibility to have multiple verifiers has other benefits than
that, password rolling being one. We may want to revisit tha
On Fri, Apr 14, 2017 at 8:03 PM, Stephen Frost wrote:
> Some of those were specifically left around to test those code paths.
> I'm not sure if these were those or not though, Andrew was the one who
> reviewed the various pg_dumpall calls to add --no-sync in places.
Well, Andrew has pushed the pa
On Thu, Apr 6, 2017 at 7:48 AM, Michael Paquier
wrote:
> On Wed, Apr 5, 2017 at 10:24 PM, Stephen Frost wrote:
>> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>>> 1) Initialize the old cluster and start it.
>>> 2) create a bunch of databases with full range
On Fri, Apr 14, 2017 at 1:37 AM, Heikki Linnakangas wrote:
> On 04/13/2017 05:53 AM, Michael Paquier wrote:
>> +* Parse the list of SASL authentication mechanisms in the
>> +* AuthenticationSASL message, and select the best mechanism that we
>> +* support. (
On Thu, Apr 13, 2017 at 7:40 PM, Vitaly Burovoy
wrote:
> On 4/6/17, Vitaly Burovoy wrote:
>> On 4/6/17, Peter Eisentraut wrote:
>>> As I tried to mention earlier, it is very difficult to implement the IF
>>> NOT EXISTS behavior here, because we need to run the commands the create
>>> the sequenc
On Fri, Apr 14, 2017 at 2:47 AM, Fujii Masao wrote:
> I'm thinking that it's less confusing to report always 0 as the priority of
> async standby whatever the setting of synchronous_standby_names is.
> Thought?
Or we could have priority being reported to NULL for async standbys as
well, the prior
On Fri, Apr 14, 2017 at 3:03 AM, Fujii Masao wrote:
> On Thu, Apr 13, 2017 at 12:36 PM, Michael Paquier
> wrote:
>> On Thu, Apr 13, 2017 at 12:28 PM, Fujii Masao wrote:
>>> On Thu, Apr 13, 2017 at 5:25 AM, Peter Eisentraut
>>> wrote:
>>>> On 4/12/17 0
On Fri, Apr 14, 2017 at 6:32 AM, Pierre Ducroquet wrote:
> Yesterday while doing a few pg_basebackup, I realized that the integer
> parameters were not properly checked against invalid input.
> It is not a critical issue, but this could be misleading for an user who
> writes -z max or -s 0.5…
> I'
On Tue, Apr 11, 2017 at 5:38 PM, Kyotaro HORIGUCHI
wrote:
> Sorry, what I have just sent was broken.
You can use PROVE_TESTS when running make check to select a subset of
tests you want to run. I use that all the time when working on patches
dedicated to certain code paths.
>> - Relation has new
On Thu, Apr 13, 2017 at 12:28 PM, Fujii Masao wrote:
> On Thu, Apr 13, 2017 at 5:25 AM, Peter Eisentraut
> wrote:
>> On 4/12/17 09:55, Fujii Masao wrote:
>>> To fix this issue, we should terminate walsender for logical replication
>>> before shutdown checkpoint starts. Of course walsender for phy
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
wrote:
> By looking at the them, and unless I'm missing something, I don't see
> how the extra information for the future implementation of channel binding
> would be added (without changing the protocol). Relevant part is:
>
> The mess
On Thu, Apr 13, 2017 at 2:34 AM, Heikki Linnakangas wrote:
> On 04/11/2017 02:32 PM, Álvaro Hernández Tortosa wrote:
>>
>> So I still see your proposal more awkward and less clear, mixing
>> things that are separate. But again, your choice :)
>
>
> So, here's my more full-fledged proposal.
>
On Thu, Apr 13, 2017 at 3:21 AM, Robert Haas wrote:
> On Wed, Apr 12, 2017 at 2:09 PM, Heikki Linnakangas wrote:
>> Yes, we need to nail down the protocol and \password before beta. I am
>> working on them now.
>
> Good to hear.
FWIW, there are patches for each issue.
--
Michael
--
Sent via
On Wed, Apr 12, 2017 at 9:12 AM, Craig Ringer
wrote:
> Well, you can get a lot of information on timings in crake's latest
> builds for example, or nightjar's.
>
> Here's an interesting fact: almost all the time taken up in the scripts
> test set seems to be consumed in running initdb over and ove
On Wed, Apr 12, 2017 at 3:40 AM, Tom Lane wrote:
> I notice looking at pg_stat_activity that the logical replication launcher
> sets its application_name to "logical replication launcher". This seems
> inconsistent (no other standard background process sets application_name),
> redundant with oth
On Tue, Apr 11, 2017 at 9:41 PM, Magnus Hagander wrote:
> This bug seems to have snuck in there with the introduction of walmethods.
> AFAICT we are testing the result of sync() backwards, so whenever a partial
> segment exists for pg_receivewal, it will fail. It will then unlink the
> file, so wh
On Tue, Apr 11, 2017 at 9:53 PM, Álvaro Hernández Tortosa
wrote:
> I know this is a lost battle. But please bear with me for a minute.
I admire your courage.
> But just a bit more is needed to make it really a big announcement and
> provide real value to (I guess, mostly but very interes
On Tue, Apr 11, 2017 at 12:14 AM, Peter Eisentraut
wrote:
> Why $subject?
>
> Does it just need to be wired into the makefiles a bit better?
Looks like an oversight to me. I would suggest changing the Makefile like that:
diff --git a/contrib/bloom/Makefile b/contrib/bloom/Makefile
index 13bd397b7
On Mon, Apr 10, 2017 at 5:11 PM, Heikki Linnakangas wrote:
> Here are some characters that seem plausible to be misinterpreted and
> ignored by SASLprep:
> EUC-JP and EUC-JISX0213:
>
> U+00AD (C2 AD): 足 (meaning "foot", per Unihan database)
> U+FE00-FE0F (EF B8 8X): 鏝 (meaning "trowel", per Unihan
On Tue, Apr 11, 2017 at 4:41 AM, Heikki Linnakangas wrote:
> On 04/10/2017 09:33 PM, Álvaro Hernández Tortosa wrote:
>> - If the username used is the one sent in the startup message, rather
>> than leaving it empty in the client-first-message, I would force it to
>> be the same as the used in the
On Tue, Apr 11, 2017 at 1:45 AM, Tom Lane wrote:
> Magnus Hagander writes:
> Are these votes for getting rid of both win32.mak and bcc32.mak?
>
>> PFA a patch that does this. Did I miss something? :)
>
> Perhaps we should get rid of the WIN32_ONLY_COMPILER symbol altogether;
> given this patc
On Mon, Apr 10, 2017 at 5:47 PM, Magnus Hagander wrote:
> Based on that we seem to agree here, should we add this as an open item?
> Clearly if we want to change this, we should do so before 10.
This really is a new feature, so as the focus is to stabilize things I
think that we should not make t
On Tue, Apr 11, 2017 at 4:02 AM, Robert Haas wrote:
> On Mon, Apr 10, 2017 at 2:09 PM, Tom Lane wrote:
>> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>>> Why bother with the 'rte' variable at all if it's only used for the
>>> Assert()ing the rtekind?
>>
>> That was propo
On Mon, Apr 10, 2017 at 9:05 PM, Tom Lane wrote:
> I wonder if we shouldn't just do
>
> RangeTblEntry *rte PG_USED_FOR_ASSERTS_ONLY;
> ListCell *lc;
>
> /* Should only be applied to base relations that are subqueries */
> Assert(rel->relid > 0);
> -#ifdef USE_ASSE
On Mon, Apr 10, 2017 at 8:35 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> Are these votes for getting rid of both win32.mak and bcc32.mak?
>
> I'm for it.
+1.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
On Mon, Apr 10, 2017 at 12:53 PM, Noah Misch wrote:
> On Wed, Apr 05, 2017 at 08:11:25PM +0300, Heikki Linnakangas wrote:
>> >Heikki, are you going to do something about these? We're running out of
>> >time.
>>
>> Sorry I've been procrastinating. I'm on it now. (We need to do something
>> about
On Mon, Apr 10, 2017 at 1:01 PM, Noah Misch wrote:
> This PostgreSQL 10 open item is past due for your status update. Kindly send
> a status update within 24 hours, and include a date for your subsequent status
> update. Refer to the policy on open item ownership:
> https://www.postgresql.org/me
On Sat, Apr 8, 2017 at 9:28 AM, Robert Haas wrote:
> On Fri, Apr 7, 2017 at 6:32 PM, Michael Paquier
> wrote:
>> On Sat, Apr 8, 2017 at 1:59 AM, Robert Haas wrote:
>>> On Fri, Apr 7, 2017 at 3:59 AM, Heikki Linnakangas wrote:
>>>> I think the "SCRAM"
On Mon, Apr 10, 2017 at 11:41 AM, Noah Misch wrote:
> On Thu, Apr 06, 2017 at 02:21:29AM +0900, Fujii Masao wrote:
>> Both launcher and worker don't handle SIGHUP signal and cannot
>> reload the configuration. I think that this is a bug. Will add this as
>> an open item barring objection.
>
> [Act
On Sat, Apr 8, 2017 at 11:27 PM, Andres Freund wrote:
> Thanks for your work on managing the fest!
+1. Great work!
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Apr 8, 2017 at 7:33 PM, Heikki Linnakangas wrote:
> Hmm. It looks like none of the buildfarm members are running the
> authentication tests. Nor recovery tests, nor subscription tests. We're
> missing a trick here, at least some of the buildfarm members really ought to
> run "make check-wo
On Sat, Apr 8, 2017 at 1:59 AM, Robert Haas wrote:
> On Fri, Apr 7, 2017 at 3:59 AM, Heikki Linnakangas wrote:
>> I think the "SCRAM" part is more important than "SHA-256", so -1 on that.
>
> I agree. The point here isn't that we're using a better hashing
> method, even if a lot of people *think
On Fri, Apr 7, 2017 at 8:58 PM, Heikki Linnakangas wrote:
> On 04/07/2017 05:30 AM, Michael Paquier wrote:
>> I am really wondering if this should not reflect the real range
>> reported by the RFC. I understand that you have grouped things to save
>> a couple of bytes, but th
On Fri, Apr 7, 2017 at 12:38 AM, Michael Paquier
wrote:
> On Tue, Apr 4, 2017 at 9:42 PM, Michael Paquier
> wrote:
>> On Wed, Apr 5, 2017 at 2:54 AM, Tom Lane wrote:
>>> (I'm personally not that much in love with PG_USED_FOR_ASSERTS_ONLY,
>>> because it tends
On Tue, Apr 4, 2017 at 9:42 PM, Michael Paquier
wrote:
> On Wed, Apr 5, 2017 at 2:54 AM, Tom Lane wrote:
>> (I'm personally not that much in love with PG_USED_FOR_ASSERTS_ONLY,
>> because it tends to confuse pgindent.)
>
> I would be incline to just do that, any oth
On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane wrote:
> Still, it's not very clear why we need to cater for building just libpq
> rather than the whole distribution, and a user of win32.mak presumably
> has the option to do the latter. The core argument for bcc32.mak,
> I think, is that we never did su
Hi all,
I am getting the following warning with MSVC 2010 for what is a result
of 3217327 (identity columns):
c:\users\michael\git\postgres\src\backend\catalog\pg_depend.c(615):
warning C4715: 'getOwnedSequence' : not all control paths return a
value [C:\Users\michael\git\postgres\postgres.vcxpr
Hi all,
While looking at some SCRAM stuff, I have bumped into bcc32.mak and
win32.mak in src/interfaces/libpq. To put it short: those files are
not up to date. The code of SCRAM is in the tree for a bit of time
now, and should have updated those files to list and clean up objects,
but nobody has r
On Fri, Apr 7, 2017 at 2:47 AM, Heikki Linnakangas wrote:
> On 04/06/2017 08:42 PM, Heikki Linnakangas wrote:
>>> There is for example this portion in the new tables:
>>> +static const Codepoint prohibited_output_chars[] =
>>> +{
>>> + 0xD800, 0xF8FF, /* C.3, C.5 */
>>>
>>>-
701 - 800 of 5507 matches
Mail list logo