On Thu, Sep 06, 2018 at 06:26:51AM +0100, Andrew Gierth wrote:
> What version of GNU Make is on there, do you know? Tom? I don't see it
> mentioned in the output anywhere.
I don't know it. What I can see is that the use of "else ifdef" is
forbidden. You could bypass the problem with more
Hello.
At Wed, 05 Sep 2018 20:02:04 +0900, Etsuro Fujita
wrote in <5b8fb7ac.5020...@lab.ntt.co.jp>
> (2018/08/30 21:58), Etsuro Fujita wrote:
> > (2018/08/30 20:37), Kyotaro HORIGUCHI wrote:
> >> At Fri, 24 Aug 2018 21:45:35 +0900, Etsuro
> >> Fujita wrote
> >>
> "Michael" == Michael Paquier writes:
Michael> prairiedog is unhappy with this commit:
What version of GNU Make is on there, do you know? Tom? I don't see it
mentioned in the output anywhere.
--
Andrew.
Hi Andrew,
On Wed, Sep 05, 2018 at 09:45:49PM +, Andrew Gierth wrote:
> Allow extensions to install built as well as unbuilt headers.
>
> Commit df163230b overlooked the case that an out-of-tree extension
> might need to build its header files (e.g. via ./configure). If it is
> also doing a
Hi,
On Wed, Sep 5, 2018 at 2:56 PM, Tom Lane wrote:
> Richard Guo writes:
> > In this patch, we are trying to do the similar deduction, from
> > non-equivalence
> > clauses, that is, A=B AND f(A) implies A=B AND f(A) and f(B), under some
> > restrictions on f.
>
> Uh, *what* restrictions on
On Wed, Sep 5, 2018 at 2:55 PM, Heikki Linnakangas wrote:
> On 05/09/18 09:34, Richard Guo wrote:
>
>> Hi,
>>
>> As we know, current planner will generate additional restriction clauses
>> from
>> equivalence clauses. This will generally lower the total cost because
>> some of
>> tuples may be
On Wed, Sep 05, 2018 at 11:55:39AM -0700, Andres Freund wrote:
> On 2018-08-22 06:20:21 +, Noah Misch wrote:
> > I see jit slows the regression tests considerably:
>
> Is this with LLVM assertions enabled or not?
Without, I think. I configured them like this:
cmake -G Ninja
On Wed, Sep 05, 2018 at 01:05:42PM -0700, Michael Paquier wrote:
> As far as I can see, the proposal is not cold to death and could have a
> future, so I'll begin a new thread with a more complete patch.
Done. Let's move the discussion here then:
Hi all,
On a recent thread of pgsql-committers has been discussed the fact that
we lacked a bit of infrastructure to allow extensions to control
isolation and TAP tests:
https://www.postgresql.org/message-id/20180905174527.ga2...@paquier.xyz
Attached is a patch which is the result of the
-Original Message-
From: Yotsunaga, Naoki [mailto:yotsunaga.na...@jp.fujitsu.com]
Sent: Tuesday, June 26, 2018 10:18 AM
To: Postgres hackers
Subject: automatic restore point
>Hi, I attached a patch to output the LSN before execution to the server log
>>when executing a specific command
On 2018-09-05 19:11:56 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-09-05 18:45:52 -0400, Tom Lane wrote:
> >> The snapshot has little to do with the query plan, usually. It's about
> >> what view of the database the executed query will see, and particularly
> >> about what view
> > Queries stop getting re-optimized after 5 times, unless better plans are to
> > be had. In the absence of schema changes or changing search path why is
> > the snapshot needed?
>
> The snapshot has little to do with the query plan, usually. It's about
> what view of the database the
Andres Freund writes:
> On 2018-09-05 18:45:52 -0400, Tom Lane wrote:
>> The snapshot has little to do with the query plan, usually. It's about
>> what view of the database the executed query will see, and particularly
>> about what view the parameter input functions will see, if they look.
>
Chapman Flack writes:
> On 09/05/18 18:07, Tom Lane wrote:
>> * Replace SPI_tuptable et al with macros that access fields in the
>> current SPI stack level (similar to the way that, eg, errno works
>> on most modern platforms). This seems do-able, if a bit grotty.
> It would mean they'd have to
On 2018-09-05 18:45:52 -0400, Tom Lane wrote:
> Daniel Wood writes:
> >>> exec_bind_message()
> >>> PushActiveSnapshot(GetTransactionSnapshot());
> >>>
> >>> If there were no input functions, that needed this, nor reparsing or
> >>> reanalyzing needed, and we knew this up front, it'd be a huge
Daniel Wood writes:
>>> exec_bind_message()
>>> PushActiveSnapshot(GetTransactionSnapshot());
>>>
>>> If there were no input functions, that needed this, nor reparsing or
>>> reanalyzing needed, and we knew this up front, it'd be a huge win.
>> Unfortunately, that's not the case, so I think
On 09/05/18 18:07, Tom Lane wrote:
> * Replace SPI_tuptable et al with macros that access fields in the
> current SPI stack level (similar to the way that, eg, errno works
> on most modern platforms). This seems do-able, if a bit grotty.
It would mean they'd have to *be* in the stack frame,
[ redirecting to pgsql-hackers ]
I wrote:
> Gunnlaugur Thor Briem writes:
>> SET search_path = "$user"; SELECT public.unaccent('foo');
>> SET
>> ERROR: text search dictionary "unaccent" does not exist
> Meh. I think we need the attached, or something just about like it.
>
> It's barely
> > exec_bind_message()
> > PushActiveSnapshot(GetTransactionSnapshot());
>
> > If there were no input functions, that needed this, nor reparsing or
> > reanalyzing needed, and we knew this up front, it'd be a huge win.
>
> Unfortunately, that's not the case, so I think trying to get
Chapman Flack writes:
> In xml.c, query_to_xml_internal() contains a loop that refers
> to SPI_processed every iteration:
> for (i = 0; i < SPI_processed; i++)
> SPI_sql_row_to_xmlelement(i, result, tablename, nulls,
> tableforest, targetns, top_level);
>
When max_files_per_process=1201 or more server not start. I tested and
debugged this on Windows 7. On Windows 10 work all right.
I found this take place after call function count_usable_fds(int
max_to_probe, int *usable_fds, int *already_open)
Error occured on the first call selres =
On Wed, Sep 5, 2018 at 12:10 PM Christoph Berg wrote:
> > So, it's not ideal but perhaps worth considering on the grounds that
> > it's better than nothing?
>
> Ack.
Ok, here's a little patch like that.
postgres=# select collname, collcollate, collversion from pg_collation
where collname =
I encountered this in 9.5 and haven't yet written a reproducer
for 10 or 11, but the code in question looks the same in master.
In xml.c, query_to_xml_internal() contains a loop that refers
to SPI_processed every iteration:
for (i = 0; i < SPI_processed; i++)
SPI_sql_row_to_xmlelement(i,
On Wed, Sep 5, 2018 at 5:05 PM Alexander Korotkov
wrote:
> On Wed, Sep 5, 2018 at 2:39 PM Alexander Korotkov
> wrote:
> > On Wed, Sep 5, 2018 at 12:26 PM Alexander Korotkov
> > wrote:
> > > On Wed, Sep 5, 2018 at 1:45 AM R, Siva wrote:
> > > > On Tue, Sep 4, 2018 at 09:16 PM, Alexander
Hi,
On 2018-09-05 12:31:04 -0700, Daniel Wood wrote:
> NOTE:
>
> In GetSnapshotData because pgxact, is declared volatile, the compiler will
> not reduce the following two IF tests into a single test:
>
>
> if (pgxact->vacuumFlags & PROC_IN_LOGICAL_DECODING)
> continue;
>
>
>
On Wed, Sep 05, 2018 at 03:20:03PM -0300, Alvaro Herrera wrote:
> On 2018-Sep-05, Michael Paquier wrote:
> > It would be better to start a new thread rather than posting
> > a new patch, but I'd rather take the temperature first.
>
> Slightly feverish, it appears.
As far as I can see, the
I wrote:
> Andres Freund writes:
>> One concern I have with your approach is that it isn't particularly
>> bullet-proof for cases where the rebuild is triggered by something that
>> doesn't hold a conflicting lock.
> Wouldn't that be a bug in the something-else?
So where are we on this? Should
Daniel Wood writes:
> In particular:
> exec_bind_message()
> PushActiveSnapshot(GetTransactionSnapshot());
> If there were no input functions, that needed this, nor reparsing or
> reanalyzing needed, and we knew this up front, it'd be a huge win.
Unfortunately, that's not the case,
In particular:
exec_bind_message()
PushActiveSnapshot(GetTransactionSnapshot());
Suppressing this I've achieved over 1.9 M TXN's a second on select only pgbench
on a 48 core box. It is about 50% faster with this change. The cpu usage of
GetSnapshotData drops from about 22% to
Andrew Gierth writes:
> The problem is that if we're relying on -fexcess-precision=standard
> semantics in places besides infinity checks, then we won't get those
> semantics on clang/i386/no-sse2 since it has no comparable option. (What
> are we doing about compilers for x86-32 other than clang
> "Tom" == Tom Lane writes:
>> At the very minimum, I believe FreeBSD project policy would require
>> that the i386 packages for postgresql be built to run without SSE2.
Tom> Well, can we tell them they have to use gcc to compile, or will
Tom> that be against their policy too?
That's
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> If you wanted to argue that the set of people who still want to
> Tom> run PG on pre-SSE2 hardware is the empty set, that'd be an easier
> Tom> sell really.
> At the very minimum, I believe FreeBSD project policy would require that
>
> "Peter" == Peter Eisentraut writes:
> On 05/09/2018 18:42, Andres Freund wrote:
>> Realistically we're going to be running into old versions of clang
>> for a long time. And the importance of running i386 without SSE2
>> surely isn't increasing. So I don't really see an urgent need to
> "Tom" == Tom Lane writes:
Tom> If you wanted to argue that the set of people who still want to
Tom> run PG on pre-SSE2 hardware is the empty set, that'd be an easier
Tom> sell really.
At the very minimum, I believe FreeBSD project policy would require that
the i386 packages for
Hi,
On 2018-08-22 06:20:21 +, Noah Misch wrote:
> I see jit slows the regression tests considerably:
Is this with LLVM assertions enabled or not? The differences seem
bigger than what I'm observing, especially on the mips animal - which I
observe uses a separately installed LLVM build.
On
Hi,
On 2018-08-25 21:34:22 -0400, Robert Haas wrote:
> On Wed, Aug 22, 2018 at 6:43 PM, Andres Freund wrote:
> > Now you can say that'd be solved by bumping the cost up, sure. But
> > obviously the row / cost model is pretty much out of whack here, I don't
> > see how we can make reasonable
On Wed, Sep 05, 2018 at 12:16:00AM -0400, Tom Lane wrote:
> Amit Kapila writes:
>> Does anybody else have any idea on how can we write a test for
>> non-default block size or if we already have anything similar?
>
> Build with a non-default BLCKSZ and see if the regression tests pass.
> There's
On 2018-Sep-05, Michael Paquier wrote:
> On Wed, Sep 05, 2018 at 11:39:50AM -0300, Alvaro Herrera wrote:
> > Should this be used in src/test/modules/{brin,test_commit_ts} also?
>
> Hmm, I have not thought those two ones. commit_ts relies on REGRESS to
> be defined so as it does its cleanup.
On 2018-09-05 14:08:11 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-09-05 10:05:26 -0400, Tom Lane wrote:
> >> One thought is that maybe we should provide a way to override this,
> >> in case somebody really can't or doesn't want to use -msse2, and
> >> is willing to put up with
On Wed, Sep 5, 2018 at 10:13 AM Chris Travers wrote:
> On Wed, Sep 5, 2018 at 6:55 PM Andres Freund wrote:
>> > On Wed, Sep 5, 2018 at 6:40 PM Chris Travers
>> > wrote:
>> > >> Do you mean this loop in dsm_impl_posix_resize() is getting
>> > >> interrupted constantly and never completing?
>> >
On Wed, Sep 05, 2018 at 11:39:50AM -0300, Alvaro Herrera wrote:
> Should this be used in src/test/modules/{brin,test_commit_ts} also?
Hmm, I have not thought those two ones. commit_ts relies on REGRESS to
be defined so as it does its cleanup. brin is more interesting, it
directly quotes that it
On Wed, Sep 5, 2018 at 4:59 AM, R, Siva wrote:
> Hi,
>
> We recently encountered an issue where the opaque data flags on a gin data
> leaf page was corrupted while replaying a gin insert WAL record. Upon
> further examination of the redo code, we found a bug in ginRedoRecompress
> code, which
On Wed, Sep 5, 2018 at 6:55 PM Andres Freund wrote:
> Hi,
>
> On 2018-09-05 18:48:44 +0200, Chris Travers wrote:
> > Will submit a patch here shortly. Thanks! Should we do for master and
> > 10? Or 9.6 too?
>
> Please don't top-post on this list. This needs to be done in all
> branches where
Andres Freund writes:
> On 2018-09-05 18:55:34 +0200, Peter Eisentraut wrote:
>> Another option perhaps is to let this be and accept it as alternative
>> floating point behavior. We already have some of those.
> -many. We'd directly violate our own error rules.
I think that just from a
On 2018-09-05 18:55:34 +0200, Peter Eisentraut wrote:
> On 05/09/2018 18:42, Andres Freund wrote:
> > Realistically we're going to be running into old versions of clang for a
> > long time. And the importance of running i386 without SSE2 surely isn't
> > increasing. So I don't really see an
Hi,
On 2018-09-05 18:48:44 +0200, Chris Travers wrote:
> Will submit a patch here shortly. Thanks! Should we do for master and
> 10? Or 9.6 too?
Please don't top-post on this list. This needs to be done in all
branches where the posix_fallocate call is present.
> > Yep, Maybe we should
On 05/09/2018 18:42, Andres Freund wrote:
> Realistically we're going to be running into old versions of clang for a
> long time. And the importance of running i386 without SSE2 surely isn't
> increasing. So I don't really see an urgent need to do anything about
> it. And if it gets fixed, and
On Wed, Sep 5, 2018 at 9:49 AM Chris Travers wrote:
>
> Will submit a patch here shortly. Thanks! Should we do for master and 10?
> Or 9.6 too?
>
> On Wed, Sep 5, 2018 at 6:40 PM Chris Travers wrote:
>>
>> Yep, Maybe we should check for signals there.
Yeah, it seems reasonable to check for
Will submit a patch here shortly. Thanks! Should we do for master and
10? Or 9.6 too?
On Wed, Sep 5, 2018 at 6:40 PM Chris Travers
wrote:
> Yep, Maybe we should check for signals there.
>
> On Wed, Sep 5, 2018 at 5:27 PM Thomas Munro
> wrote:
>
>> On Wed, Sep 5, 2018 at 8:23 AM Chris
Hi,
On 2018-09-05 10:05:26 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 05/09/2018 02:51, Andres Freund wrote:
> >> My current proposal is thus to do add a check that does
> >> #if defined(__clang__) && defined(__i386__) && !defined(__SSE2_MATH__)
> >> something-that-fails
> >>
Yep, Maybe we should check for signals there.
On Wed, Sep 5, 2018 at 5:27 PM Thomas Munro
wrote:
> On Wed, Sep 5, 2018 at 8:23 AM Chris Travers
> wrote:
> > 1. The query is in a parallel index scan or similar
> > 2. A process is executing a parallel plan and allocating a significant
> chunk
On Wed, Sep 5, 2018 at 8:20 AM Thomas Munro
wrote:
> On Wed, Sep 5, 2018 at 3:35 AM Christoph Berg wrote:
> > int main (void) { puts (gnu_get_libc_version ()); return 0; }
> >
> > $ ./a.out
> > 2.27
>
> Hmm. I was looking for locale data version, not libc.so itself. I
> realise they come
On Wed, Sep 5, 2018, 6:35 PM Alexander Korotkov
wrote:
> On Wed, Sep 5, 2018 at 3:10 PM amul sul wrote:
> > On Wed, Sep 5, 2018 at 3:05 PM Alexander Korotkov
> > wrote:
> > > On Wed, Sep 5, 2018 at 1:22 AM David G. Johnston
> > > wrote:
> > > > From those results the question is how important
On 29/08/2018 11:37, Peter Eisentraut wrote:
> I have found some dying code in PL/Python.
>
> The simple slicing API (sq_slice, sq_ass_slice) has been deprecated
> since Python 2.0 and has been removed altogether in Python 3, so we can
> remove those functions from the PLyResult class. Instead,
Hi,
On 2018-09-05 13:06:06 +0300, Victor Spirin wrote:
> I have a bug in Windows 7 with max_files_per_process> 1200.
>
> Using dup (0) in the function count_usable_fds more than 1200 times (0 =
> stdin) causes further unpredictable errors with file operations.
Could you expand a bit on this?
Hi,
On 2018-09-05 01:05:54 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On September 4, 2018 9:11:25 PM PDT, Tom Lane wrote:
> >> I think that line of thought leads to an enormous increase in locking
> >> overhead, for which we'd get little if any gain in usability. So my
> >>
On 2018-Sep-05, Tom Lane wrote:
> Alvaro Herrera writes:
> > That said, I haven't heard of anyone using these functions in code yet,
> > so if we change it in 11 or 12 nobody is going to complain.
>
> ... and that's pretty much my feeling. It seems really unlikely that
> anyone's using
Alvaro Herrera writes:
> On 2018-Sep-03, Tom Lane wrote:
>> I do not think we can change the names of the output arguments;
>> it'd break existing queries. However, renaming input arguments
>> shouldn't affect anything. So I propose we make pg_get_object_address'
>> input arguments be named
On Wed, Sep 5, 2018 at 8:23 AM Chris Travers wrote:
> 1. The query is in a parallel index scan or similar
> 2. A process is executing a parallel plan and allocating a significant chunk
> of memory (2MB for example) in dynamic shared memory.
> 3. The startup process goes into a loop where it
Hi all;
For the last few months we have been facing a funny problem on a slave
where queries go to 100% cpu usage and never finish, causing the recovery
process to hang and the replica to fall behind, Over time we ruled out a
lot of causes and were banging our heads against this one. Today we
On Wed, Sep 5, 2018 at 3:35 AM Christoph Berg wrote:
> Re: Thomas Munro 2018-09-04
>
> > I was reminded about that by recent news
> > about an upcoming glibc/CLDR resync that is likely to affect
> > PostgreSQL users (though, I guess, probably only when they do a major
> > OS upgrade).
>
> Or
On 2018-Sep-04, Michael Paquier wrote:
> OK. I have dug into that, and finished with the attached. What do you
> think? One thing is that the definition of submake is moving out of
> REGRESS, and .PHONY gets defined.
Should this be used in src/test/modules/{brin,test_commit_ts} also?
Why do
On Wed, Sep 5, 2018 at 2:39 PM Alexander Korotkov
wrote:
> On Wed, Sep 5, 2018 at 12:26 PM Alexander Korotkov
> wrote:
> > On Wed, Sep 5, 2018 at 1:45 AM R, Siva wrote:
> > > On Tue, Sep 4, 2018 at 09:16 PM, Alexander Korotkov
> > > wrote:
> > > > Do you have a test scenario for reproduction
Peter Eisentraut writes:
> On 05/09/2018 02:51, Andres Freund wrote:
>> My current proposal is thus to do add a check that does
>> #if defined(__clang__) && defined(__i386__) && !defined(__SSE2_MATH__)
>> something-that-fails
>> #endif
>> in an autoconf test, and have configure complain if that
On 2018-Sep-05, Amit Langote wrote:
> On 2018/09/05 1:50, Alvaro Herrera wrote:
> > Proposed patch. Checking isnull in a elog(ERROR) is important, because
> > the column is not marked NOT NULL. This is not true for other columns
> > where we simply do Assert(!isnull).
>
> Looks good. Thanks
Hi,
I prepared next version of Background worker (cleaner) based on a retail
indextuple deletion patch.
This version shows stable behavior on regression tests and pgbench
workloads.
In this version:
1. Only AccessShareLock are acquired on a cleanup of heap and index
relations.
2. Some
On Wed, Sep 5, 2018 at 3:05 PM Alexander Korotkov
wrote:
>
> On Wed, Sep 5, 2018 at 1:22 AM David G. Johnston
> wrote:
> > On Mon, Sep 3, 2018 at 2:30 PM, Alexander Korotkov
> > wrote:
> >>
> >> The current version of patch doesn't really distinguish spaces and
> >> delimiters in format string
On Wed, Sep 5, 2018 at 12:26 PM Alexander Korotkov
wrote:
> On Wed, Sep 5, 2018 at 1:45 AM R, Siva wrote:
> > On Tue, Sep 4, 2018 at 09:16 PM, Alexander Korotkov
> > wrote:
> > > Do you have a test scenario for reproduction of this issue? We need
> > > it to ensure that fix is correct.
> >
>
(2018/08/30 21:58), Etsuro Fujita wrote:
(2018/08/30 20:37), Kyotaro HORIGUCHI wrote:
At Fri, 24 Aug 2018 21:45:35 +0900, Etsuro
Fujita wrote
in<5b7ffdef.6020...@lab.ntt.co.jp>
(2018/08/21 11:01), Kyotaro HORIGUCHI wrote:
At Tue, 14 Aug 2018 20:49:02 +0900, Etsuro
Fujita wrote
Re: Thomas Munro 2018-09-04
> I was reminded about that by recent news
> about an upcoming glibc/CLDR resync that is likely to affect
> PostgreSQL users (though, I guess, probably only when they do a major
> OS upgrade).
Or replicating/restoring a database to a newer host.
> ... or, on a
Hi,
I have a bug in Windows 7 with max_files_per_process> 1200.
Using dup (0) in the function count_usable_fds more than 1200 times (0
= stdin) causes further unpredictable errors with file operations.
When I open a real file and use its descriptor for the dup, no error
occurs. In the
On Wed, Sep 5, 2018 at 1:22 AM David G. Johnston
wrote:
> On Mon, Sep 3, 2018 at 2:30 PM, Alexander Korotkov
> wrote:
>>
>> The current version of patch doesn't really distinguish spaces and
>> delimiters in format string in non-FX mode. So, spaces and delimiters
>> are forming single group.
On Wed, Sep 5, 2018 at 1:45 AM R, Siva wrote:
> On Tue, Sep 4, 2018 at 09:16 PM, Alexander Korotkov
> wrote:
> > Do you have a test scenario for reproduction of this issue? We need
> > it to ensure that fix is correct.
>
> Unfortunately, I do not have a way of reproducing this issue.
> So far
> 5 сент. 2018 г., в 13:29, Kyotaro HORIGUCHI
> написал(а):
>
> We don't preserve it for Andrey's use case.
Just my 2 cents: that was a hacky use case for development reasons. I think
that removing fillfactor is good idea and your latest patch looks good from my
POV.
Best regards, Andrey
At Tue, 4 Sep 2018 13:05:55 +0300, Alexander Korotkov
wrote in
> On Tue, Sep 4, 2018 at 12:16 PM Kyotaro HORIGUCHI
> wrote:
> > I agree that fillfactor should be ignored in certain cases
> > (inserting the first tuple into empty pages or something like
> > that). Even though GiST doesn't need
On 05/09/2018 02:51, Andres Freund wrote:
> My current proposal is thus to do add a check that does
> #if defined(__clang__) && defined(__i386__) && !defined(__SSE2_MATH__)
> something-that-fails
> #endif
> in an autoconf test, and have configure complain if that
> fails. Something roughly along
>
> Something which would be good to have for all those queries is a set of
> isolation tests. No need for multiple specs, you could just use one
> spec with one session defining all the object types you would like to
> work on. How did you find this object list? Did you test all the
> objects
Richard Guo writes:
> In this patch, we are trying to do the similar deduction, from
> non-equivalence
> clauses, that is, A=B AND f(A) implies A=B AND f(A) and f(B), under some
> restrictions on f.
Uh, *what* restrictions on f()? In general the above equivalence
does not hold, at least not for
On 05/09/18 09:34, Richard Guo wrote:
Hi,
As we know, current planner will generate additional restriction clauses
from
equivalence clauses. This will generally lower the total cost because
some of
tuples may be filtered out before joins.
In this patch, we are trying to do the similar
Hi,
As we know, current planner will generate additional restriction clauses
from
equivalence clauses. This will generally lower the total cost because some
of
tuples may be filtered out before joins.
In this patch, we are trying to do the similar deduction, from
non-equivalence
clauses, that
On Tue, 4 Sep 2018 17:51:30 -0700
Andres Freund wrote:
> #endif
> in an autoconf test, and have configure complain if that
> fails. Something roughly along the lines of
> "Compiling PostgreSQL with clang, on 32bit x86, requires SSE2
> support. Use -msse2 or use gcc."
Adding CFLAGS=-msse2 to
81 matches
Mail list logo
