[GENERAL] pg_stat_replication in 9.3

[Torsten Förtsch]

Hi,

I noticed a strange behaviour regarding pg_stat_replication in 9.3. If
called from psql using the \watch command, I see all my replicas. From
time to time one of them drops out and reconnects in a short period of
time, typically ~30 sec.

If I use the same select in plpgsql like:

  FOR r in SELECT application_name,
  client_addr,
  flush_location, clock_timestamp() AS lmd
 FROM pg_stat_replication
ORDER BY application_name, client_addr
  LOOP
RAISE NOTICE 'aname=%, ca=%, lmd=%, loc=%, cur=%, lag=%',
 r.application_name, r.client_addr, r.lmd,
 r.flush_location,
 pg_current_xlog_location(),
 pg_size_pretty(
   pg_xlog_location_diff(
 pg_current_xlog_location(),
 r.flush_location
   )
 );
  END LOOP;

I see one of the replicas dropping out but never coming back again while
in a parallel session using psql and \watch it indeed does come back.

Is that intended?

Torsten


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] 2 left joins causes seqscan

[Kevin Grittner]

Willy-Bas Loos  wrote:

> I can't understand what is confusing the planner.

Well, it doesn't do exhaustive proofs of whether two queries are
equivalent.  If it did, it would still not have come up with a plan
like your second one, because it is not equivalent.  The trick in
planning is to stop when the cost of further analysis is likely to
exceed the benefits derived from a better plan.  The fact that the
first query was complex enough that *you* weren't able to
accurately optimize it better before posting is pretty good
evidence that it's moving into the realm of "expensive to
optimize".

Now, if you want to propose some specific check the planner can
make to try to find a plan like the one generated for the query I
showed (which I believe actually *is* equivalent to your first
query), perhaps someone will find implementing that a better use of
their time than any of the other things they have in front of them
to work on, and benchmarks can establish what the planning cost of
that is for people running queries it *won't* benefit compared to
the benefits seen in queries that *do* benefit.  There is an
understandable reluctance to add planning costs to every query run
in order to cause better plan choice for a very small percentage of
queries, especially when there is a workaround -- of explicitly
writing a UNION for those cases.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] 2 left joins causes seqscan

[Tom Lane]

Kevin Grittner  writes:
> Willy-Bas Loos  wrote:
>> I can't understand what is confusing the planner.

> Well, it doesn't do exhaustive proofs of whether two queries are
> equivalent.  If it did, it would still not have come up with a plan
> like your second one, because it is not equivalent.

Yeah.  The short reason why the index was not used in the original
query is that the supposedly indexable condition was inside an OR,
which made it useless as an index qualification: rows not satisfying
that condition at all might yet satisfy the query as a whole.  The
planner does have some ability to use indexes when every arm of the
OR includes an indexable condition on the same table, but that was
not the case here.

Another point about the proposed transformation is that an OR in
WHERE is far from equivalent to a UNION: WHERE ... OR does not result
in full de-duplication.  You could possibly conclude they were
equivalent if the query output columns included a primary key,
but that was not the case here.  In any case, the planner includes
no logic that could transform OR into UNION, and I'd be pretty
hesitant to add any even if the transformation were formally correct,
because the planner has no ability to optimize UNION meaningfully.
You'd often get a worse plan than you get now.  (Perhaps that will
change someday, but it's not very high on the priority list.)

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] pg_stat_replication in 9.3

[Andy Colson]

On 09/14/2014 07:03 AM, Torsten Förtsch wrote:

Hi,

I noticed a strange behaviour regarding pg_stat_replication in 9.3. If
called from psql using the \watch command, I see all my replicas. From
time to time one of them drops out and reconnects in a short period of
time, typically ~30 sec.

If I use the same select in plpgsql like:

   FOR r in SELECT application_name,
   client_addr,
   flush_location, clock_timestamp() AS lmd
  FROM pg_stat_replication
 ORDER BY application_name, client_addr
   LOOP
 RAISE NOTICE 'aname=%, ca=%, lmd=%, loc=%, cur=%, lag=%',
  r.application_name, r.client_addr, r.lmd,
  r.flush_location,
  pg_current_xlog_location(),
  pg_size_pretty(
pg_xlog_location_diff(
  pg_current_xlog_location(),
  r.flush_location
)
  );
   END LOOP;

I see one of the replicas dropping out but never coming back again while
in a parallel session using psql and \watch it indeed does come back.

Is that intended?

Torsten




I wonder if its a transaction thing?  Maybe \watch is using a transaction for 
each (or isn't using transactions at all), whereas the plpgsql is one long 
transaction?

Also if one of your replicas is far away, it doesn't really surprise me that it 
might loose connection every once and a while.  On the other hand, if the box 
is on the same subnet, right next to the master, and it was loosing connection, 
that would be a bad thing.

So, how far away is the replica?  And does 'ps ax|grep postgr' show 'idle' or 
'idle in transaction' on the \watch and the plpgsql?

-Andy




--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] pg_stat_replication in 9.3

[Torsten Förtsch]

On 14/09/14 16:24, Andy Colson wrote:
> I wonder if its a transaction thing?  Maybe \watch is using a
> transaction for each (or isn't using transactions at all), whereas the
> plpgsql is one long transaction?
> 
> Also if one of your replicas is far away, it doesn't really surprise me
> that it might loose connection every once and a while.  On the other
> hand, if the box is on the same subnet, right next to the master, and it
> was loosing connection, that would be a bad thing.
> 
> So, how far away is the replica?  And does 'ps ax|grep postgr' show
> 'idle' or 'idle in transaction' on the \watch and the plpgsql?

The replicas are far away, intercontinental far. I am not complaining
that the replica looses the connection. What makes me wonder is that
within a transaction, pg_stat_replication can forget rows but cannot
acquire new ones. I'd think it should be either report the state at the
beginning of the transaction like now() or the current state like
clock_timestamp(). But currently it's reporting half the current state.

Torsten


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] pg_stat_replication in 9.3

[Tom Lane]

=?UTF-8?B?VG9yc3RlbiBGw7ZydHNjaA==?=  writes:
> The replicas are far away, intercontinental far. I am not complaining
> that the replica looses the connection. What makes me wonder is that
> within a transaction, pg_stat_replication can forget rows but cannot
> acquire new ones. I'd think it should be either report the state at the
> beginning of the transaction like now() or the current state like
> clock_timestamp(). But currently it's reporting half the current state.

Are you watching the state in a loop inside a single plpgsql function?
If so, I wonder whether the problem is that the plpgsql function's
snapshot isn't changing.  From memory, marking the function VOLATILE
would help if that's the issue.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] pg_stat_replication in 9.3

[Torsten Förtsch]

On 14/09/14 18:55, Tom Lane wrote:
> Are you watching the state in a loop inside a single plpgsql function?
> If so, I wonder whether the problem is that the plpgsql function's
> snapshot isn't changing.  From memory, marking the function VOLATILE
> would help if that's the issue.

The function is VOLATILE. I attached 2 versions of it. fn-old.sql does
not work because once a slave has disconnected it drops out and does not
come back. fn.sql uses dblink to work around the problem. But it
consumes 2 db connections.

The intent of the function is to be called between operations that may
cause slaves to lag behind. If the lag is below a certain limit, it
simply returns. Otherwise, it waits until the lag drops below a second
limit.

If it were a VOLATILE problem, the functions would not be able to see
when a slave drops out nor changes in the data. But it does see these
changes. Only when a slave comes back online, it is not seen in the
current transaction.

Torsten
CREATE OR REPLACE FUNCTION wait_for_streaming_lag(low_water_mark BIGINT DEFAULT 100, high_water_mark BIGINT DEFAULT 2000, tmout INTERVAL DEFAULT '4h')
RETURNS BIGINT
AS $def$
DECLARE r  RECORD;
water_mark BIGINT;
BEGIN
SET LOCAL client_min_messages TO ERROR;
CREATE TEMP TABLE IF NOT EXISTS lag (
gen  INT,
application_name TEXT,
client_addr  INET,
flush_location   TEXT,
lmd  TIMESTAMP
);
SET LOCAL client_min_messages TO NOTICE;

water_mark := $2;   -- use high_water_mark for the first loop

LOOP
WITH g AS (SELECT max(gen) AS gen FROM lag),
 r AS (SELECT 1 AS ord, application_name, client_addr, flush_location, clock_timestamp() AS lmd
 FROM pg_stat_replication
UNION ALL
   SELECT 2 AS ord, application_name, client_addr, flush_location, lmd
 FROM lag)
INSERT INTO lag
SELECT coalesce(g.gen+1, 1), rx.*
  FROM (SELECT DISTINCT ON (application_name, client_addr)
   application_name, client_addr, flush_location, lmd
  FROM r
 ORDER BY application_name,
  client_addr,
  ord ASC,
  pg_xlog_location_diff(flush_location, '0/0') ASC) rx CROSS JOIN g;
DELETE FROM lag WHERE gen<(SELECT max(gen) FROM lag);
DELETE FROM lag WHERE lmd$3 THEN
RAISE EXCEPTION USING
MESSAGE='Timeout while waiting for streaming lag to drop below ' || $1,
ERRCODE='TF001';
END IF;

water_mark := $1;
PERFORM pg_sleep(1);
END LOOP;

RETURN r.lag;
END;
$def$ LANGUAGE plpgsql VOLATILE SECURITY invoker;
BEGIN;

CREATE OR REPLACE FUNCTION wait_for_streaming_lag(low_water_mark BIGINT DEFAULT 100, high_water_mark BIGINT DEFAULT 2000, tmout INTERVAL DEFAULT '4h')
RETURNS BIGINT
AS $def$
DECLARE r  RECORD;
water_mark BIGINT;
BEGIN
-- we need dblink here because pg_stat_replication at least in 9.3,
-- although it does report replicas dropping out, it does not report
-- replicas reconnecting if called in a transaction.
PERFORM dblink_connect('wait_for_streaming_lag', 'dbname=' || current_database() || ' application_name=wait_for_streaming_lag')
  WHERE NOT EXISTS (SELECT 1 FROM unnest(dblink_get_connections()) c(c)
 WHERE c='wait_for_streaming_lag');

SET LOCAL client_min_messages TO ERROR;
CREATE TEMP TABLE IF NOT EXISTS lag (
gen  INT,
application_name TEXT,
client_addr  INET,
flush_location   TEXT,
lmd  TIMESTAMP
);
SET LOCAL client_min_messages TO NOTICE;

water_mark := $2;   -- use high_water_mark for the first loop

LOOP
WITH g AS (SELECT max(gen) AS gen FROM lag),
 r AS (SELECT 1 AS ord, application_name, client_addr, flush_location, clock_timestamp() AS lmd
 FROM dblink('wait_for_streaming_lag', $$
  SELECT application_name, client_addr, flush_location
FROM pg_stat_replication
  $$) repl(application_name TEXT, client_addr INET, flush_location TEXT)
UNION ALL
   SELECT 2 AS ord, application_name, client_addr, flush_location, lmd
 FROM lag)
INSERT INTO lag
SELECT coalesce(g.gen+1, 1), rx.*
  FROM (SELECT DISTINCT ON (application_name, client_addr)
   application_name, client_addr, flush_location, lmd
  FROM r
 ORDER BY application_name,
  client_addr,
  ord ASC,
  pg_xlog_location_diff(flush_location, '0/0') ASC) rx CROSS JOIN g;
DELETE FROM lag WHERE

[GENERAL] Feature request: temporary schemas

[cowwoc]

Hi,

I'd like to propose the ability to create temporary schemas.

Unlike temporary tables, this feature would enable developers to create a
temporary schema once and execute CREATE TABLE statements without the
TEMPORARY parameter.

This would facilitate running unit tests, where developers would like to run
the same creation script for unit tests and production code but do not wish
to parameterize each CREATE TABLE statement (both environments are expected
to execute identical scripts). It further enables the use of temporary
functions, something which is not possible today (apparently you can hack
this too, but there isn't an "official" way of doing so).

See http://dba.stackexchange.com/q/76494/4719 for a related discussion.

Should I move this discussion to a different mailing list or is this the
correct location?

Thanks,
Gili



--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Feature-request-temporary-schemas-tp5819001.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] 2 left joins causes seqscan

[Willy-Bas Loos]

On Sun, Sep 14, 2014 at 3:23 PM, Kevin Grittner  wrote:

> The fact that the
> first query was complex enough that *you* weren't able to
> accurately optimize it better before posting is pretty good
> evidence that it's moving into the realm of "expensive to
> optimize".
>
>
Touche
BTW i don't mean any offense. I don't expect for anyone to waste their time
on cases that aren't worth the while. I just brought this up because i want
to help make the planner even more awesome. I believe that planner hints
are a bad thing, because the planner should be able to solve it
automatically. If it doesn't, users and developers should talk to each
other so that the planner (and/or knowledge how to use it) keeps improving.

On Sun, Sep 14, 2014 at 3:54 PM, Tom Lane  wrote:

> The
> planner does have some ability to use indexes when every arm of the
> OR includes an indexable condition on the same table, but that was
> not the case here.
>

It wasn't? I think that it was. I guess that this is the core of my
question.
But, in a way you are right. The planner probably sees it as a different
table, because it is a different join, even though it is the same table.
Ok, i understand now that it is probably too much to ask from the planner.
Because OR negates the effect of the qualifications in the WHERE clause and
both joins might be the same table, but that is -arguably- a corner case.
Thanks both of you.


>
> In any case, the planner includes
> no logic that could transform OR into UNION, and I'd be pretty
> hesitant to add any even if the transformation were formally correct,
> because the planner has no ability to optimize UNION meaningfully.
>

No, i didn't mean to say that the planner should do that, just that getting
the data in 2 queries (and appending with union (all)) which was faster
than the 1 query.


Cheers,
-- 
Willy-Bas Loos

Re: [GENERAL] Feature request: temporary schemas

[Nick Guenther]

On September 14, 2014 5:01:54 PM EDT, cowwoc  wrote:
>Hi,
>
>I'd like to propose the ability to create temporary schemas.
>
>This would facilitate running unit tests, where developers would like
>to run
>the same creation script for unit tests and production code but do not

What if you ran a temporary database instead? You can use some combination of 
PGHOST, PGPORT, PGUSER and PGDATABASE to "pg_ctl start" an empty DB and then 
point your unit tests at it.  Then you aren't in danger of wiping out your 
production DB either.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Feature request: temporary schemas

[cowwoc]

Hi Nick,

I don't think this would help for three reasons:

 1. I'm already planning to run unit tests against a separate (but
identical) database than production, so there's no danger of wiping
out the production database.
 2. I need to create a new temporary schema per test, and run 4-10 of
tests per second. I'm guessing this wouldn't perform well using
"pg_ctl".
 3. And finally, I'd like to configure all this through JDBC (pure
Java). "pg_ctl" would require me to interact with native code.

Gili

On 14/09/2014 5:52 PM, Nick Guenther [via PostgreSQL] wrote:
>
>
> On September 14, 2014 5:01:54 PM EDT, cowwoc <[hidden email] 
> > wrote:
> >Hi,
> >
> >I'd like to propose the ability to create temporary schemas.
> >
> >This would facilitate running unit tests, where developers would like
> >to run
> >the same creation script for unit tests and production code but do not
>
> What if you ran a temporary database instead? You can use some 
> combination of PGHOST, PGPORT, PGUSER and PGDATABASE to "pg_ctl start" 
> an empty DB and then point your unit tests at it.  Then you aren't in 
> danger of wiping out your production DB either.
>
>
> -- 
> Sent via pgsql-general mailing list ([hidden email] 
> )
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://postgresql.1045698.n5.nabble.com/Feature-request-temporary-schemas-tp5819001p5819003.html
>  
>
> To unsubscribe from Feature request: temporary schemas, click here 
> .
> NAML 
> 
>  
>





--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Feature-request-temporary-schemas-tp5819001p5819004.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

Re: [GENERAL] Feature request: temporary schemas

[Nick Guenther]

On September 14, 2014 6:01:15 PM EDT, cowwoc  wrote:
>
>On 14/09/2014 5:52 PM, Nick Guenther [via PostgreSQL] wrote:
>>
>>
>> On September 14, 2014 5:01:54 PM EDT, cowwoc <[hidden email] 
>> > wrote:
>> >Hi,
>> >
>> >I'd like to propose the ability to create temporary schemas.
>> >
>> >This would facilitate running unit tests, where developers would
>like
>> >to run
>> >the same creation script for unit tests and production code but do
>not
>>
>> What if you ran a temporary database instead? You can use some 
>> combination of PGHOST, PGPORT, PGUSER and PGDATABASE to "pg_ctl
>start" 
>> an empty DB and then point your unit tests at it.  Then you aren't in
>
>> danger of wiping out your production DB either.
>>
>>
>Hi Nick,
>
>I don't think this would help for three reasons:
>
> 1. I'm already planning to run unit tests against a separate (but
>identical) database than production, so there's no danger of wiping
>out the production database.
> 2. I need to create a new temporary schema per test, and run 4-10 of
>tests per second. I'm guessing this wouldn't perform well using
>"pg_ctl".
> 3. And finally, I'd like to configure all this through JDBC (pure
>Java). "pg_ctl" would require me to interact with native code.

Well, forget pg_ctl then.  Can you use DROP DATABASE instead?


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Feature request: temporary schemas

[Adrian Klaver]

On 09/14/2014 02:01 PM, cowwoc wrote:

Hi,

I'd like to propose the ability to create temporary schemas.

Unlike temporary tables, this feature would enable developers to create a
temporary schema once and execute CREATE TABLE statements without the
TEMPORARY parameter.

This would facilitate running unit tests, where developers would like to run
the same creation script for unit tests and production code but do not wish
to parameterize each CREATE TABLE statement (both environments are expected
to execute identical scripts). It further enables the use of temporary
functions, something which is not possible today (apparently you can hack
this too, but there isn't an "official" way of doing so).

See http://dba.stackexchange.com/q/76494/4719 for a related discussion.

Should I move this discussion to a different mailing list or is this the
correct location?


So from the above link and the discussion here so far I gather you want:

1) A CREATE TEMPORARY SCHEMA that behaves like CREATE TEMPORARY TABLE, 
where it lasts only for a session and masks any existing schema and 
contained objects with the same name for the duration.


2) You want to run this on a test database as so you can have 'masked' 
tests over the permanent schema. Presumably because the tests can be 
destructive and you do not want change the underlying structure and/or 
data in your test database.


3) This needs to happen on the order of 4-10 times a second and it needs 
to be tied to a session, as multiple transactions need to be run in each 
test.


As to whether this is the appropriate list, I would say yes at least for 
sounding out the idea. The list to address for dealing with the folks 
that actually would implement the idea I would suggest --hackers.


In the meantime, the only way I can see doing this is creating and 
dropping databases. Not sure that would meet your 4-10 times a second 
requirement though.




Thanks,
Gili





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


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Feature request: temporary schemas

[cowwoc]

Hi Adrian,

Replies below.

On 14/09/2014 8:34 PM, Adrian Klaver wrote:

On 09/14/2014 02:01 PM, cowwoc wrote:

See http://dba.stackexchange.com/q/76494/4719 for a related discussion.

So from the above link and the discussion here so far I gather you want:

1) A CREATE TEMPORARY SCHEMA that behaves like CREATE TEMPORARY TABLE, 
where it lasts only for a session and masks any existing schema and 
contained objects with the same name for the duration.


Yes. Tests should not be able to see each other's tables, data (and 
ideally not even each other's schema).


2) You want to run this on a test database as so you can have 'masked' 
tests over the permanent schema. Presumably because the tests can be 
destructive and you do not want change the underlying structure and/or 
data in your test database.


Not exactly. Each test is responsible for populating its own schema 
(creating tables, inserting data). The main purpose of using temporary 
schemas is to ensure that each test runs in isolation so that data from 
other tests cannot influence the outcome of the test. This ensures test 
execution/results are 100% reproducible.


3) This needs to happen on the order of 4-10 times a second and it 
needs to be tied to a session, as multiple transactions need to be run 
in each test.


As to whether this is the appropriate list, I would say yes at least 
for sounding out the idea. The list to address for dealing with the 
folks that actually would implement the idea I would suggest --hackers.


In the meantime, the only way I can see doing this is creating and 
dropping databases. Not sure that would meet your 4-10 times a second 
requirement though.


One of the requirements is that if someone kills the process running the 
unit tests, it can't leave behind any dangling schemas. I expect all 
test data to get dropped automatically when the connection is closed 
unexpectedly, so DROP DATABASE won't do.


Gili


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] PgToolkit 1.0.2 release testing

[Sergey Konoplev]

Hi,

The 1.0.2 release of the PgToolkit is on the way. Some significant
improvements of the tables and indexes bloat reducing tool have been
made.

Testers are very welcome. Use this link to get the testing version

https://github.com/grayhemp/pgtoolkit/branches/v1.0testing

Report bugs and suggestions either to me directly or on the issue page

https://github.com/grayhemp/pgtoolkit/issues.

List of changes:

- Fixed the non working statement timeout in the reindexing process
- Made it use `DROP INDEX CONCURRENTLY` if version is `>=9.2`
- Fixed the randomness of the SET statements order in database
  adapters
- Made it to process TOAST tables and indexes providing bloat
  information and rebuilding instructions
- Set an additional protection against the "incorrect result of
  cleaning" error

-- 
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA

http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (499) 346-7196, +7 (988) 888-1979
gray...@gmail.com


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Why isn't Java support part of Postgresql core?

[cowwoc]

Hi,

Out of curiosity, why is Postgresql's Java support so poor? I am
specifically looking for the ability to write triggers in Java.

I took a look at the PL/Java project and it looked both incomplete and dead,
yet other languages like Javascript are taking off. I would have expected to
see very strong support for Java because it's the most frequently used
language on the server-side.

What's going on? Why isn't this a core language supported alongside SQL,
Perl and Python as part of the core project?

Thanks,
Gili



--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Testing truthiness of GUC variables?

[Abelard Hoffman]

If I set a custom GUC variable to a boolean value, such as:

  SET myapp.audit = 'on';

is there a way to test it for truthiness in the same way the standard
built-in variables are? IOW, the docs say a boolean can be written as:

Boolean values can be written as on, off, true, false, yes, no, 1, 0 (all
case-insensitive) or any unambiguous prefix of these.

Re: [GENERAL] Testing truthiness of GUC variables?

[Abelard Hoffman]

On Sun, Sep 14, 2014 at 11:17 PM, Abelard Hoffman 
wrote:

> If I set a custom GUC variable to a boolean value, such as:
>
>   SET myapp.audit = 'on';
>
> is there a way to test it for truthiness in the same way the standard
> built-in variables are? IOW, the docs say a boolean can be written as:
>
> Boolean values can be written as on, off, true, false, yes, no, 1, 0 (all
> case-insensitive) or any unambiguous prefix of these.
>
>
Sorry, hit send too soon. I meant to ask, is there a built-in function I
can call, given the value from current_setting('myapp.audit'), that will
test it using the same logic?