Re: [HACKERS] Turning recovery.conf into GUCs

On Sat, Nov 22, 2014 at 12:24 AM, Stephen Frost wrote: > > * Josh Berkus (j...@agliodbs.com) wrote: > > > Either way, from the code it is clear that we only stay in recovery if > > > standby_mode is directly turned on. This makes the whole check for a > > > specially named file unnecessary, IMO:

Re: [HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

On Fri, Nov 21, 2014 at 7:49 PM, Marko Tiikkaja wrote: > A common mistake is to try and qualify column references on the LHS of SET > in UPDATE. I think that this is a good idea, but as written the patch doesn't handle aliases correctly: postgres=# create table foo (val text); CREATE TABLE postg

[HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

Hi, A common mistake is to try and qualify column references on the LHS of SET in UPDATE. The error message can be a bit cryptic at times, too. I've attached a patch to try and improve the situation a bit: =# create table foo(bar int); CREATE TABLE =# update foo set foo.bar = 1; ERROR: col

Re: [HACKERS] How to use brin indexes?

Alvaro Herrera wrote: > hubert depesz lubaczewski wrote: > > > The minmax operator families don't include any cross-type operators. I'm > > not exactly sure why not.. Alvaro? > > > Anyway, try "select * from t where id = 1224::int8" > > > > It works that way, but it would be great to have it worki

Re: [HACKERS] Automatic PG_PRINTF_ATTRIBUTE

On Fri, Nov 21, 2014 at 08:13:17PM -0500, Tom Lane wrote: > Andres Freund writes: > > On 2014-11-21 03:12:14 -0500, Noah Misch wrote: > >> ... I'm > >> increasingly using an affected compiler, because it builds twice as > >> quickly as > >> today's gcc. > > > No objections to the patch itself, b

Re: [HACKERS] Automatic PG_PRINTF_ATTRIBUTE

Andres Freund writes: > On 2014-11-21 03:12:14 -0500, Noah Misch wrote: >> ... I'm >> increasingly using an affected compiler, because it builds twice as quickly >> as >> today's gcc. > No objections to the patch itself, but this seems like quite the odd > approach. Sure those old compilers migh

Re: [HACKERS] Automatic PG_PRINTF_ATTRIBUTE

Hi, On 2014-11-21 03:12:14 -0500, Noah Misch wrote: > pg_config_manual.h has been choosing gnu_printf as the PG_PRINTF_ATTRIBUTE for > every MinGW build. That invites a torrent of warnings on pre-gcc-4.4 MinGW > compilers, including the compiler on buildfarm member narwhal. I'm > increasingly us

Re: [HACKERS] Automatic PG_PRINTF_ATTRIBUTE

On Fri, Nov 21, 2014 at 01:16:25PM -0500, Tom Lane wrote: > Noah Misch writes: > > pg_config_manual.h has been choosing gnu_printf as the PG_PRINTF_ATTRIBUTE > > for > > every MinGW build. That invites a torrent of warnings on pre-gcc-4.4 MinGW > > compilers, including the compiler on buildfarm

Re: [HACKERS] [v9.5] Custom Plan API

> Kouhei Kaigai writes: > > Let assume a custom-scan provider that runs on a materialized-view > > (or, something like a query cache in memory) instead of join. > > In this case, a reasonable design is to fetch a tuple from the > > materialized-view then put it on the ecxt_scantuple of ExprContext

Re: [HACKERS] Should the removal of SnapshotNow be in the compatibility warnings for 9.4?

Josh Berkus writes: > ... I think it should. > It'll break some extensions, so we should warn people about it more > prominently. Robert's text lower down in the release notes is fine, > but we should put a more prominent warning at the top with the other > backwards compatibility breakage. I d

Re: [HACKERS] KNN-GiST with recheck

On Mon, Jan 13, 2014 at 9:17 AM, Alexander Korotkov wrote: > This patch was split from thread: > http://www.postgresql.org/message-id/CAPpHfdscOX5an71nHd8WSUH6GNOCf=V7wgDaTXdDd9=gon-...@mail.gmail.com > > I've split it to separate thead, because it's related to partial sort only > conceptually not

Re: [HACKERS] [v9.5] Custom Plan API

Kouhei Kaigai writes: > Let assume a custom-scan provider that runs on a materialized-view > (or, something like a query cache in memory) instead of join. > In this case, a reasonable design is to fetch a tuple from the > materialized-view then put it on the ecxt_scantuple of ExprContext > prior t

[HACKERS] Should the removal of SnapshotNow be in the compatibility warnings for 9.4?

... I think it should. It'll break some extensions, so we should warn people about it more prominently. Robert's text lower down in the release notes is fine, but we should put a more prominent warning at the top with the other backwards compatibility breakage. -- Josh Berkus PostgreSQL Expert

Re: [HACKERS] [v9.5] Custom Plan API

> Kouhei Kaigai writes: > >> I've done some preliminary cleanup on this patch, but I'm still > >> pretty desperately unhappy about some aspects of it, in particular > >> the way that it gets custom scan providers directly involved in > >> setrefs.c, finalize_primnode, and replace_nestloop_params p

Re: [HACKERS] Functions used in index definitions shouldn't be changed

On 11/21/14, 9:06 AM, Tom Lane wrote: Albe Laurenz writes: There is also the possibility to add syntax like this: CREATE OR REPLACE [FORCE] FUNCTION ... What do you think about that? It would protect the casual user but allow the expert to do it anyway. I don't see any great attraction to th

Re: [HACKERS] pg_multixact not getting truncated

On 11/21/14, 12:51 PM, Josh Berkus wrote: On 11/21/2014 10:44 AM, Josh Berkus wrote: Greg, This is actually the way it used to be. It was changed because it was discovered there was some case where an unfrozen xid would end up in template0 anyways and for some reason it was hard to be sure to

Re: [HACKERS] Transient failure of rowsecurity regression test

* Tom Lane (t...@sss.pgh.pa.us) wrote: > According to > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dromedary&dt=2014-11-21%2019%3A59%3A50 > the order of cascaded drops at one point in the rowsecurity test is not > too stable. This is not terribly surprising since it would depend on > p

Re: [HACKERS] superuser() shortcuts

All, > It was brought up for discussion- see > > http://www.postgresql.org/message-id/20141015052259.gg28...@tamriel.snowman.net > > Specifically: > --- > One curious item to note is that the > current if(!superuser()) {} block approach has masked an inconsistency > in at least

Re: [HACKERS] How to use brin indexes?

hubert depesz lubaczewski wrote: > > The minmax operator families don't include any cross-type operators. I'm > not exactly sure why not.. Alvaro? > > Anyway, try "select * from t where id = 1224::int8" > > It works that way, but it would be great to have it working with non-casted > values too.

[HACKERS] Transient failure of rowsecurity regression test

According to http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dromedary&dt=2014-11-21%2019%3A59%3A50 the order of cascaded drops at one point in the rowsecurity test is not too stable. This is not terribly surprising since it would depend on physical row order in pg_depend. I think the easi

Re: [HACKERS] How to use brin indexes?

> The minmax operator families don't include any cross-type operators. I'm not exactly sure why not.. Alvaro? > Anyway, try "select * from t where id = 1224::int8" It works that way, but it would be great to have it working with non-casted values too. depesz

Re: [HACKERS] RLS with check option - surprised design

* Peter Geoghegan (p...@heroku.com) wrote: > On Fri, Nov 21, 2014 at 6:57 AM, Stephen Frost wrote: > > Are you sure this isn't just another example of an existing issue we > > have wrt column privileges..? I'm working on a patch already to address > > those issues in back-branches and will be con

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Thu, Nov 20, 2014 at 10:58 PM, Anssi Kääriäinen wrote: > Django uses the command tag currently to check if a row was updated. We > also use RETURNING to get SERIAL values back from the database on > insert. > > The most likely place to use this functionality in Django is > Model.save(). This me

Re: [HACKERS] Additional role attributes && superuser review

On 11/06/2014 03:31 AM, Robert Haas wrote: [snip] We haven't reached consensus on this one yet and I didn't want it to fall too far off the radar. Here is what I summarize as the current state of the discussion: 1. Syntax: ALTER ROLE { ADD | DROP } CAPABILITY Though a bit late to this thr

Re: [HACKERS] psql \sf doesn't show it's SQL when ECHO_HIDDEN is on

On 11/21/2014 02:44 PM, Tom Lane wrote: Andrew Dunstan writes: Well, now we get things like this: ERROR: more than one function named "abc" LINE 1: SELECT 'abc'::pg_catalog.regproc::pg_catalog.oid whereas minimal_error_message suppressed the second line. If we want to preserve that

Re: [HACKERS] RLS with check option - surprised design

On Fri, Nov 21, 2014 at 6:57 AM, Stephen Frost wrote: > Are you sure this isn't just another example of an existing issue we > have wrt column privileges..? I'm working on a patch already to address > those issues in back-branches and will be considering what needs to be > done for RLS also. I t

Re: [HACKERS] How to use brin indexes?

On 11/21/2014 09:59 PM, hubert depesz lubaczewski wrote: I tried to add BRIN index on very simple table, to test it for "Waiting for" blogpost, btu I can't get it to work. I got newest git head, and ran: $ create table t (id int8); CREATE TABLE (depesz@[local]:5930) 20:56:22 [depesz] $ insert i

[HACKERS] How to use brin indexes?

I tried to add BRIN index on very simple table, to test it for "Waiting for" blogpost, btu I can't get it to work. I got newest git head, and ran: $ create table t (id int8); CREATE TABLE (depesz@[local]:5930) 20:56:22 [depesz] $ insert into t select generate_series(1,100); INSERT 0 100 (

Re: [HACKERS] psql \sf doesn't show it's SQL when ECHO_HIDDEN is on

On 11/21/2014 02:44 PM, Tom Lane wrote: Andrew Dunstan writes: Well, now we get things like this: ERROR: more than one function named "abc" LINE 1: SELECT 'abc'::pg_catalog.regproc::pg_catalog.oid whereas minimal_error_message suppressed the second line. If we want to preserve that

Re: [HACKERS] 9.5: Better memory accounting, towards memory-bounded HashAgg

On 21.11.2014 00:03, Andres Freund wrote: > On 2014-11-17 21:03:07 +0100, Tomas Vondra wrote: >> On 17.11.2014 19:46, Andres Freund wrote: >> >>> The MemoryContextData struct is embedded into AllocSetContext. >> >> Oh, right. That makes is slightly more complicated, though, because >> AllocSetConte

Re: [HACKERS] psql \sf doesn't show it's SQL when ECHO_HIDDEN is on

Andrew Dunstan writes: > Well, now we get things like this: > ERROR: more than one function named "abc" > LINE 1: SELECT 'abc'::pg_catalog.regproc::pg_catalog.oid > whereas minimal_error_message suppressed the second line. If we want to > preserve that older behaviour we'll have to aba

Re: [HACKERS] pg_multixact not getting truncated

Josh Berkus wrote: > Actually, here's a question ... pg_clog is usually smaller than I think > it should be (that is, smaller than 4bytes * XID_age). Why is that? It's not 4 bytes per Xid, but 2 bits per Xid, so Xid_age / 4. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreS

Re: [HACKERS] psql \sf doesn't show it's SQL when ECHO_HIDDEN is on

On 11/21/2014 01:05 PM, Andrew Dunstan wrote: On 11/21/2014 12:32 PM, Tom Lane wrote: Andrew Dunstan writes: On 11/21/2014 11:11 AM, Pavel Stehule wrote: I noticed the other day that psql doesn't honor ECHO_HIDDEN for \sf. OK. it was so trivial I just did it. I think it may not be quite a

Re: [HACKERS] Turning recovery.conf into GUCs

On 11/21/2014 10:54 AM, Stephen Frost wrote: > * Josh Berkus (j...@agliodbs.com) wrote: >>> Either way, from the code it is clear that we only stay in recovery if >>> standby_mode is directly turned on. This makes the whole check for a >>> specially named file unnecessary, IMO: we should just chec

Re: [HACKERS] Turning recovery.conf into GUCs

* Josh Berkus (j...@agliodbs.com) wrote: > > Either way, from the code it is clear that we only stay in recovery if > > standby_mode is directly turned on. This makes the whole check for a > > specially named file unnecessary, IMO: we should just check the value of > > standby_mode (which is off b

Re: [HACKERS] pg_multixact not getting truncated

On 11/21/2014 10:44 AM, Josh Berkus wrote: > Greg, > > >> This is actually the way it used to be. It was changed because it was >> discovered there was some case where an unfrozen xid would end up in >> template0 anyways and for some reason it was hard to be sure to avoid it. I >> don't recall ex

Re: [HACKERS] pg_multixact not getting truncated

Greg, > This is actually the way it used to be. It was changed because it was > discovered there was some case where an unfrozen xid would end up in > template0 anyways and for some reason it was hard to be sure to avoid it. I > don't recall exactly what the situation was that triggered it but th

Re: [HACKERS] Automatic PG_PRINTF_ATTRIBUTE

Noah Misch writes: > pg_config_manual.h has been choosing gnu_printf as the PG_PRINTF_ATTRIBUTE for > every MinGW build. That invites a torrent of warnings on pre-gcc-4.4 MinGW > compilers, including the compiler on buildfarm member narwhal. I'm > increasingly using an affected compiler, because

Re: [HACKERS] pg_multixact not getting truncated

On Thu, Nov 20, 2014 at 9:21 PM, Josh Berkus wrote: > Well, the first thing that comes to mind is that template0 should be > "permanently frozen". That is, all objects in it should be created with > frozen xid and mxids. After all, nobody can modify anything in it. This is actually the way it use

Re: [HACKERS] psql \sf doesn't show it's SQL when ECHO_HIDDEN is on

On 11/21/2014 12:32 PM, Tom Lane wrote: Andrew Dunstan writes: On 11/21/2014 11:11 AM, Pavel Stehule wrote: I noticed the other day that psql doesn't honor ECHO_HIDDEN for \sf. OK. it was so trivial I just did it. I think it may not be quite as trivial as that. In particular, PSQLexec alre

Re: [HACKERS] Turning recovery.conf into GUCs

On 11/21/2014 09:35 AM, Alex Shulgin wrote: > Hello, > > Here's an attempt to revive this patch. Yayy! Thank you. >> People might not like me for the suggestion, but I think we should >> simply always include a 'recovery.conf' in $PGDATA >> unconditionally. That'd make this easier. >> Alternati

Re: [HACKERS] Turning recovery.conf into GUCs

Hello, Here's an attempt to revive this patch. It is rebased onto the latest master and also includes handling and documentation of newly added recovery.conf parameters such as primary_slot_name, recovery_min_apply_delay and recovery_target='immediate'. The following feedback had been addressed:

Re: [HACKERS] psql \sf doesn't show it's SQL when ECHO_HIDDEN is on

Andrew Dunstan writes: > On 11/21/2014 11:11 AM, Pavel Stehule wrote: >>> I noticed the other day that psql doesn't honor ECHO_HIDDEN for \sf. > OK. it was so trivial I just did it. I think it may not be quite as trivial as that. In particular, PSQLexec already contains error-reporting function

Re: [HACKERS] [v9.5] Custom Plan API

Robert Haas writes: > As I said, I wasn't sure we wanted to commit to the API enough to > document it, and by the time you get done whacking the stuff above > around, the documentation KaiGai wrote for it (which was also badly in > need of editing by a native English speaker) would have been mostl

Re: [HACKERS] psql \sf doesn't show it's SQL when ECHO_HIDDEN is on

On 11/21/2014 11:11 AM, Pavel Stehule wrote: 2014-11-21 16:46 GMT+01:00 Tom Lane >: Andrew Dunstan mailto:and...@dunslane.net>> writes: > I noticed the other day that psql doesn't honor ECHO_HIDDEN for \sf. > This looks on a somewhat cursory examina

Re: [HACKERS] psql \sf doesn't show it's SQL when ECHO_HIDDEN is on

2014-11-21 16:46 GMT+01:00 Tom Lane : > Andrew Dunstan writes: > > I noticed the other day that psql doesn't honor ECHO_HIDDEN for \sf. > > This looks on a somewhat cursory examination to be the only significant > > place that doesn't. Is there any reason for this, or should I just > > adjust it

Re: [HACKERS] [v9.5] Custom Plan API

Kouhei Kaigai writes: >> I've done some preliminary cleanup on this patch, but I'm still pretty >> desperately unhappy about some aspects of it, in particular the way that >> it gets custom scan providers directly involved in setrefs.c, >> finalize_primnode, and replace_nestloop_params processing.

Re: [HACKERS] psql \sf doesn't show it's SQL when ECHO_HIDDEN is on

Andrew Dunstan writes: > I noticed the other day that psql doesn't honor ECHO_HIDDEN for \sf. > This looks on a somewhat cursory examination to be the only significant > place that doesn't. Is there any reason for this, or should I just > adjust it so that it uses PSQLexec like pretty much ever

Re: [HACKERS] make installcheck.

BTW, so far as that goes, make installcheck should honor PGOPTIONS, so you should be able to pass in "-c online_analyze.enable = off". Thank you a lot, this works. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW:

Re: [HACKERS] make installcheck.

If you're fooling with the optimizer's behavior I'd think a lot of the core regression tests would show bogus "failures" as well. Contrib module tests seem like the least of your worries. make check works well, of course, and I don't run core tests with installcheck. But when module updates I'

[HACKERS] psql \sf doesn't show it's SQL when ECHO_HIDDEN is on

I noticed the other day that psql doesn't honor ECHO_HIDDEN for \sf. This looks on a somewhat cursory examination to be the only significant place that doesn't. Is there any reason for this, or should I just adjust it so that it uses PSQLexec like pretty much every other slash command? cheers

Re: [HACKERS] superuser() shortcuts

Peter, * Peter Eisentraut (pete...@gmx.net) wrote: > On 11/5/14 5:10 PM, Adam Brightwell wrote: > > Attached is two separate patches to address previous > > comments/recommendations: > > > > * superuser-cleanup-shortcuts_11-5-2014.patch > > Seeing that the regression tests had to be changed in t

Re: [HACKERS] make installcheck.

Teodor Sigaev writes: > On production instance I have an installed preloaded library which affects > postgresql's optimizer (online_analyze if somebody is interesting). It works > well except executing make installcheck of other modules, for example > btree_gist: If you're fooling with the opt

Re: [HACKERS] make installcheck.

Teodor Sigaev writes: > Is there any way to unload that library for test or, at least, execute set > statement (set online_analyze.enable = off, actually) on test database > before > test run? BTW, so far as that goes, make installcheck should honor PGOPTIONS, so you should be able to pass in

[HACKERS] make installcheck.

Hi! On production instance I have an installed preloaded library which affects postgresql's optimizer (online_analyze if somebody is interesting). It works well except executing make installcheck of other modules, for example btree_gist: test numeric ... ok test not_equal

Re: [HACKERS] superuser() shortcuts

* Andres Freund (and...@2ndquadrant.com) wrote: > I still think this change makes the error message more verbose, without > any win in clarity. Can we agree that there should be consistency? I'm not really particular about which way we go with the specific wording (suggestions welcome..) but the

Re: [HACKERS] Functions used in index definitions shouldn't be changed

Albe Laurenz writes: > There is also the possibility to add syntax like this: > CREATE OR REPLACE [FORCE] FUNCTION ... > What do you think about that? It would protect the casual user but allow > the expert to do it anyway. I don't see any great attraction to that. regar

Re: [HACKERS] RLS with check option - surprised design

* Peter Geoghegan (p...@heroku.com) wrote: > On Sun, Oct 5, 2014 at 5:16 AM, Stephen Frost wrote: > >> next a message: > >> > >> ERROR: new row violates WITH CHECK OPTION for "data" > >> DETAIL: Failing row contains (2014-10-05 12:28:30.79652, petr, 1000). > >> > >> Doesn't inform about broken p

Re: [HACKERS] tracking commit timestamps

On 21/11/14 00:17, Petr Jelinek wrote: On 19/11/14 17:30, Steve Singer wrote: On 11/19/2014 08:22 AM, Alvaro Herrera wrote: I think we're overblowing the pg_upgrade issue. Surely we don't need to preserve commit_ts data when upgrading across major versions; and pg_upgrade is perfectly prepare

Re: [HACKERS] What exactly is our CRC algorithm?

On Fri, Nov 21, 2014 at 03:41:45PM +0530, Abhijit Menon-Sen wrote: > At 2014-11-20 13:47:00 +0530, a...@2ndquadrant.com wrote: > > > > > Suggestions for how to address (b) are welcome. > > With help from Andres, I set up a workload where XLogInsert* was at the > top of my profiles: server with fsy

Re: [HACKERS] group locking: incomplete patch, just for discussion

On Thu, Nov 20, 2014 at 8:31 PM, Andres Freund wrote: >> I can't follow that logic. Why do you think self-exclusive locks are >> the only ones that matter? > > All the others can be acquired by jumping in front of the lock's > waitqueue? That's is true, as a practical matter, in many cases. But

Re: [HACKERS] WAL format and API changes (9.5)

On 11/21/2014 05:58 AM, Amit Kapila wrote: On Thu, Nov 20, 2014 at 10:36 PM, Heikki Linnakangas < hlinnakan...@vmware.com> wrote: As you may have noticed, I committed this (after some more cleanup). Of course, feel free to still review it, and please point out any issues you may find. Few

Re: [HACKERS] Comment header for src/test/regress/regress.c

On 11/21/2014 06:23 AM, Ian Barwick wrote: I thought it might be useful to add a few words at the top of 'src/test/regress/regress.c' to explain what it does and to help differentiate it from 'pg_regress.c' and 'pg_regress_main.c'. Makes sense, committed. I remember being a bit confused on that

Re: [HACKERS] What exactly is our CRC algorithm?

On Fri, Nov 21, 2014 at 12:11 PM, Abhijit Menon-Sen wrote: > If anyone has other suggestions, I'm all ears. Do you have a WIP patch I could take a look at and tweak? Maybe there's something about the compilers code generation that could be improved. Regards, Ants Aasma -- Cybertec Schönig & Sc

Re: [HACKERS] What exactly is our CRC algorithm?

On 11/21/2014 01:06 PM, Andres Freund wrote: On 2014-11-21 13:01:50 +0200, Heikki Linnakangas wrote: On 11/21/2014 12:11 PM, Abhijit Menon-Sen wrote: At 2014-11-20 13:47:00 +0530, a...@2ndquadrant.com wrote: Suggestions for how to address (b) are welcome. With help from Andres, I set up a

Re: [HACKERS] What exactly is our CRC algorithm?

On 2014-11-21 13:01:50 +0200, Heikki Linnakangas wrote: > On 11/21/2014 12:11 PM, Abhijit Menon-Sen wrote: > >At 2014-11-20 13:47:00 +0530, a...@2ndquadrant.com wrote: > >> > >>>Suggestions for how to address (b) are welcome. > > > >With help from Andres, I set up a workload where XLogInsert* was a

Re: [HACKERS] What exactly is our CRC algorithm?

On 11/21/2014 12:11 PM, Abhijit Menon-Sen wrote: At 2014-11-20 13:47:00 +0530, a...@2ndquadrant.com wrote: Suggestions for how to address (b) are welcome. With help from Andres, I set up a workload where XLogInsert* was at the top of my profiles: server with fsync and synchronous_commit off,

Re: [HACKERS] WAL format and API changes (9.5)

On 11/21/2014 09:19 AM, Michael Paquier wrote: On Fri, Nov 21, 2014 at 2:06 AM, Heikki Linnakangas wrote: As you may have noticed, I committed this (after some more cleanup). Of course, feel free to still review it, and please point out any issues you may find. This comment on top of XLogR

Re: [HACKERS] What exactly is our CRC algorithm?

At 2014-11-20 13:47:00 +0530, a...@2ndquadrant.com wrote: > > > Suggestions for how to address (b) are welcome. With help from Andres, I set up a workload where XLogInsert* was at the top of my profiles: server with fsync and synchronous_commit off, and pgbench running a multiple-row insert into a

Re: [HACKERS] GIN pageinspect functions

On 11/20/2014 05:52 AM, Michael Paquier wrote: On Wed, Nov 19, 2014 at 7:01 AM, Peter Geoghegan wrote: On Tue, Nov 4, 2014 at 7:26 AM, Amit Kapila wrote: 1. Documentation seems to be missing, other API's exposed via pageinspect are documented at: http://www.postgresql.org/docs/devel/static/pag

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

Dag-Erling Smørgrav writes: > Alex Shulgin writes: >> I can do that too, just need a hint where to look at in libpq/psql to >> add the option. > > The place to *enforce* the option is src/interfaces/libpq/fe-secure.c > (look for SSLv23_method() and SSL_CTX_set_options()). I haven't looked > in

Re: [HACKERS] Functions used in index definitions shouldn't be changed

Robert Haas wrote: > On Thu, Nov 20, 2014 at 1:56 PM, Albe Laurenz wrote: > > I don't think that there is a universally compelling right or wrong to > > questions like this, it is more a matter of taste. Is it more important to > > protect > > the casual DBA from hurting himself or herself, or i

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

Alex Shulgin writes: > I can do that too, just need a hint where to look at in libpq/psql to > add the option. The place to *enforce* the option is src/interfaces/libpq/fe-secure.c (look for SSLv23_method() and SSL_CTX_set_options()). I haven't looked into how to set it. DES -- Dag-Erling Smør

[HACKERS] Automatic PG_PRINTF_ATTRIBUTE

pg_config_manual.h has been choosing gnu_printf as the PG_PRINTF_ATTRIBUTE for every MinGW build. That invites a torrent of warnings on pre-gcc-4.4 MinGW compilers, including the compiler on buildfarm member narwhal. I'm increasingly using an affected compiler, because it builds twice as quickly