2016-11-10 13:54 GMT+07:00 Michael Paquier :
> On Thu, Nov 10, 2016 at 7:37 AM, Tom Lane wrote:
> > Given that nobody actually cares what that sort order is, I think that
> > having to jump through hoops in pg_upgrade in order to fix it is not a
> > great tradeoff. I suggest changing the documen
On 2016/11/10 5:17, Tom Lane wrote:
Etsuro Fujita writes:
[ foreign_plan_cache_inval_v6.patch ]
I looked through this a bit.
Thank you for working on this!
A point that doesn't seem to have been
discussed anywhere in the thread is why foreign tables should deserve
exact tracking of depen
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Mithun Cy
> Among the remaining things I have worked on failover to new master idea.
> Below patch implement that idea. This is taken from Victors patch but
> rewritten by me to do some cleanup. As i
On Thu, Nov 10, 2016 at 4:23 PM, konstantin knizhnik
wrote:
> No, it is latest sources from Postgres repository.
> Please notice that you should create new database and tablespace to reproduce
> this issue.
> So actually the whole sequence is
>
> mkdir fs
> initdb -D pgsql
> pg_ctl -D pgsql -l lo
On Nov 10, 2016, at 10:17 AM, Michael Paquier wrote:
>
> Hm.. I cannot reproduce what you see on Linux or macos. Perhaps you
> have locally a standby pointing as well to this tablespace?
No, it is latest sources from Postgres repository.
Please notice that you should create new database and tab
On Thu, Nov 10, 2016 at 3:29 AM, Robert Haas wrote:
> On Wed, Nov 9, 2016 at 11:56 AM, Konstantin Knizhnik
> wrote:
>> Now simulate server crash using using "pkill -9 postgres".
>>
>> knizhnik@knizhnik:~/dtm-data$ rm -f logfile ; pg_ctl -D pgsql.master -l
>> logfile start
>> pg_ctl: another serve
On Thu, Nov 10, 2016 at 7:37 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Thu, Nov 10, 2016 at 3:27 AM, Robert Haas wrote:
>>> https://www.postgresql.org/docs/current/static/datatype-json.html
>
>> Indeed, I missed that. So that's broken...
>
> Given that nobody actually cares what that s
On Fri, Nov 4, 2016 at 11:09 AM, Haribabu Kommi
wrote:
>
>
> On Tue, Oct 25, 2016 at 11:40 PM, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>
>> On 10/25/16 1:38 AM, Haribabu Kommi wrote:
>> > Here I attached the first version of patch that supports both EUI-48 and
>> > EUI-64 ty
On Wed, Nov 9, 2016 at 7:46 PM, Andreas Karlsson wrote:
> Those tests fail due to that listen_addresses cannot be changed on reload so
> none of the test cases can even connect to the database. When I hacked
> ServerSetup.pm to set the correct listen_address before starting all tests
> pass.
Hm..
On Mon, Nov 7, 2016 at 3:36 PM, Michael Paquier
wrote:
> On Mon, Nov 7, 2016 at 12:36 PM, Haribabu Kommi
> wrote:
> > The added regression test fails for the cases where the server is loaded
> > with
> > different pg_hba.conf rules during installcheck verification. Updated
> patch
> > is
> > att
On 11/10/2016 05:29 AM, Peter Eisentraut wrote:
On 11/8/16 6:43 PM, Andreas Karlsson wrote:
- A worry is that it might get a bit confusing to have both the future
catalog pg_sequence and the view pg_sequences.
We already have this in other cases: pg_index/pg_indexes,
pg_user_mapping/pg_user_ma
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> OK. I agree that's a problem. However, your patch adds zero new comment
> text while removing some existing comments, so I can't easily tell how it
> solves that problem or whether it
On Wed, Nov 9, 2016 at 9:33 PM, Kuntal Ghosh wrote:
> In brin_doupdate(line 290), REGBUF_STANDARD is used to register
> revmap buffer reference in WAL record. But, revmap buffer page doesn't
> have a standard page layout and it doesn't update pd_upper and
> pd_lower as well.
>
> Either we should r
On Wed, Nov 9, 2016 at 11:32 PM, Kuntal Ghosh
wrote:
> On Fri, Nov 4, 2016 at 1:32 PM, Michael Paquier
> wrote:
>> Thank you for the new patch. This will be hopefully the last round of
>> reviews, we are getting close to something that has an acceptable
>> shape.
>
> Thanks a lot for reviewing th
On 11/8/16 6:43 PM, Andreas Karlsson wrote:
> - A worry is that it might get a bit confusing to have both the future
> catalog pg_sequence and the view pg_sequences.
We already have this in other cases: pg_index/pg_indexes,
pg_user_mapping/pg_user_mappings. It's an established naming system by n
On Wed, Nov 9, 2016 at 10:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Nov 9, 2016 at 4:51 PM, Tom Lane wrote:
>>> Perhaps the "logpath" buffer that the filename is constructed in
>>> needs to be made bigger. 64 bytes was obviously enough with the
>>> old pattern, but it's not with t
On Thu, Nov 10, 2016 at 2:57 AM, Robert Haas wrote:
>
> Some more review:
>
> The API contract of _hash_finish_split seems a bit unfortunate. The
> caller is supposed to have obtained a cleanup lock on both the old and
> new buffers, but the first thing it does is walk the entire new bucket
> ch
On Wed, Nov 9, 2016 at 6:57 PM, Robert Haas wrote:
> I guess that's possible, but the problem with polyphase merge is that
> the increased I/O becomes a pretty significant cost in a hurry.
Not if you have a huge RAID array. :-)
Obviously I'm not seriously suggesting that we revise the cap from 5
On Thu, Nov 10, 2016 at 12:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Nov 9, 2016 at 4:51 PM, Tom Lane wrote:
>>> Perhaps the "logpath" buffer that the filename is constructed in
>>> needs to be made bigger. 64 bytes was obviously enough with the
>>> old pattern, but it's not with
Robert Haas writes:
> On Wed, Nov 9, 2016 at 4:51 PM, Tom Lane wrote:
>> Perhaps the "logpath" buffer that the filename is constructed in
>> needs to be made bigger. 64 bytes was obviously enough with the
>> old pattern, but it's not with the new.
> Oops, yes, that seems like a good idea. How
On 2016/11/10 2:00, Robert Haas wrote:
> In this latest patch set:
>
> src/backend/parser/parse_utilcmd.c:3194: indent with spaces.
> +*rdatum;
This one I will fix.
>
> With all patches applied, "make check" fails with a bunch of diffs
> that look like this:
On Wed, Nov 9, 2016 at 7:54 PM, Peter Geoghegan wrote:
>> Now, on the other hand, as far as I can see, the actual amount of
>> evidence that 0001 is a good idea which has been presented in this
>> forum is pretty near zero. You've argued for it on theoretical
>> grounds several times, but theoret
On Wed, Nov 9, 2016 at 4:54 PM, Peter Geoghegan wrote:
> It's more complicated than that. As I said, I think that Knuth
> basically had it right with his sweet spot of 7. I think that commit
> df700e6b40195d28dc764e0c694ac8cef90d4638 was effective in large part
> because a one-pass merge avoided c
On Wed, Nov 9, 2016 at 4:01 PM, Robert Haas wrote:
> I gather that 0001, which puts a cap on the number of tapes, is not
> actually related to the subject of this thread; it's an independent
> change that you think is a good idea. I reviewed the previous
> discussion on this topic upthread, betwe
On 11/8/16 8:33 AM, Tom Lane wrote:
As things stand in HEAD, the behavior is about the same, but the error
messages are not --- in one case they mention triggers and of course the
other doesn't. There are a couple of other minor things in the way of
unifying the two hunks of code, so I concluded
On 8 Nov. 2016 15:11, "Craig Ringer" wrote:
>
>
>
> On 7 November 2016 at 05:08, Stefan Scheid wrote:
>>
>> Hi all,
>>
>> are there plans to introduce temporal tables?
>
> I don't know of anybody working on them, but someone else may. Try
searching the list archives.
I should've mentioned that o
On 10 November 2016 at 01:55, Robert Haas wrote:
> On Wed, Nov 9, 2016 at 12:17 PM, Tom Lane wrote:
>> The system will let you set the "user_catalog_table" reloption to "true"
>> on a materialized view. Is this sensible, or is it a bug caused by the
>> fact that reloptions.c fails to distinguish
On 10 November 2016 at 07:18, Clifford Hammerschmidt
wrote:
>
> On Tue, Nov 8, 2016 at 2:58 PM, Craig Ringer
> wrote:
>>
>> 2ndQuadrant/bdr
>
>
> That is similar. I'm not clear on the usage of OID for sequence
> (`DirectFunctionCall1(nextval_oid, seqoid)`) ... does that imply a lock
> around a se
On 10 November 2016 at 07:18, Clifford Hammerschmidt
wrote:
>
> On Tue, Nov 8, 2016 at 2:58 PM, Craig Ringer
> wrote:
>>
>> 2ndQuadrant/bdr
>
>
> That is similar. I'm not clear on the usage of OID for sequence
> (`DirectFunctionCall1(nextval_oid, seqoid)`) ... does that imply a lock
> around a se
> On Tue, Nov 8, 2016 at 6:54 AM, Jeevan Chalke
> wrote:
> > 1. ps_numTuples is declared as long, however offset and count members in
> > LimitState struct and bound member in SortState struct is int64. However
> > long on 32 bit machine may be 32 bits and thus I think tuples_needed which
> > is
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: Thursday, November 10, 2016 3:08 AM
> To: Kaigai Kouhei(海外 浩平)
> Cc: pgsql-hackers@postgresql.org; Jeevan Chalke; Etsuro Fujita; Andres Freund
> Sub
On Wed, Nov 9, 2016 at 4:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> pgbench: Allow the transaction log file prefix to be changed.
>
> Perhaps the "logpath" buffer that the filename is constructed in
> needs to be made bigger. 64 bytes was obviously enough with the
> old pattern, but it's no
On Mon, Nov 7, 2016 at 11:28 PM, Peter Geoghegan wrote:
> I attach V5.
I gather that 0001, which puts a cap on the number of tapes, is not
actually related to the subject of this thread; it's an independent
change that you think is a good idea. I reviewed the previous
discussion on this topic up
On Tue, Nov 8, 2016 at 2:58 PM, Craig Ringer
wrote:
> 2ndQuadrant/bdr
That is similar. I'm not clear on the usage of OID for sequence (`
DirectFunctionCall1(nextval_oid, seqoid)`) ... does that imply a lock
around a sequence generation? also different is that your sequence doesn't
reset on the
Michael Paquier writes:
> On Thu, Nov 10, 2016 at 3:27 AM, Robert Haas wrote:
>> https://www.postgresql.org/docs/current/static/datatype-json.html
> Indeed, I missed that. So that's broken...
Given that nobody actually cares what that sort order is, I think that
having to jump through hoops in
On Thu, Nov 10, 2016 at 3:27 AM, Robert Haas wrote:
> On Tue, Nov 8, 2016 at 9:49 PM, Michael Paquier
> wrote:
>> On Wed, Nov 9, 2016 at 8:31 AM, Nikita Glukhov
>> wrote:
>>> Hi hackers.
>>>
>>> While working on jsonbstatistics, I found the following bug:
>>> an empty jsonb array is considered
I am looking for ways to ensure referential integrity on large objects.
Something like having a column myoid in a table that holds an oid of a large
object, and which throws an error when the referenced large object should be
unlinked. Like "myoid references pg_largeobject(loid)", which does not
Pavel Stehule writes:
> [ psql-setfileref-2016-10-11.patch ]
I haven't been paying any attention to this thread, but I got around to
looking at it finally. I follow the idea of wanting to be able to shove
the contents of a file into a query literal, but there isn't much else
that I like about th
On Wed, Nov 9, 2016 at 2:54 PM, Corey Huinker wrote:
> 3. The operation is judged to have succeeded if at least one permission is
> granted, or NO grants failed (i.e. there was nothing to grant).
Allow me to be skeptical. If a user types INSERT INTO blah VALUES
(...), (...), (...) should we chan
On Tue, Nov 8, 2016 at 4:04 AM, Fabien COELHO wrote:
>
> [ ... v4 ]
>
>> I checked. It works as expected. I have no more comments.
>> If its okay with Fabien, we can mark it ready for committer.
>
> Patch applies, compiles (including the documentation), make check ok and
> features works for me. C
On Wed, Nov 9, 2016 at 12:11 PM, Robert Haas wrote:
> On Wed, Nov 9, 2016 at 11:41 AM, Amit Kapila wrote:
>> On Wed, Nov 9, 2016 at 9:10 PM, Robert Haas wrote:
>>> On Wed, Nov 9, 2016 at 9:04 AM, Amit Kapila wrote:
>>> I think we can give a brief explanation right in the code comment. I
>>> re
Etsuro Fujita writes:
> [ foreign_plan_cache_inval_v6.patch ]
I looked through this a bit. A point that doesn't seem to have been
discussed anywhere in the thread is why foreign tables should deserve
exact tracking of dependencies, when we have not bothered with that
for most other object types.
>
> > SET relacl = ( SELECT relacl FROM pg_class
> >WHERE oid = 'foo'::regclass)
> > WHERE oid = 'dummy'::regclass;
>
> Yikes, let's not suggest folks go updating catalog tables, ever, please.
> :)
>
Glad you find that as icky as I do.
> Should we have a way for users to
Robert Haas writes:
> On Tue, Nov 8, 2016 at 9:48 AM, Stephen Frost wrote:
>> Second, as always, what's the syntax going to actually be? I don't
>> think GRANT SAME PERMISSIONS is going to work out too well in the
>> parser, and it seems a bit grotty to me anyway. I do think this should
>> be a
On Tue, Nov 8, 2016 at 9:49 PM, Michael Paquier
wrote:
> On Wed, Nov 9, 2016 at 8:31 AM, Nikita Glukhov
> wrote:
>> Hi hackers.
>>
>> While working on jsonbstatistics, I found the following bug:
>> an empty jsonb array is considered to be lesser than any scalar,
>> but it is expected that object
On Wed, Nov 9, 2016 at 11:56 AM, Konstantin Knizhnik
wrote:
> Now simulate server crash using using "pkill -9 postgres".
>
> knizhnik@knizhnik:~/dtm-data$ rm -f logfile ; pg_ctl -D pgsql.master -l
> logfile start
> pg_ctl: another server might be running; trying to start server anyway
> server sta
Robert Haas writes:
> On Wed, Nov 9, 2016 at 9:02 AM, Peter Eisentraut
> wrote:
>> On 11/7/16 1:13 AM, Haribabu Kommi wrote:
>>> Yes, I agree that default zone is the main use case of the original thread.
>>> From the RFC 4007, the default zone is used for the global addresses,
>>> This may be th
On 16 August 2016 at 09:06, Stephen Frost wrote:
> Greetings,
>
> * Venkata B Nagothi (nag1...@gmail.com) wrote:
>> The above said parameters can be configured to pause, shutdown or prevent
>> promotion only after reaching the recovery target point.
>> To clarify, I am referring to a scenario wher
On Tue, Nov 8, 2016 at 9:53 AM, Oleksandr Shulgin
wrote:
> On Mon, Nov 7, 2016 at 9:31 PM, Jim Nasby wrote:
>>
>> On 11/4/16 4:04 AM, Oleksandr Shulgin wrote:
>>>
>>> The psql process even exits with an error code 2, which might be not
>>> that expected. We could stop reading the file and reset
On Tue, Nov 8, 2016 at 9:48 AM, Stephen Frost wrote:
> Second, as always, what's the syntax going to actually be? I don't
> think GRANT SAME PERMISSIONS is going to work out too well in the
> parser, and it seems a bit grotty to me anyway. I do think this should
> be associated with GRANT rather
On Wed, Nov 9, 2016 at 12:54 PM, Markus Nullmeier
wrote:
> On 11/08/16 18:12, Robert Haas wrote:
>> On Tue, Nov 8, 2016 at 1:01 AM, Michael Paquier
>> wrote:
>>> On Tue, Nov 8, 2016 at 2:33 PM, Kuntal Ghosh
>>> wrote:
I've attached a patch to fix this.
>>> Good catch. Interesting copy-pas
On Wed, Nov 9, 2016 at 9:02 AM, Peter Eisentraut
wrote:
> On 11/7/16 1:13 AM, Haribabu Kommi wrote:
>> Yes, I agree that default zone is the main use case of the original thread.
>> From the RFC 4007, the default zone is used for the global addresses,
>> This may be the main use case with zone id.
On Tue, Nov 8, 2016 at 6:54 AM, Jeevan Chalke
wrote:
> 1. ps_numTuples is declared as long, however offset and count members in
> LimitState struct and bound member in SortState struct is int64. However
> long on 32 bit machine may be 32 bits and thus I think tuples_needed which
> is long may hav
On Mon, Oct 31, 2016 at 10:20 AM, Kouhei Kaigai wrote:
> As an example, I enhanced postgres_fdw to understand the ps_numTuples
> if it is set. If and when remote ORDER BY is pushed down, the latest
> code tries to sort the entire remote table because it does not know
> how many rows to be returned
On Wed, Nov 9, 2016 at 12:17 PM, Tom Lane wrote:
> The system will let you set the "user_catalog_table" reloption to "true"
> on a materialized view. Is this sensible, or is it a bug caused by the
> fact that reloptions.c fails to distinguish matviews from heaps at all?
>
> If it is sensible, the
On 11/08/16 18:12, Robert Haas wrote:
> On Tue, Nov 8, 2016 at 1:01 AM, Michael Paquier
> wrote:
>> On Tue, Nov 8, 2016 at 2:33 PM, Kuntal Ghosh
>> wrote:
>>> I've attached a patch to fix this.
>> Good catch. Interesting copy-pasto from 88e9823.
> Committed.
Hmm, somehow this fix (60379f66c8 f
The system will let you set the "user_catalog_table" reloption to "true"
on a materialized view. Is this sensible, or is it a bug caused by the
fact that reloptions.c fails to distinguish matviews from heaps at all?
If it is sensible, then I broke it in e3e66d8a9 ...
rega
On Wed, Nov 9, 2016 at 11:41 AM, Amit Kapila wrote:
> On Wed, Nov 9, 2016 at 9:10 PM, Robert Haas wrote:
>> On Wed, Nov 9, 2016 at 9:04 AM, Amit Kapila wrote:
>> I think we can give a brief explanation right in the code comment. I
>> referred to "decreasing the TIDs"; you are referring to "movi
On Wed, Nov 9, 2016 at 12:00 PM, Robert Haas wrote:
> In this latest patch set:
>
> src/backend/parser/parse_utilcmd.c:3194: indent with spaces.
> +*rdatum;
>
> With all patches applied, "make check" fails with a bunch of diffs
> that look like this:
>
> Check
Craig Ringer wrote:
So personally I think it'd be fine if a cmake build defaulted to
finding and using what it could, but offered a --minimal mode or
whatever that gets us just core postgres + whatever we enable
explicitly. But our current behaviour is OK too.
To me it's best way. But I'm not s
In this latest patch set:
src/backend/parser/parse_utilcmd.c:3194: indent with spaces.
+*rdatum;
With all patches applied, "make check" fails with a bunch of diffs
that look like this:
Check constraints:
- "pt1chk2" CHECK (c2 <> ''::text)
"pt1chk3"
Hi, hackers
I wonder if such behavior can be considered as a bug:
knizhnik@knizhnik:~/dtm-data$ psql postgres
psql (10devel)
Type "help" for help.
postgres=# create tablespace fs location '/home/knizhnik/dtm-data/fs';
CREATE TABLESPACE
postgres=# set default_tablespace=fs;
SET
postgres=# create
On Wed, Nov 9, 2016 at 9:10 PM, Robert Haas wrote:
> On Wed, Nov 9, 2016 at 9:04 AM, Amit Kapila wrote:
>
> I think we can give a brief explanation right in the code comment. I
> referred to "decreasing the TIDs"; you are referring to "moving tuples
> around". But I think that moving the tuples
Amit Langote writes:
> On Wed, Nov 9, 2016 at 11:47 PM, Tom Lane wrote:
>> Hmm, that's from 2009. I thought I remembered something much more recent,
>> like last year or so.
> This perhaps:
> * Re: Bootstrap DATA is a pita *
> https://www.postgresql.org/message-id/flat/CAOjayEfKBL-_Q9m3Jsv6V-m
While testing bitmap performance, I have observed that some of the
TPCH queries taking huge time in BitmapIndexScan node, when there are
lossy pages.
I suspected 75ae538bc3168bf44475240d4e0487ee2f3bb376 commit, because
prior to that it used to take very less time. So I tested by reverting
suspecte
On Wed, Nov 9, 2016 at 9:04 AM, Amit Kapila wrote:
> + * This function expects that the caller has acquired a cleanup lock on the
> + * primary bucket page, and will with a write lock again held on the primary
> + * bucket page. The lock won't necessarily be held continuously, though,
> + * becau
On Wed, Nov 9, 2016 at 11:47 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Wed, Nov 9, 2016 at 1:44 PM, Tom Lane wrote:
>>> I don't think we need "named constants", especially not
>>> manually-maintained ones. The thing that would help in pg_proc.h is for
>>> numeric type OIDs to be repla
On Thu, Nov 3, 2016 at 7:16 PM, Robert Haas wrote:
> Great, committed. There's still potentially more work to be done
> here, because my patch omits some features that were present in
> Victor's original submission, like setting the failover timeout,
> optionally randomizing the order of the host
Michael Paquier writes:
> On Wed, Nov 9, 2016 at 1:44 PM, Tom Lane wrote:
>> I don't think we need "named constants", especially not
>> manually-maintained ones. The thing that would help in pg_proc.h is for
>> numeric type OIDs to be replaced by type names. We talked awhile back
>> about intro
On Fri, Nov 4, 2016 at 1:32 PM, Michael Paquier
wrote:
> Thank you for the new patch. This will be hopefully the last round of
> reviews, we are getting close to something that has an acceptable
> shape.
Thanks a lot for reviewing the patch. Based on your review, I've attached the
updated patch al
On Tue, Nov 8, 2016 at 10:56 PM, Jeff Janes wrote:
> On Sat, Sep 24, 2016 at 10:00 PM, Amit Kapila
> wrote:
>>
>> On Fri, Sep 23, 2016 at 5:34 PM, Amit Kapila
>> wrote:
>> >
>> > I think here I am slightly wrong. For the full page writes, it do use
>> > RBM_ZERO_AND_LOCK mode to read the page a
On Wed, Nov 9, 2016 at 1:23 AM, Robert Haas wrote:
> On Mon, Nov 7, 2016 at 9:51 PM, Amit Kapila wrote:
>> [ new patches ]
>
> Attached is yet another incremental patch with some suggested changes.
>
> + * This expects that the caller has acquired a cleanup lock on the target
> + * bucket (primar
On 11/7/16 1:13 AM, Haribabu Kommi wrote:
> Yes, I agree that default zone is the main use case of the original thread.
> From the RFC 4007, the default zone is used for the global addresses,
> This may be the main use case with zone id. How about currently just
> ignoring it and store the actual I
Hi all,
In brin_doupdate(line 290), REGBUF_STANDARD is used to register
revmap buffer reference in WAL record. But, revmap buffer page doesn't
have a standard page layout and it doesn't update pd_upper and
pd_lower as well.
Either we should register revmapbuf as following:
XLogRegisterBuffer(1, r
On Wed, Nov 9, 2016 at 3:28 PM, Fabien COELHO wrote:
>
> +1. My vote is for backslash continuations.
>>
>
> I'm fine with that!
>
> --
> Fabien.
>
Looks good to me also.
--
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/
On 11/09/2016 06:54 AM, Michael Paquier wrote:
It seems to me that this patch is missing something... To begin with,
src/test/ssl/ServerSetup.pm should be patched so as the new SSL
configuration is reloaded after pg_ctl reload, and not after an
instance restart. That's straight-forward:
--- a/src
+1. My vote is for backslash continuations.
I'm fine with that!
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
So this is really not open for negotiation. As Peter said upthread,
what we are looking for in a CMake reimplementation is that it behaves
exactly like the Autoconf version does. To the extent that you are unable
or unwilling to duplicate that behavior, you increase the odds tha
Hello, thank you for polishing this.
At Wed, 9 Nov 2016 02:19:01 +0100, Daniel Gustafsson wrote in
<80f34f25-bf6d-4bcd-9c38-42ed10d3f...@yesql.se>
> > On 08 Nov 2016, at 17:37, Peter Eisentraut
> > wrote:
> >
> > On 10/31/16 12:11 PM, Daniel Gustafsson wrote:
> >> I took a small stab at doing
79 matches
Mail list logo
