Re: minio server. Was: Performance of ByteA: ascii vs binary

[Thomas Güttler]

Am 18.03.19 um 17:52 schrieb Adrian Klaver:

On 3/18/19 7:59 AM, Thomas Güttler wrote:



Am 18.03.19 um 15:49 schrieb Tom Lane:

Adrian Klaver  writes:

On 3/18/19 7:33 AM, Thomas Güttler wrote:

If I used ascii data the tests took 52 seconds.
If I used random binary data the test took 250 seconds.


This doesn't seem terribly surprising in bytea_output = escape
mode.  Probably with bytea_output = hex the performance would
be less data-dependent.


Thank you for your fast reply.

I guess we will use a minio server to store the blobs.


According to this:

http://initd.org/psycopg/docs/usage.html?highlight=bytea#adapt-binary

psycopg2 will use 'hex' by default.

Have you tried the test outside Python/psycopg2 e.g in psql to see if the 
performance hit still exists?


No, I did not test it outside Python/psycopg2.

Since our code will use Python/psycopg2 I did not run a test outside.

The decision was made. Now I am busy learning minio. I use it for the first 
time.

Regards,
  Thomas Güttler



--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

Re: recovery_target_time and WAL fetch with streaming replication

[Alexandre Arruda]

Sorry to revive this post, but I have the same problem:

I set a streaming replication slave with this steps:
1) create a physical replication slot in master
2) pg_basebackup -S slot (...)
3) create a recovery.conf with primary_conninfo, primary_slot_name and
recovery_min_apply_delay = '4d'
4) start replica and wal_receiver is started and write the wal files
5) after 4 days, I have a delayed replica and ALL wal files to apply a
recovery from 4 days until now

The problem is: if I restart the master or the replica, the
wal_receiver will not start and the replica will not receive
the new WAL files because all files in the pg_wal match the
recovery_min_apply_delay criteria.
Master will retain the WAL files (because the inactive slot and last
LSN), growing the space to save this wals.

But the real problem is if the master die: I have a replica with only
WAL files until restart.

To solve, I need to receive the WAL by pg_receivewal and use a
traditional cp in recovery.conf to apply them.
But this is an extra work to monitor and cleanup this WALs.

There is a way to start walreceiver independent from
recovery_min_apply_delay set ?

Best regards,

Alexandre







Em dom, 13 de mai de 2018 às 08:45, Michael Paquier
 escreveu:
>
> On Sun, May 13, 2018 at 09:42:42AM +0200, Hannes Erven wrote:
> > But when new WAL is needed, the standby will fetch /all/ WAL present on the
> > master.
>
> Fetching as much WAL as possible when recovery happens is wanted by
> design, so as it recovers as much as possible.  And that's documented.
>
> > I'd say, the standby should either:
> > - always connect to the primary and fetch any WAL present
>
> This is what a hot standby does.  It keeps waiting for WAL to become
> available whichever the source used (archive, local pg_xlog or stream)
> and switches between one or the other.  You can look at
> WaitForWALToBecomeAvailable to get an idea of the details.
>
> > - stop fetching/streaming WAL when it is not needed for the current
> > recovery_target
>
> The startup process is in charge of recovery (WAL replay and definition
> of from where to get the WAL available), and is the one which decides if
> using streaming is necessary or not.  if streaming is used, then it
> starts a WAL receiver.  If a switch from streaming to another WAL source
> (local pg_xlog or archives is done), then it shuts down the WAL
> receiver, consisting in sending SIGTERM to the WAL receiver and stopping
> it immediately with a FATAL message (stops process immediately).  The
> key point is that  WAL receiver is designed to be a light-weight
> transport layer for WAL data.  In short, to be simple, it receives a set
> of WAL bytes and writes them.  It does not include any logic to decode
> WAL records, so it cannot know when a stop point happens or not.  It
> also has no idea of the configuration within recovery.conf, which is
> loaded by the startup process.
>
> > Yes, but thats far less simple than just setting restore_target_time .
>
> It seems to me that archiving provides the control you are looking for.
> --
> Michael

Re: printing JsonbPair values of input JSONB on server side?

[Michel Pelletier]

Yeah I'm not sure why you're looping using pointer math, the iterators are
there to provide that service.  Another function to check out 'jsonb_each',
other than the set returning function parts, it does what it looks like
your are trying to do.

-Michel

On Mon, Mar 18, 2019 at 4:12 PM Andrew Gierth 
wrote:

> > "T" == T L  writes:
>
>  T> Below is my test. It prints a strange character instead of "a"; and
>  T> says that the value isn't numeric.
>
> Yeah, there's plenty else wrong with your code.
>
> Did you look at how JsonbToCStringWorker does it? that looks like the
> best example I can find on a quick scan.
>
> --
> Andrew (irc:RhodiumToad)
>
>

subscription broken after upgrade to pg11

[Radoslav Nedyalkov]

Hi All,
We're testing upgrade from postgres 10.6 to postgres 11.2 with pg_upgrade.
Before stopping pg10 we disabled subscription.
After upgrade and launching pg11,  the existing logical replication
subscription is there and disabled.

stest=# \dRs+
 List of subscriptions
 Name |  Owner   | Enabled | Publication | Synchronous commit |
Conninfo
--+--+-+-++-
 sub1 | postgres | f   | {pub2}  | off|
host=10.2.5.8 dbname=test user=postgres
(1 row)

However after enabling it,  the target table does not get updates,
although the subscription looks okay according to the status below.

stest=# alter subscription sub1 enable;
ALTER SUBSCRIPTION
# no updates here

stest=# \dRs+
List of subscriptions
 Name |  Owner   | Enabled | Publication | Synchronous commit |
Conninfo
--+--+-+-++-
 sub1 | postgres | t   | {pub2}  | off|
host=10.2.5.8 dbname=test user=postgres

stest=# select * from pg_subscription;
 subdbid | subname | subowner | subenabled |   subconninfo
 | subslotname | subsynccommit | subpublications
-+-+--++-+-+---+-
   16402 | sub1|   10 | t  | host=10.2.5.8 dbname=test
user=postgres | sub1| off   | {pub2}

stest=# select * from pg_stat_subscription;
 subid | subname | pid  | relid | received_lsn | last_msg_send_time |
 last_msg_receipt_time | latest_end_lsn |latest_end_time
---+-+--+---+--++---++---
 16413 | sub1| 2810 |   | 0/145C3400   ||
2019-03-19 16:23:23.650073+00 | 0/145C3320 | 2019-03-19
16:23:23.446651+00

Issuing a refresh
stest=# alter subscription sub1 refresh publication with (copy_data =
false);
ALTER SUBSCRIPTION

resumes updates , but with a gap in data. Everything up-to to the refresh
statement is missing in the target.

What we're doing wrong ?

Thanks,
Radoslav

Re: printing JsonbPair values of input JSONB on server side?

[T L]

I need this in my C code on the server side. Any link to the `jsonb_each`
for this? Examples I found in a quick search are on the client side in SQL.

I am just confused about the various jsonb types and how to effectively
extract values and convert between them:

There are Jsonb, JsonbValue (plus the associated JsonbPair ) to begin with.
The ` JsonbToCStringWorker ` example that Andrew pointed out uses still
another "JsonbContainer" type.
But the type I get from "PG_GETARG_JSONB_P" is Jsonb. And it doesn't fit
into " JsonbContainer" or the pointer math about "JsonPair" that I found
online.

What I am struggling with adapting some of the iterator code I saw is how
to delete irrelevant code without breaking it. My use case is very
restricted and handles hstore-like jsonb's.
I don't need or want the code to have the ability to descend into nested
objects or handle arrays etc., as they are invalid input in my case.

I thought the pointer math example I found is easier to adapt, but I
couldn't get a valid "JsonbPair" from the input parameter to feed into the
pointer math.






On Tue, Mar 19, 2019 at 9:50 AM Michel Pelletier 
wrote:

> Yeah I'm not sure why you're looping using pointer math, the iterators are
> there to provide that service.  Another function to check out 'jsonb_each',
> other than the set returning function parts, it does what it looks like
> your are trying to do.
>
> -Michel
>
> On Mon, Mar 18, 2019 at 4:12 PM Andrew Gierth 
> wrote:
>
>> > "T" == T L  writes:
>>
>>  T> Below is my test. It prints a strange character instead of "a"; and
>>  T> says that the value isn't numeric.
>>
>> Yeah, there's plenty else wrong with your code.
>>
>> Did you look at how JsonbToCStringWorker does it? that looks like the
>> best example I can find on a quick scan.
>>
>> --
>> Andrew (irc:RhodiumToad)
>>
>>

Re: printing JsonbPair values of input JSONB on server side?

[Michel Pelletier]

jsonb_each is a wrapper around each_worker_jsonb.  It produces a row for
every key/value pair in an object.

https://doxygen.postgresql.org/jsonfuncs_8c.html#a7511a3aa3918eb956f3f4211d07bdbb0

the iteration is:

  while ((r = JsonbIteratorNext(&it, &v, skipNested)) != WJB_DONE)



On Tue, Mar 19, 2019 at 11:20 AM T L  wrote:

> I need this in my C code on the server side. Any link to the `jsonb_each`
> for this? Examples I found in a quick search are on the client side in SQL.
>
> I am just confused about the various jsonb types and how to effectively
> extract values and convert between them:
>
> There are Jsonb, JsonbValue (plus the associated JsonbPair ) to begin
> with. The ` JsonbToCStringWorker ` example that Andrew pointed out uses
> still another "JsonbContainer" type.
> But the type I get from "PG_GETARG_JSONB_P" is Jsonb. And it doesn't fit
> into " JsonbContainer" or the pointer math about "JsonPair" that I found
> online.
>
> What I am struggling with adapting some of the iterator code I saw is how
> to delete irrelevant code without breaking it. My use case is very
> restricted and handles hstore-like jsonb's.
> I don't need or want the code to have the ability to descend into nested
> objects or handle arrays etc., as they are invalid input in my case.
>
> I thought the pointer math example I found is easier to adapt, but I
> couldn't get a valid "JsonbPair" from the input parameter to feed into the
> pointer math.
>
>
>
>
>
>
> On Tue, Mar 19, 2019 at 9:50 AM Michel Pelletier <
> pelletier.mic...@gmail.com> wrote:
>
>> Yeah I'm not sure why you're looping using pointer math, the iterators
>> are there to provide that service.  Another function to check out
>> 'jsonb_each', other than the set returning function parts, it does what it
>> looks like your are trying to do.
>>
>> -Michel
>>
>> On Mon, Mar 18, 2019 at 4:12 PM Andrew Gierth <
>> and...@tao11.riddles.org.uk> wrote:
>>
>>> > "T" == T L  writes:
>>>
>>>  T> Below is my test. It prints a strange character instead of "a"; and
>>>  T> says that the value isn't numeric.
>>>
>>> Yeah, there's plenty else wrong with your code.
>>>
>>> Did you look at how JsonbToCStringWorker does it? that looks like the
>>> best example I can find on a quick scan.
>>>
>>> --
>>> Andrew (irc:RhodiumToad)
>>>
>>>

Re: Performance of ByteA: ascii vs binary

[Peter J. Holzer]

On 2019-03-18 15:33:17 +0100, Thomas Güttler wrote:
> I did some benchmarking and in my setup there was major
> performance difference.
> 
> I tested a ByteA column.
> 
> If I used ascii data the tests took 52 seconds.
> If I used random binary data the test took 250 seconds.
> 
> binary data is (roughly) five times slower than ascii data?
> 
> Is this a know fact, or is there something wrong with my benchmark?
> 
> I used Python and psycopg2.

I don't see this here (Debian 9, Python 3,5, psycopg2 2.7.6, PostgreSQL
9.5).

I modified my bench-bytea script (https://github.com/hjp/blob-bench) to
restrict the byte values to printable ASCII (32 .. 126). There was
absolutely no difference, as the attached graph shows.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature

Re: printing JsonbPair values of input JSONB on server side?

[T L]

Thanks a lot for the hint. I've used the iteration style and cleaned up the
code as far as I can.
It now correctly prints the keys and values, but the server crashes near
function return.

Any suggestions?

-- function code --

PG_FUNCTION_INFO_V1(print_kv_pair);
Datum
print_kv_pair(PG_FUNCTION_ARGS)
{
//1. extracting JsonbValue
Jsonb *jb = PG_GETARG_JSONB_P(0);
JsonbIterator *it;
JsonbValuev;
JsonbIteratorToken r;
JsonbParseState *state = NULL;

if (jb == NULL)
PG_RETURN_BOOL(false);

if (!JB_ROOT_IS_OBJECT(jb))
ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("Can only take objects")));

it = JsonbIteratorInit(&jb->root);
r = JsonbIteratorNext(&it, &v, false);
if (r != WJB_BEGIN_OBJECT)
ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("Iterator was not an object")));

//2. iterating through key-value pairs
char *buf;
while ((r = JsonbIteratorNext(&it, &v, true)) != WJB_DONE)
{
switch (r) {
case WJB_KEY:
buf = pnstrdup(v.val.string.val, v.val.string.len);
elog(NOTICE, "print_kv_pair(): k = %s", buf);  //debug
break;
case WJB_VALUE:
if (v.type != jbvNumeric) {
ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("value must be numeric")));
}
elog(NOTICE, "print_kv_pair(): v = %s",
DatumGetCString(DirectFunctionCall1(numeric_out,
NumericGetDatum(v.val.numeric))) ); //debug
break;
case WJB_END_OBJECT:
break;
default:
elog(ERROR, "invalid JsonbIteratorNext rc: %d", (int ) r);
}
}
elog(NOTICE, "print_kv_pair(): ok4");

PG_RETURN_BOOL(true);
}

-- output --

=> select print_kv_pair('{"a":1, "b": 2}');
NOTICE:  print_kv_pair(): k = a
NOTICE:  print_kv_pair(): v = 1
NOTICE:  print_kv_pair(): k = b
NOTICE:  print_kv_pair(): v = 2
NOTICE:  print_kv_pair(): ok4
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>


On Tue, Mar 19, 2019 at 2:22 PM Michel Pelletier 
wrote:

> jsonb_each is a wrapper around each_worker_jsonb.  It produces a row for
> every key/value pair in an object.
>
>
> https://doxygen.postgresql.org/jsonfuncs_8c.html#a7511a3aa3918eb956f3f4211d07bdbb0
>
> the iteration is:
>
>   while ((r = JsonbIteratorNext(&it, &v, skipNested)) != WJB_DONE)
>
>
>
> On Tue, Mar 19, 2019 at 11:20 AM T L  wrote:
>
>> I need this in my C code on the server side. Any link to the `jsonb_each`
>> for this? Examples I found in a quick search are on the client side in SQL.
>>
>> I am just confused about the various jsonb types and how to effectively
>> extract values and convert between them:
>>
>> There are Jsonb, JsonbValue (plus the associated JsonbPair ) to begin
>> with. The ` JsonbToCStringWorker ` example that Andrew pointed out uses
>> still another "JsonbContainer" type.
>> But the type I get from "PG_GETARG_JSONB_P" is Jsonb. And it doesn't fit
>> into " JsonbContainer" or the pointer math about "JsonPair" that I found
>> online.
>>
>> What I am struggling with adapting some of the iterator code I saw is how
>> to delete irrelevant code without breaking it. My use case is very
>> restricted and handles hstore-like jsonb's.
>> I don't need or want the code to have the ability to descend into nested
>> objects or handle arrays etc., as they are invalid input in my case.
>>
>> I thought the pointer math example I found is easier to adapt, but I
>> couldn't get a valid "JsonbPair" from the input parameter to feed into the
>> pointer math.
>>
>>
>>
>>
>>
>>
>> On Tue, Mar 19, 2019 at 9:50 AM Michel Pelletier <
>> pelletier.mic...@gmail.com> wrote:
>>
>>> Yeah I'm not sure why you're looping using pointer math, the iterators
>>> are there to provide that service.  Another function to check out
>>> 'jsonb_each', other than the set returning function parts, it does what it
>>> looks like your are trying to do.
>>>
>>> -Michel
>>>
>>> On Mon, Mar 18, 2019 at 4:12 PM Andrew Gierth <
>>> and...@tao11.riddles.org.uk> wrote:
>>>
 > "T" == T L  writes:

  T> Below is my test. It prints a strange character instead of "a"; and
  T> says that the value isn't numeric.

 Yeah, there's plenty else wrong with your code.

 Did you look at how JsonbToCStringWorker does it? that looks like the
 best example I can find on a quick scan.

 --
 Andrew (irc:RhodiumToad)

Re: printing JsonbPair values of input JSONB on server side?

[Michel Pelletier]

For server crashes you can't beat gdb in my opinion.  It's a challenge but
worth it in the long run to have gdb skills if you're coding in C (or
Python, since pdb shares many of gdb's keybindings).

But just looking at the function I don't see what's immediately wrong,
what's your CREATE FUNCTION statement look like?

On Tue, Mar 19, 2019 at 1:08 PM T L  wrote:

> Thanks a lot for the hint. I've used the iteration style and cleaned up
> the code as far as I can.
> It now correctly prints the keys and values, but the server crashes near
> function return.
>
> Any suggestions?
>
> -- function code --
>
> PG_FUNCTION_INFO_V1(print_kv_pair);
> Datum
> print_kv_pair(PG_FUNCTION_ARGS)
> {
> //1. extracting JsonbValue
> Jsonb *jb = PG_GETARG_JSONB_P(0);
> JsonbIterator *it;
> JsonbValuev;
> JsonbIteratorToken r;
> JsonbParseState *state = NULL;
>
> if (jb == NULL)
> PG_RETURN_BOOL(false);
>
> if (!JB_ROOT_IS_OBJECT(jb))
> ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> errmsg("Can only take objects")));
>
> it = JsonbIteratorInit(&jb->root);
> r = JsonbIteratorNext(&it, &v, false);
> if (r != WJB_BEGIN_OBJECT)
> ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> errmsg("Iterator was not an object")));
>
> //2. iterating through key-value pairs
> char *buf;
> while ((r = JsonbIteratorNext(&it, &v, true)) != WJB_DONE)
> {
> switch (r) {
> case WJB_KEY:
> buf = pnstrdup(v.val.string.val, v.val.string.len);
> elog(NOTICE, "print_kv_pair(): k = %s", buf);  //debug
> break;
> case WJB_VALUE:
> if (v.type != jbvNumeric) {
> ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> errmsg("value must be numeric")));
> }
> elog(NOTICE, "print_kv_pair(): v = %s",
> DatumGetCString(DirectFunctionCall1(numeric_out,
> NumericGetDatum(v.val.numeric))) ); //debug
> break;
> case WJB_END_OBJECT:
> break;
> default:
> elog(ERROR, "invalid JsonbIteratorNext rc: %d", (int ) r);
> }
> }
> elog(NOTICE, "print_kv_pair(): ok4");
>
> PG_RETURN_BOOL(true);
> }
>
> -- output --
>
> => select print_kv_pair('{"a":1, "b": 2}');
> NOTICE:  print_kv_pair(): k = a
> NOTICE:  print_kv_pair(): v = 1
> NOTICE:  print_kv_pair(): k = b
> NOTICE:  print_kv_pair(): v = 2
> NOTICE:  print_kv_pair(): ok4
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> !>
>
>
> On Tue, Mar 19, 2019 at 2:22 PM Michel Pelletier <
> pelletier.mic...@gmail.com> wrote:
>
>> jsonb_each is a wrapper around each_worker_jsonb.  It produces a row for
>> every key/value pair in an object.
>>
>>
>> https://doxygen.postgresql.org/jsonfuncs_8c.html#a7511a3aa3918eb956f3f4211d07bdbb0
>>
>> the iteration is:
>>
>>   while ((r = JsonbIteratorNext(&it, &v, skipNested)) != WJB_DONE)
>>
>>
>>
>> On Tue, Mar 19, 2019 at 11:20 AM T L  wrote:
>>
>>> I need this in my C code on the server side. Any link to the
>>> `jsonb_each` for this? Examples I found in a quick search are on the client
>>> side in SQL.
>>>
>>> I am just confused about the various jsonb types and how to effectively
>>> extract values and convert between them:
>>>
>>> There are Jsonb, JsonbValue (plus the associated JsonbPair ) to begin
>>> with. The ` JsonbToCStringWorker ` example that Andrew pointed out uses
>>> still another "JsonbContainer" type.
>>> But the type I get from "PG_GETARG_JSONB_P" is Jsonb. And it doesn't fit
>>> into " JsonbContainer" or the pointer math about "JsonPair" that I found
>>> online.
>>>
>>> What I am struggling with adapting some of the iterator code I saw is
>>> how to delete irrelevant code without breaking it. My use case is very
>>> restricted and handles hstore-like jsonb's.
>>> I don't need or want the code to have the ability to descend into nested
>>> objects or handle arrays etc., as they are invalid input in my case.
>>>
>>> I thought the pointer math example I found is easier to adapt, but I
>>> couldn't get a valid "JsonbPair" from the input parameter to feed into the
>>> pointer math.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Mar 19, 2019 at 9:50 AM Michel Pelletier <
>>> pelletier.mic...@gmail.com> wrote:
>>>
 Yeah I'm not sure why you're looping using pointer math, the iterators
 are there to provide that service.  Another function to check out
 'jsonb_each', other than the set returning function parts, it does what it
 looks like your are trying to do.

 -Michel

 On Mon, Mar 18, 2019 at 4:12 PM Andrew Gierth <
 and...@tao11.riddles.org.uk> wrote:

> > "T" == T L  writes:
>
>  T> Below is my test. It prints a strange character instead of "a"; and
>  T>

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

[Thomas Munro]

On Fri, Mar 15, 2019 at 4:46 PM Noah Misch  wrote:
> Thanks.  That rules out my guess.  I don't have another guess at this time.

Even though I can't reproduce the problem myself, I'm quite keen to go
ahead and push the patch I proposed for v12 anyway, and close this
case.  Otherwise this problem could just keep coming back until
libldap.so is eventually entirely phased out by all distros.  In 2023
I want to be working on quantum parallelism or something, not LDAP bug
reports.  Any objections?

-- 
Thomas Munro
https://enterprisedb.com

Re: printing JsonbPair values of input JSONB on server side?

[T L]

Thanks a lot. Fixing `CREATE FUNCTION` statement fixed the crash issue.


On Tue, Mar 19, 2019 at 3:18 PM Michel Pelletier 
wrote:

> For server crashes you can't beat gdb in my opinion.  It's a challenge but
> worth it in the long run to have gdb skills if you're coding in C (or
> Python, since pdb shares many of gdb's keybindings).
>
> But just looking at the function I don't see what's immediately wrong,
> what's your CREATE FUNCTION statement look like?
>
> On Tue, Mar 19, 2019 at 1:08 PM T L  wrote:
>
>> Thanks a lot for the hint. I've used the iteration style and cleaned up
>> the code as far as I can.
>> It now correctly prints the keys and values, but the server crashes near
>> function return.
>>
>> Any suggestions?
>>
>> -- function code --
>>
>> PG_FUNCTION_INFO_V1(print_kv_pair);
>> Datum
>> print_kv_pair(PG_FUNCTION_ARGS)
>> {
>> //1. extracting JsonbValue
>> Jsonb *jb = PG_GETARG_JSONB_P(0);
>> JsonbIterator *it;
>> JsonbValuev;
>> JsonbIteratorToken r;
>> JsonbParseState *state = NULL;
>>
>> if (jb == NULL)
>> PG_RETURN_BOOL(false);
>>
>> if (!JB_ROOT_IS_OBJECT(jb))
>> ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
>> errmsg("Can only take objects")));
>>
>> it = JsonbIteratorInit(&jb->root);
>> r = JsonbIteratorNext(&it, &v, false);
>> if (r != WJB_BEGIN_OBJECT)
>> ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
>> errmsg("Iterator was not an object")));
>>
>> //2. iterating through key-value pairs
>> char *buf;
>> while ((r = JsonbIteratorNext(&it, &v, true)) != WJB_DONE)
>> {
>> switch (r) {
>> case WJB_KEY:
>> buf = pnstrdup(v.val.string.val, v.val.string.len);
>> elog(NOTICE, "print_kv_pair(): k = %s", buf);  //debug
>> break;
>> case WJB_VALUE:
>> if (v.type != jbvNumeric) {
>> ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
>> errmsg("value must be numeric")));
>> }
>> elog(NOTICE, "print_kv_pair(): v = %s",
>> DatumGetCString(DirectFunctionCall1(numeric_out,
>> NumericGetDatum(v.val.numeric))) ); //debug
>> break;
>> case WJB_END_OBJECT:
>> break;
>> default:
>> elog(ERROR, "invalid JsonbIteratorNext rc: %d", (int ) r);
>> }
>> }
>> elog(NOTICE, "print_kv_pair(): ok4");
>>
>> PG_RETURN_BOOL(true);
>> }
>>
>> -- output --
>>
>> => select print_kv_pair('{"a":1, "b": 2}');
>> NOTICE:  print_kv_pair(): k = a
>> NOTICE:  print_kv_pair(): v = 1
>> NOTICE:  print_kv_pair(): k = b
>> NOTICE:  print_kv_pair(): v = 2
>> NOTICE:  print_kv_pair(): ok4
>> server closed the connection unexpectedly
>> This probably means the server terminated abnormally
>> before or while processing the request.
>> The connection to the server was lost. Attempting reset: Failed.
>> !>
>>
>>
>> On Tue, Mar 19, 2019 at 2:22 PM Michel Pelletier <
>> pelletier.mic...@gmail.com> wrote:
>>
>>> jsonb_each is a wrapper around each_worker_jsonb.  It produces a row for
>>> every key/value pair in an object.
>>>
>>>
>>> https://doxygen.postgresql.org/jsonfuncs_8c.html#a7511a3aa3918eb956f3f4211d07bdbb0
>>>
>>> the iteration is:
>>>
>>>   while ((r = JsonbIteratorNext(&it, &v, skipNested)) != WJB_DONE)
>>>
>>>
>>>
>>> On Tue, Mar 19, 2019 at 11:20 AM T L  wrote:
>>>
 I need this in my C code on the server side. Any link to the
 `jsonb_each` for this? Examples I found in a quick search are on the client
 side in SQL.

 I am just confused about the various jsonb types and how to effectively
 extract values and convert between them:

 There are Jsonb, JsonbValue (plus the associated JsonbPair ) to begin
 with. The ` JsonbToCStringWorker ` example that Andrew pointed out uses
 still another "JsonbContainer" type.
 But the type I get from "PG_GETARG_JSONB_P" is Jsonb. And it doesn't
 fit into " JsonbContainer" or the pointer math about "JsonPair" that I
 found online.

 What I am struggling with adapting some of the iterator code I saw is
 how to delete irrelevant code without breaking it. My use case is very
 restricted and handles hstore-like jsonb's.
 I don't need or want the code to have the ability to descend into
 nested objects or handle arrays etc., as they are invalid input in my case.

 I thought the pointer math example I found is easier to adapt, but I
 couldn't get a valid "JsonbPair" from the input parameter to feed into the
 pointer math.






 On Tue, Mar 19, 2019 at 9:50 AM Michel Pelletier <
 pelletier.mic...@gmail.com> wrote:

> Yeah I'm not sure why you're looping using pointer math, the iterators
> are there to provide that service.  Another function to check out
> 'jsonb_each', other than the set returning function parts, it does what it
> look

Re: subscription broken after upgrade to pg11

[Adrian Klaver]

On 3/19/19 9:35 AM, Radoslav Nedyalkov wrote:

Hi All,
We're testing upgrade from postgres 10.6 to postgres 11.2 with pg_upgrade.
Before stopping pg10 we disabled subscription.
After upgrade and launching pg11,  the existing logical replication 
subscription is there and disabled.


stest=# \dRs+
                                          List of subscriptions
  Name |  Owner   | Enabled | Publication | Synchronous commit |
         Conninfo

--+--+-+-++-
  sub1 | postgres | f       | {pub2}      | off                | 
host=10.2.5.8 dbname=test user=postgres

(1 row)

However after enabling it,  the target table does not get updates,
although the subscription looks okay according to the status below.

stest=# alter subscription sub1 enable;
ALTER SUBSCRIPTION
# no updates here

stest=# \dRs+
                             List of subscriptions
  Name |  Owner   | Enabled | Publication | Synchronous commit |
         Conninfo

--+--+-+-++-
  sub1 | postgres | t       | {pub2}      | off                | 
host=10.2.5.8 dbname=test user=postgres


stest=# select * from pg_subscription;
  subdbid | subname | subowner | subenabled |               subconninfo  
              | subslotname | subsynccommit | subpublications

-+-+--++-+-+---+-
    16402 | sub1    |       10 | t          | host=10.2.5.8 dbname=test 
user=postgres | sub1        | off           | {pub2}


stest=# select * from pg_stat_subscription;
  subid | subname | pid  | relid | received_lsn | last_msg_send_time |  
    last_msg_receipt_time     | latest_end_lsn |        latest_end_time

---+-+--+---+--++---++---
  16413 | sub1    | 2810 |       | 0/145C3400   |                    | 
2019-03-19 16:23:23.650073+00 | 0/145C3320     | 2019-03-19 
16:23:23.446651+00


Issuing a refresh
stest=# alter subscription sub1 refresh publication with (copy_data = 
false);

ALTER SUBSCRIPTION

resumes updates , but with a gap in data. Everything up-to to the 
refresh statement is missing in the target.


What we're doing wrong ?


https://www.postgresql.org/docs/11/sql-altersubscription.html

REFRESH PUBLICATION

Fetch missing table information from publisher. This will start 
replication of tables that were added to the subscribed-to publications 
since the last invocation of REFRESH PUBLICATION or since CREATE 
SUBSCRIPTION.


refresh_option specifies additional options for the refresh 
operation. The supported options are:


copy_data (boolean)

Specifies whether the existing data in the publications that 
are being subscribed to should be copied once the replication starts. 
The default is true.



Try with:

copy_data=true





Thanks,
Radoslav




--
Adrian Klaver
adrian.kla...@aklaver.com

Re: printing JsonbPair values of input JSONB on server side?

[T L]

BTW, my pointer math code was trying to mimic the below code I found for
"uniqueifyJsonbObject".

I just removed the logic for dropping duplicates. My difficulty is that I
couldn't find out how to interface the jsonb object I get from
my "print_kv_pair()" to this function. Just out of curiosity, I am still
interested in finding a way to extract
and feed the JsonValue the right way.

static void
uniqueifyJsonbObject(JsonbValue *object)
{
boolhasNonUniq = false;

Assert(object->type == jbvObject);

if (object->val.object.nPairs > 1)
qsort_arg(object->val.object.pairs, object->val.object.nPairs,
sizeof(JsonbPair),
  lengthCompareJsonbPair, &hasNonUniq);

if (hasNonUniq)
{
JsonbPair  *ptr = object->val.object.pairs + 1,
   *res = object->val.object.pairs;

while (ptr - object->val.object.pairs < object->val.object.nPairs)
{
// Avoid copying over duplicate
if (lengthCompareJsonbStringValue(ptr, res) != 0)
{
res++;
if (ptr != res)
memcpy(res, ptr, sizeof(JsonbPair));
}
ptr++;
}

object->val.object.nPairs = res + 1 - object->val.object.pairs;
}
}


On Tue, Mar 19, 2019 at 9:50 AM Michel Pelletier 
wrote:

> Yeah I'm not sure why you're looping using pointer math, the iterators are
> there to provide that service.  Another function to check out 'jsonb_each',
> other than the set returning function parts, it does what it looks like
> your are trying to do.
>
> -Michel
>
> On Mon, Mar 18, 2019 at 4:12 PM Andrew Gierth 
> wrote:
>
>> > "T" == T L  writes:
>>
>>  T> Below is my test. It prints a strange character instead of "a"; and
>>  T> says that the value isn't numeric.
>>
>> Yeah, there's plenty else wrong with your code.
>>
>> Did you look at how JsonbToCStringWorker does it? that looks like the
>> best example I can find on a quick scan.
>>
>> --
>> Andrew (irc:RhodiumToad)
>>
>>

FreeBSD 12 and Postgres build failures

[Karl Denninger]

Both 10.7 and 11.2 fail on FreeBSD 12-STABLE if --with-openssl is part
of the configure string.

The issue appears to be that FreeBSD updated OpenSSL to OpenSSL
1.1.1a-freebsd  20 Nov 2018 where the 11.x release of FreeBSD (and
previous was on 1.0.x -- e.g. OpenSSL 1.0.2o-freebsd  27 Mar 2018)

The errors start here:

gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv
-fexcess-precision=standard -Wno-format-truncation
-Wno-stringop-truncation -O2 -I../../../src/include    -c -o
be-secure-openssl.o be-secure-openssl.c
be-secure-openssl.c: In function 'be_tls_init':
be-secure-openssl.c:85:3: warning: implicit declaration of function
'OPENSSL_init_ssl'; did you mean 'OPENSSL_init'?
[-Wimplicit-function-declaration]
   OPENSSL_init_ssl(OPENSSL_INIT_LOAD_CONFIG, NULL);
   ^~~~
   OPENSSL_init
be-secure-openssl.c:85:20: error: 'OPENSSL_INIT_LOAD_CONFIG' undeclared
(first use in this function); did you mean 'OPENSSL_NO_PADLOCK'?
   OPENSSL_init_ssl(OPENSSL_INIT_LOAD_CONFIG, NULL);
    ^~~~
    OPENSSL_NO_PADLOCK
be-secure-openssl.c:85:20: note: each undeclared identifier is reported
only once for each function it appears in
be-secure-openssl.c: In function 'my_sock_read':
be-secure-openssl.c:665:35: warning: implicit declaration of function
'BIO_get_data'; did you mean 'BIO_get_ex_data'?
[-Wimplicit-function-declaration]
   res = secure_raw_read(((Port *) BIO_get_data(h)), buf, size);
   ^~~~
   BIO_get_ex_data
be-secure-openssl.c:665:26: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
   res = secure_raw_read(((Port *) BIO_get_data(h)), buf, size);
  ^

Has anyone looked into and dealt with this yet or have suggestions?

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

[Tom Lane]

Thomas Munro  writes:
> Even though I can't reproduce the problem myself, I'm quite keen to go
> ahead and push the patch I proposed for v12 anyway, and close this
> case.  Otherwise this problem could just keep coming back until
> libldap.so is eventually entirely phased out by all distros.  In 2023
> I want to be working on quantum parallelism or something, not LDAP bug
> reports.  Any objections?

Do we have any clear reason to believe this'd actually fix Mike's problem?
AFAIK the analogy to the old destructor-conflict issue is just a guess,
and we don't really know exactly what is going wrong.

It's reasonable to assume that the proposed patch won't cause real issues
on any modern platform, but I'm not sure we can assume that for old ones,
so the whole thing is making me a bit nervous.  Still, it's nice
simplification to not have different frontend and backend LDAP libs.

As far as the specifics of the patch go, I don't like that you didn't
adjust any of the comments near pthread_is_threaded_np() usages.

regards, tom lane

Re: FreeBSD 12 and Postgres build failures

[Tom Lane]

Karl Denninger  writes:
> Both 10.7 and 11.2 fail on FreeBSD 12-STABLE if --with-openssl is part
> of the configure string.

Hmmm ... I don't have that exact configuration handy to try, but
we know that PG works against OpenSSL 1.1.1a in principle, and
it does work for me with FreeBSD 12.0-RC1 from mid-November,
which contains
# openssl version
OpenSSL 1.1.1-freebsd  11 Sep 2018

The error you quote looks a bit like bad decisions in PG's configure
script --- maybe you need to re-run configure?  Be sure to blow
away any autoconf cache file if you're using one.

regards, tom lane

Re: FreeBSD 12 and Postgres build failures

[Thomas Munro]

On Wed, Mar 20, 2019 at 11:13 AM Tom Lane  wrote:
> Karl Denninger  writes:
> > Both 10.7 and 11.2 fail on FreeBSD 12-STABLE if --with-openssl is part
> > of the configure string.
>
> Hmmm ... I don't have that exact configuration handy to try, but
> we know that PG works against OpenSSL 1.1.1a in principle, and
> it does work for me with FreeBSD 12.0-RC1 from mid-November,
> which contains
> # openssl version
> OpenSSL 1.1.1-freebsd  11 Sep 2018
>
> The error you quote looks a bit like bad decisions in PG's configure
> script --- maybe you need to re-run configure?  Be sure to blow
> away any autoconf cache file if you're using one.

Builds OK for me on FreeBSD 12.0-RELEASE (using OpenSSL 1.1.1a-freebsd
from base system), tested with PostgreSQL REL_11_STABLE.  +1 for the
autoconf cache theory.

-- 
Thomas Munro
https://enterprisedb.com

Re: FreeBSD 12 and Postgres build failures

[Andrew Gierth]

> "Karl" == Karl Denninger  writes:

 Karl> Both 10.7 and 11.2 fail on FreeBSD 12-STABLE if --with-openssl is
 Karl> part of the configure string.

Nope, they work fine for me, running under 12-stable as of a couple of
weeks ago.

-- 
Andrew (irc:RhodiumToad)

Re: FreeBSD 12 and Postgres build failures

[Karl Denninger]

On 3/19/2019 17:12, Tom Lane wrote:
> Karl Denninger  writes:
>> Both 10.7 and 11.2 fail on FreeBSD 12-STABLE if --with-openssl is part
>> of the configure string.
> Hmmm ... I don't have that exact configuration handy to try, but
> we know that PG works against OpenSSL 1.1.1a in principle, and
> it does work for me with FreeBSD 12.0-RC1 from mid-November,
> which contains
> # openssl version
> OpenSSL 1.1.1-freebsd  11 Sep 2018
>
> The error you quote looks a bit like bad decisions in PG's configure
> script --- maybe you need to re-run configure?  Be sure to blow
> away any autoconf cache file if you're using one.
>
>   regards, tom lane

That was on a bare, new grab of the source from your repository and a
straight-up run of "./configure --with-openssl --with-perl", then "gmake".

It's a new directory tree - there's no autoconf or other cache files
laying around.

Same grab on FreeBSD 11.x builds fine.

Digging around I had the openssl-1.0.2r port on the system, which used
to be necessary for some other stuff back before 12.x.  I've removed it
and it looks like that took care of it; for whatever reason configure
was getting confused (in theory this shouldn't get you, but theory and
practice sometimes don't play nice. :-)

Thanks for the confirm that others do have it working; gave me a place
to start looking for the issue.

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: FreeBSD 12 and Postgres build failures

[Thomas Munro]

On Wed, Mar 20, 2019 at 11:33 AM Karl Denninger  wrote:
> Digging around I had the openssl-1.0.2r port on the system, which used to be 
> necessary for some other stuff back before 12.x.  I've removed it and it 
> looks like that took care of it; for whatever reason configure was getting 
> confused (in theory this shouldn't get you, but theory and practice sometimes 
> don't play nice. :-)

Hmm.  I guess it'd be good not to get confused between ports and base
OpenSSL installations...  is there something we're doing wrong that
makes that happen?

-- 
Thomas Munro
https://enterprisedb.com

Re: FreeBSD 12 and Postgres build failures

[Andrew Gierth]

> "Karl" == Karl Denninger  writes:

 Karl> That was on a bare, new grab of the source from your repository and a
 Karl> straight-up run of "./configure --with-openssl --with-perl", then 
"gmake".

That's a configure line that has never worked on FreeBSD:

% ./configure --with-openssl --with-perl
[...]
configure: error: readline header not found
If you have libedit already installed, see config.log for details on the
failure.  It is possible the compiler isn't looking in the proper directory.
Use --without-readline to disable libedit support.
%

(If you don't use --without-readline then you must add
--with-includes=/usr/local/include and --with-libs=/usr/local/lib to
pick up either ports readline or ports libedit. Or you might be able to
use --with-includes=/usr/include/edit to get base system libedit, but
that's not really the recommended method. Besides libedit sucks for
actual use so you want readline anyway.)

If you didn't explicitly specify any of those, but configure found a
readline to use anyway, then it means you have defined some non-standard
compiler options or have messed with the include paths in some other
way, which could be relevant to your problem.

-- 
Andrew (irc:RhodiumToad)

Re: FreeBSD 12 and Postgres build failures

[Karl Denninger]

On 3/19/2019 18:15, Andrew Gierth wrote:
>> "Karl" == Karl Denninger  writes:
>  Karl> That was on a bare, new grab of the source from your repository and a
>  Karl> straight-up run of "./configure --with-openssl --with-perl", then 
> "gmake".
>
> That's a configure line that has never worked on FreeBSD:
>
> % ./configure --with-openssl --with-perl
> [...]
> configure: error: readline header not found
> If you have libedit already installed, see config.log for details on the
> failure.  It is possible the compiler isn't looking in the proper directory.
> Use --without-readline to disable libedit support.
> %

Uh, it has worked on all my FreeBSD systems for a very long time; I've
been running Postgres as the backend for a web forum/blogging system for
the last many years.  Then again:

[karl@NewFS ~]$ pkg info|grep readline
readline-7.0.5 Library for editing command lines as they
are typed

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: FreeBSD 12 and Postgres build failures

[Andrew Gierth]

> "Karl" == Karl Denninger  writes:

 >> That's a configure line that has never worked on FreeBSD:
 >> 
 >> % ./configure --with-openssl --with-perl
 >> [...]
 >> configure: error: readline header not found
 >> If you have libedit already installed, see config.log for details on the
 >> failure.  It is possible the compiler isn't looking in the proper directory.
 >> Use --without-readline to disable libedit support.
 >> %

 Karl> Uh, it has worked on all my FreeBSD systems for a very long time;

Then you have done something non-standard, because "cc" on FreeBSD does
not look in /usr/local/include or /usr/local/lib without being told to
do so, and the configure checks for readline will fail without that.
Possible explanations include having a "gcc" (without a specific version
suffix) on the $PATH (gcc will be chosen over cc in that case), or
having configured CFLAGS or CPPFLAGS in the environment to ./configure.

You might post your full output of ./configure rather than leaving us to
guess at it.

-- 
Andrew (irc:RhodiumToad)

Re: FreeBSD 12 and Postgres build failures

[Karl Denninger]

On 3/19/2019 21:12, Andrew Gierth wrote:
>> "Karl" == Karl Denninger  writes:
>  >> That's a configure line that has never worked on FreeBSD:
>  >> 
>  >> % ./configure --with-openssl --with-perl
>  >> [...]
>  >> configure: error: readline header not found
>  >> If you have libedit already installed, see config.log for details on the
>  >> failure.  It is possible the compiler isn't looking in the proper 
> directory.
>  >> Use --without-readline to disable libedit support.
>  >> %
>
>  Karl> Uh, it has worked on all my FreeBSD systems for a very long time;
>
> Then you have done something non-standard, because "cc" on FreeBSD does
> not look in /usr/local/include or /usr/local/lib without being told to
> do so, and the configure checks for readline will fail without that.
> Possible explanations include having a "gcc" (without a specific version
> suffix) on the $PATH (gcc will be chosen over cc in that case), or
> having configured CFLAGS or CPPFLAGS in the environment to ./configure.
>
> You might post your full output of ./configure rather than leaving us to
> guess at it.

"cc" on FreeBSD is now (and has been for quite some time) clang:

root@NewFS:/home/karl # cc -v

FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on
LLVM 6.0.1)
Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin

If it will compile Postgres now it definitely would not when it was
first shifted to; gcc, on the other hand (and gmake) does just fine and
yes, they are ports (packages in this case as they're binary installs on
this box) and not part of the base system:

root@NewFS:/home/karl # which gcc
/usr/local/bin/gcc
root@NewFS:/home/karl # gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc8/gcc/x86_64-portbld-freebsd12.0/8.3.0/lto-wrapper
Target: x86_64-portbld-freebsd12.0
Configured with: /wrkdirs/usr/ports/lang/gcc8/work/gcc-8.3.0/configure
--with-build-config=bootstrap-debug --disable-nls
--enable-gnu-indirect-function --libdir=/usr/local/lib/gcc8
--libexecdir=/usr/local/libexec/gcc8 --program-suffix=8
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc8/include/c++/
--with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection'
--with-system-zlib --enable-languages=c,c++,objc,fortran
--prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/share/info/gcc8 --build=x86_64-portbld-freebsd12.0
Thread model: posix
gcc version 8.3.0 (FreeBSD Ports Collection)

I'll spin up a test machine on a "virgin" install when I get one free
from other things and see exactly what I have to put on there in terms
of ports.

In any event with the removal of the openssl port it now configures,
compiles, links and runs.

config.log makes clear it is using gcc (as did the blowup)

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by PostgreSQL configure 11.2, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure --with-openssl --with-perl

## - ##
## Platform. ##
## - ##

hostname = NewFS.denninger.net
uname -m = amd64
uname -r = 12.0-STABLE
uname -s = FreeBSD
uname -v = FreeBSD 12.0-STABLE r343809 KSD-SMP

/usr/bin/uname -p = amd64
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /sbin
PATH: /bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /root/bin


## --- ##
## Core tests. ##
## --- ##

configure:2840: checking build system type
configure:2854: result: x86_64-unknown-freebsd12.0
configure:2874: checking host system type
configure:2887: result: x86_64-unknown-freebsd12.0
configure:2909: checking which template to use
configure:2977: result: freebsd
configure:3102: checking whether NLS is wanted
configure:3134: result: no
configure:3142: checking for default port number
configure:3167: result: 5432
configure:3672: checking for block size
configure:3706: result: 8kB
configure:3718: checking for segment size
configure:3747: result: 1GB
configure:3759: checking for WAL block size
configure:3794: result: 8kB
configure:3891: checking for gcc
configure:3907: found /usr/local/bin/gcc
configure:3918: result: gcc
configure:3949: checking for C compiler version
configure:3958: gcc --version >&5
gcc (FreeBSD Ports Collection) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3969: $? = 0
configure:3958: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc8/gcc/x86_64-portbld-freebsd12.0/8.3.

Re: FreeBSD 12 and Postgres build failures

[Andrew Gierth]

> "Karl" == Karl Denninger  writes:

 Karl> "cc" on FreeBSD is now (and has been for quite some time) clang:

 Karl> If it will compile Postgres now it definitely would not when it
 Karl> was first shifted to;

People have been building PG with clang since at least as far back as
clang 3.1, and the FreeBSD 10.0 (which I believe was the first FreeBSD
release where clang was the default) package builds of PG were built
with clang 3.3. (Now, of course, clang is _required_ if you want to try
out the new JIT features.)

Building with gcc on FreeBSD is not the default on a clean system, and
as we've recently seen with another report, there are issues with mixing
the gcc and llvm toolchains on some architectures that are not in any
way PG's problem to solve. (Though the fact that we prefer gcc to cc in
configure if both are found is a decision that should probably be
revisited, given that the reasons for that preference are mostly
consigned to the graveyard of commercial Unix variants.)

You might also have considered that the fact that package builds exist
for pg 10 and 11 on FreeBSD 12 is a demonstration that building them is,
in fact, possible on a clean system...

 Karl> root@NewFS:/home/karl # which gcc
 Karl> /usr/local/bin/gcc

I had not previously noticed that the lang/gcc metaport (which I have
never installed, though I have lang/gcc8 installed at the moment)
installs a symlink to the selected gcc version as just "gcc". That
explains a lot.

-- 
Andrew (irc:RhodiumToad)

Re: FreeBSD 12 and Postgres build failures

[Thomas Munro]

On Wed, Mar 20, 2019 at 6:41 PM Andrew Gierth
 wrote:
> ... (Though the fact that we prefer gcc to cc in
> configure if both are found is a decision that should probably be
> revisited, given that the reasons for that preference are mostly
> consigned to the graveyard of commercial Unix variants.)

+1

I'm not against looking for gcc and g++ if cc and c++ can't be found,
but preferring them (ie implying that some random GCC found on the
path that you didn't explicitly ask for must surely be better than
whatever crap the vendor ships) makes no sense in this day and age.
The silliest case is macOS, where gcc and g++ are found and used but
are in fact... wrappers for clang, for maximum confusion.

-- 
Thomas Munro
https://enterprisedb.com