On 08/20/2013 02:03 AM, Josh Berkus wrote:
On 08/19/2013 09:23 AM, Boszormenyi Zoltan wrote:
Indeed, it's a big nail in the coffin for SRFs-in-targetlist. Having
WITH ORDINALITY and this feature, I would vote for removing
SRF-in-targetlist and call the release PostgreSQL 10.0.
That's not
On Mon, Aug 19, 2013 at 07:45:23PM +0200, Pavel Stehule wrote:
Hello
Harder maybe but it may still be cleaner in the long run.
Overall, it's my intention here to remove as many as feasible of the old
reasons why one might use an SRF in the select list.
Indeed, it's a big nail in
2013/8/20 David Fetter da...@fetter.org
On Mon, Aug 19, 2013 at 07:45:23PM +0200, Pavel Stehule wrote:
Hello
Harder maybe but it may still be cleaner in the long run.
Overall, it's my intention here to remove as many as feasible of the
old
reasons why one might use an SRF in the
2013-08-20 08:13 keltezéssel, Pavel Stehule írta:
2013/8/20 David Fetter da...@fetter.org mailto:da...@fetter.org
On Mon, Aug 19, 2013 at 07:45:23PM +0200, Pavel Stehule wrote:
Hello
Harder maybe but it may still be cleaner in the long run.
Overall, it's my
On 19.08.2013 23:40, Christophe Pettus wrote:
Is it reasonable to note in the documentation that ereport does not return if
the error severity is greater than or equal to ERROR?
Yeah, it probably would be good to mention that. Got a patch?
- Heikki
--
Sent via pgsql-hackers mailing list
On 19.08.2013 21:15, Boszormenyi Zoltan wrote:
2013-08-19 19:20 keltezéssel, Andres Freund írta:
Based on a quick look it seems like you're throttling on the receiving
side. Is that a good idea? Especially over longer latency links, TCP
buffering will reduce the effect on the sender side
2013-08-20 08:37 keltezéssel, Heikki Linnakangas írta:
On 19.08.2013 21:15, Boszormenyi Zoltan wrote:
2013-08-19 19:20 keltezéssel, Andres Freund írta:
Based on a quick look it seems like you're throttling on the receiving
side. Is that a good idea? Especially over longer latency links, TCP
On 20/08/13 15:26, Tom Lane wrote:
I will be taking a long (and long-overdue) vacation from Sep 10 to Oct 20.
I expect to have email access, but won't be doing much more than minimally
keeping up with my inbox.
This means I'll be pretty much AWOL for the September commitfest :-(.
That's
On 2013-08-19 15:17:44 -0700, Jeff Janes wrote:
On Wed, Aug 7, 2013 at 7:40 AM, Merlin Moncure mmonc...@gmail.com wrote:
I agree; at least then it's not unambiguously better. if you (in
effect) swap all contention on allocation from a lwlock to a spinlock
it's not clear if you're
Hello
we support syntax for INSERT and DELETE statements, that allows a simple
triggers for these statements.
CREATE FUNCTION trg_insert()
RETURNS trigger AS $$
BEGIN
INSERT INTO target_tbl VALUES(NEW.*)
RETURN NULL;
END;
$$ LANGUAGE plpgsql;
* is not allowed in DELETE, but we can use a
You're linking against a pre-9.0 copy of libpq.so.
Thanks for help :)
I got my mistake .
Regards,
Amul Sul
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/undefined-symbol-PQescapeLiteral-tp5767578p5767994.html
Sent from the PostgreSQL - hackers mailing list
Hi all,
Taking a look at PostgreSQL HEAD today, I noticed that currently
PostgreSQL allows of value as bool type value.
So user can execute the following SQL.
=# SET enbale_seqscan TO of;
And I read the source code related to parsing bool value.
It compare TWO characters off and the setting
Hi,
2013-08-04 15:20 keltezéssel, Dimitri Fontaine írta:
Thom Brown t...@linux.com writes:
Could you please resubmit this without using SnapshotNow as it's no longer
supported?
Sure, sorry that I missed that, please find v12 attached.
Here's a review for this patch.
* Is the patch in a
Hackers,
This seems reasonable:
david=# DO $$
david$# BEGIN
david$# WITH now AS (SELECT now())
david$# SELECT * from now;
david$# END;
david$# $$;
ERROR: query has no destination for result data
HINT: If you want to discard the results of a SELECT, use
Hello
2013/8/20 David E. Wheeler da...@justatheory.com
Hackers,
This seems reasonable:
david=# DO $$
david$# BEGIN
david$# WITH now AS (SELECT now())
david$# SELECT * from now;
david$# END;
david$# $$;
ERROR: query has no destination for result
Hi Pavel,
On Aug 20, 2013, at 2:11 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
david=# DO $$
david$# BEGIN
david$# WITH now AS (SELECT now())
david$# PERFORM * from now;
david$# END;
david$# $$;
ERROR: syntax error at or near PERFORM
LINE 4:
2013/8/20 David E. Wheeler da...@justatheory.com
Hi Pavel,
On Aug 20, 2013, at 2:11 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
david=# DO $$
david$# BEGIN
david$# WITH now AS (SELECT now())
david$# PERFORM * from now;
david$# END;
david$# $$;
On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote:
Hi Pavel,
On Aug 20, 2013, at 2:11 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
david=# DO $$
david$# BEGIN
david$# WITH now AS (SELECT now())
david$# PERFORM * from now;
david$# END;
On 8/20/13 2:21 PM, Pavel Stehule wrote:
2013/8/20 David E. Wheeler da...@justatheory.com
Well, there ought to be *some* way to tell PL/pgSQL to discard the result.
Right now I am adding a variable to select into but never otherwise use.
Inelegant, IMHO. Perhaps I’m missing some other way to do
2013/8/20 Andres Freund and...@2ndquadrant.com
On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote:
Hi Pavel,
On Aug 20, 2013, at 2:11 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
david=# DO $$
david$# BEGIN
david$# WITH now AS (SELECT now())
david$#
On Aug 20, 2013, at 2:24 PM, Marko Tiikkaja ma...@joh.to wrote:
postgres=# DO $$
BEGIN
PERFORM * FROM (WITH now AS (SELECT now())
SELECT * from now) x;
END;
$$;
DO
.. which doesn't work if you want to use table-modifying CTEs.
Which, in fact, is exactly my use case (though not
2013/8/20 David E. Wheeler da...@justatheory.com
On Aug 20, 2013, at 2:24 PM, Marko Tiikkaja ma...@joh.to wrote:
postgres=# DO $$
BEGIN
PERFORM * FROM (WITH now AS (SELECT now())
SELECT * from now) x;
END;
$$;
DO
.. which doesn't work if you want to use table-modifying
On Aug 20, 2013, at 2:31 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
but it works
postgres=# do $$begin with x as (select 10) insert into omega select * from
x; end;$$;
DO
But this does not:
david=# DO $$
david$# BEGIN
david$# PERFORM * FROM (
david$# WITH inserted AS (
2013/8/20 David E. Wheeler da...@justatheory.com
On Aug 20, 2013, at 2:31 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
but it works
postgres=# do $$begin with x as (select 10) insert into omega select *
from x; end;$$;
DO
But this does not:
david=# DO $$
david$# BEGIN
On Tue, Aug 20, 2013 at 7:25 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote:
Hi Pavel,
On Aug 20, 2013, at 2:11 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
david=# DO $$
david$# BEGIN
david$# WITH now AS (SELECT
2013/8/20 Merlin Moncure mmonc...@gmail.com
On Tue, Aug 20, 2013 at 7:25 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote:
Hi Pavel,
On Aug 20, 2013, at 2:11 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
david=# DO $$
On Aug 20, 2013, at 2:41 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
yes, in this context you should not use a PERFORM
PL/pgSQL protect you before useless queries - so you can use a CTE without
returned result directly or CTE with result via PERFORM statement (and in
this case it
2013-08-20 14:35 keltezéssel, David E. Wheeler írta:
On Aug 20, 2013, at 2:31 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
but it works
postgres=# do $$begin with x as (select 10) insert into omega select * from x;
end;$$;
DO
But this does not:
david=# DO $$
david$# BEGIN
david$#
On Aug 20, 2013, at 2:44 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I think the way forward is to remove the restriction such that data
returning queries must be PERFORM'd
I disagree, current rule has sense.
Perhaps a DECLARE FUNCTION attribute that turns off the functionality, then?
On Tue, Aug 20, 2013 at 7:44 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/8/20 Merlin Moncure mmonc...@gmail.com
On Tue, Aug 20, 2013 at 7:25 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote:
Hi Pavel,
On Aug 20, 2013, at
* Amit Kapila (amit.kapil...@gmail.com) wrote:
Okay, let us decide how things will be if we disable by default:
1. initdb won't create any empty auto file, rather the file will be
created first time user uses ALTER SYSTEM.
I'm not particularly set on this.. Why not create the file
2013/8/20 David E. Wheeler da...@justatheory.com
On Aug 20, 2013, at 2:41 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
yes, in this context you should not use a PERFORM
PL/pgSQL protect you before useless queries - so you can use a CTE
without returned result directly or CTE with
On 8/20/13 2:53 PM, Pavel Stehule wrote:
2013/8/20 David E. Wheeler da...@justatheory.com
I am passing the values returned from a CTE to a call to pg_notify(). I do
not care to collect the output of pg_notify(), which returns VOID.
it is little bit different issue - PL/pgSQL doesn't check if
On Aug 20, 2013, at 2:53 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I am passing the values returned from a CTE to a call to pg_notify(). I do
not care to collect the output of pg_notify(), which returns VOID.
it is little bit different issue - PL/pgSQL doesn't check if returned type
2013/8/20 David E. Wheeler da...@justatheory.com
On Aug 20, 2013, at 2:53 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I am passing the values returned from a CTE to a call to pg_notify(). I
do not care to collect the output of pg_notify(), which returns VOID.
it is little bit
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Amit Kapila escribió:
3. postgresql.conf will contain include directive in below form:
#include = 'postgresql.auto.conf'
Whenever user wants to use Alter System, he needs to enable it
after first time using ALTER SYSTEM.
On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
Okay, let us decide how things will be if we disable by default:
1. initdb won't create any empty auto file, rather the file will be
created first time user uses ALTER
On Aug 20, 2013, at 3:05 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
When you would to ignore result, then you should to use a PERFORM - actually,
it is limited now and should be fixed. Have no problem with it.
Glad to have you on board. :-)
I don't would to enable a free unbound
2013/8/20 David E. Wheeler da...@justatheory.com
On Aug 20, 2013, at 3:05 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
When you would to ignore result, then you should to use a PERFORM -
actually, it is limited now and should be fixed. Have no problem with it.
Glad to have you on
* Amit Kapila (amit.kapil...@gmail.com) wrote:
On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost sfr...@snowman.net wrote:
I'm not particularly set on this.. Why not create the file initially?
If by default this feature needs to be disabled, then it is not
must to have at initdb time.
I
On Aug 20, 2013, at 3:18 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
can you show some examples, please
This is not dissimilar to what I am actually doing:
CREATE TABLE foo (id SERIAL PRIMARY KEY, name TEXT);
CREATE OR REPLACE FUNCTION shipit (
VARIADIC things TEXT[]
Hi,
2013-08-19 21:52 keltezéssel, Boszormenyi Zoltan írta:
2013-08-19 21:21 keltezéssel, Karol Trzcionka írta:
W dniu 19.08.2013 19:56, Boszormenyi Zoltan pisze:
* Does it apply cleanly to the current git master?
No. There's a reject in src/backend/optimizer/plan/initsplan.c
Thank you,
2013/8/20 David E. Wheeler da...@justatheory.com
On Aug 20, 2013, at 3:18 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
can you show some examples, please
This is not dissimilar to what I am actually doing:
CREATE TABLE foo (id SERIAL PRIMARY KEY, name TEXT);
CREATE OR
On 08/19/2013 11:36 PM, Michael Cronenworth wrote:
On 08/19/2013 07:35 PM, Noah Misch wrote:
That was option #1. (You weren't planning to change just the one symbol
causing the failure at hand, were you?) Reasonable choice. The
point in the
code comment quoted above looks bad, but the lack
On Aug 20, 2013, at 3:38 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
pg_notify returns void, so there are no necessary casting to void
so enhanced check - so all returned columns are void should be enough
What if I call another function I wrote myself that returns an INT, but I do
not
2013/8/20 David E. Wheeler da...@justatheory.com
On Aug 20, 2013, at 3:38 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
pg_notify returns void, so there are no necessary casting to void
so enhanced check - so all returned columns are void should be enough
What if I call another
On Tue, Aug 20, 2013 at 6:55 PM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost sfr...@snowman.net wrote:
I'm not particularly set on this.. Why not create the file initially?
If by default this feature
* Amit Kapila (amit.kapil...@gmail.com) wrote:
Wouldn't it be complicated to handle this way rather then by having
include directive.
You misunderstood. I was suggesting a setup along these lines:
postgresql.conf:
# include = 'auto.conf' # Disabled by default
auto.conf:
On Tue, Aug 20, 2013 at 7:51 PM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
Wouldn't it be complicated to handle this way rather then by having
include directive.
You misunderstood. I was suggesting a setup along these lines:
postgresql.conf:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
So let me try to explain what I understood from above:
1. enable_alter_system a new GUC whose default value =off.
2. Alter System will check this variable and return error (not
allowed), if this parameter is off.
3. Now if user enables include
Thank you for the review and tests. New version introduce a lot of
improvements:
- Fix regression test for view (wrong table_name)
- Add regression test for inheritance
- Delete hack in initsplan.c (now we ignore all RTE_BEFORE) - the
uninitialized issue
- Revert changing varno in
On Tue, Aug 20, 2013 at 1:11 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
Hi all,
Taking a look at PostgreSQL HEAD today, I noticed that currently
PostgreSQL allows of value as bool type value.
So user can execute the following SQL.
=# SET enbale_seqscan TO of;
And I read the source
Stephen Frost escribió:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Hopefully snippets put in conf.d/ by
puppet/chef will override the settings in postgresql.conf (i.e. conf.d/
should be processed after postgresql.conf, not before); and hopefully
ALTER SYSTEM will in turn override
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
With includedir and include directives, and postgresql.conf setting a
defined ordering, with last-wins, you could simply have the 'includedir'
for conf.d come before the 'include' for auto.conf.
Uh, I was thinking
Stephen Frost escribió:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
So let me try to explain what I understood from above:
1. enable_alter_system a new GUC whose default value =off.
2. Alter System will check this variable and return error (not
allowed), if this parameter is off.
On Tue, Aug 20, 2013 at 11:53 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Tue, Aug 20, 2013 at 1:11 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
Hi all,
Taking a look at PostgreSQL HEAD today, I noticed that currently
PostgreSQL allows of value as bool type value.
So user can
Stephen Frost escribió:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
With includedir and include directives, and postgresql.conf setting a
defined ordering, with last-wins, you could simply have the 'includedir'
for conf.d come before the 'include' for
Alvaro Herrera alvhe...@2ndquadrant.com writes:
What I was proposing upthread is that enable_alter_system=off/on would
be present in postgresql.conf, and there is no include line for
auto.conf. That way, if the user wishes to enable/disable the feature,
they need to edit postgresql.conf to do
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
With this design, if you put enable_alter_system=off in auto.conf, there
is no way for the user to enable alter system again short of editing a
file in the data directory. I think this is one of the things that was
forbidden by policy; only
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
With includedir and include directives, and postgresql.conf setting a
defined ordering, with last-wins, you could simply have the
Stephen Frost sfr...@snowman.net writes:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
The conf.d/ path would be relative to postgresql.conf, so there's no
need for Debian to patch anything.
Uhhh, I really don't see that working, at all...
Why not? conf.d is for installable files,
W dniu 20.08.2013 16:47, Karol Trzcionka pisze:
Thank you for the review and tests. New version introduce a lot of
improvements:
- Fix regression test for view (wrong table_name)
- Add regression test for inheritance
- Delete hack in initsplan.c (now we ignore all RTE_BEFORE) - the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
The conf.d/ path would be relative to postgresql.conf, so there's no
need for Debian to patch anything.
Uhhh, I really don't see that working, at all...
Stephen Frost escribió:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
I'd much rather have an includedir directive than some hard-coded or
command-line option to read the directory.. The directory should live
in /etc/postgresql/X.Y/cluster/ on at least
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
I'd much rather have an includedir directive than some hard-coded or
command-line option to read the directory.. The directory
Stephen Frost escribió:
I agree that auto.conf should live in $PGDATA, but I really don't like
the idea of conf.d being relative to some other existing file. It
should be included through an 'includedir' option, not just picked up as
some magic directory name, and therefore consider the
Stephen Frost escribió:
Tried to in my other mail,
Yep, got it and replied, thanks.
but let me also point out that we
(PGDG/Upstream) don't own the directory in which postgresql.conf
lives. At least on Debian and relatives, that directory isn't under
$PGDATA and it already has other files
Hackers,
I am trying to do something like this:
CREATE TYPE source AS ENUM(
'fred', 'wilma', 'barney', 'betty'
);
CREATE EXTENSION btree_gist;
CREATE TABLE things (
source source NOT NULL,
within tstzrange NOT NULL,
EXCLUDE USING gist (source
On Aug 19, 2013, at 11:28 PM, Heikki Linnakangas wrote:
On 19.08.2013 23:40, Christophe Pettus wrote:
Is it reasonable to note in the documentation that ereport does not return
if the error severity is greater than or equal to ERROR?
Yeah, it probably would be good to mention that. Got a
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Well, all the relative paths in include/includedir directives would be
relative to the directory specified by the -c config_file param, which
makes perfect sense. So the conf.d would work fine in your example.
Why would include/includedir
Hello!
From time to time when investigating different locking issues using
postgres log i have thought that process x is still waiting for
message could be more informative, for example at the moment it is quite
painful to find out which session was actually holding that particular lock.
I
On 08/19/2013 11:55 PM, Gavin Flower wrote:
On 20/08/13 15:26, Tom Lane wrote:
I will be taking a long (and long-overdue) vacation...
but, But, BUT, you're not human - you can't possibly take leave, the
sky will fall all manners of divers calamities will come to pass!!!
As if on cue:
Stephen Frost escribió:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Well, all the relative paths in include/includedir directives would be
relative to the directory specified by the -c config_file param, which
makes perfect sense. So the conf.d would work fine in your example.
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Stephen Frost escribió:
While I really like the 'include auto.conf' style, I'm starting to think
it may not be workable after all. Another thing to consider is if the
user decides to change that include line.. What happens when the DBA
tries
On Tue, Aug 20, 2013 at 2:55 AM, Gavin Flower
gavinflo...@archidevsys.co.nz wrote:
On 20/08/13 15:26, Tom Lane wrote:
I will be taking a long (and long-overdue) vacation from Sep 10 to Oct 20.
I expect to have email access, but won't be doing much more than minimally
keeping up with my inbox.
David E. Wheeler da...@justatheory.com writes:
Well, maybe I can cast it? But no, changing the EXCLUDE line to
EXCLUDE USING gist (source::text WITH =, within WITH )
Yields a syntax error:
try.sql:13: ERROR: syntax error at or near ::
LINE 4: EXCLUDE USING gist
On Aug 20, 2013, at 6:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You need more parentheses -- (source::text) would've worked.
Alas, no, same problem as for CAST():
ERROR: functions in index expression must be marked IMMUTABLE
No problem, I can use CAST(), right? So I try:
EXCLUDE
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
Of course, the current situation is quite terrible anyway, imv. Having
the GUCs be relative to whereever the user happens to run pg_ctl from is
pretty ugly- not to mention that the commented out 'defaults' won't
Tarvi Pillessaar tar...@gmail.com wrote:
Maybe someone can take a look at my patch and give some feedback.
Even if this idea won't reach to upstream, i would still like to get
feedback.
Please add the patch to the open CommitFest.
You can read about the process here:
Stephen Frost escribió:
And what about
http://www.postgresql.org/docs/9.3/static/runtime-config-file-locations.html
... ?
When setting any of these parameters, a relative path will be
interpreted with respect to the directory in which postgres is
started.
That's talking
2013-08-20 17:30 keltezéssel, Karol Trzcionka írta:
W dniu 20.08.2013 16:47, Karol Trzcionka pisze:
Thank you for the review and tests. New version introduce a lot of
improvements:
- Fix regression test for view (wrong table_name)
- Add regression test for inheritance
- Delete hack in
W dniu 20.08.2013 20:55, Boszormenyi Zoltan pisze:
Here's a new one, for v7:
setrefs.c: In function ‘set_plan_refs’:
setrefs.c:2001:26: warning: ‘before_index’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
bind_returning_variables(rlist, before_index, after_index);
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost escribió:
http://www.postgresql.org/docs/9.3/static/runtime-config-file-locations.html
That's talking about the data_directory and the various foo_file
settings, though; it doesn't apply to the include settings.
Right-
On Tue, Aug 20, 2013 at 11:23:06AM -0400, Stephen Frost wrote:
What I was proposing upthread is that enable_alter_system=off/on would
be present in postgresql.conf, and there is no include line for
auto.conf.
I really think that's a terrible approach, to be honest. I want to see
an
In a thread over in pgsql-performance, Tomas Vondra pointed out that
choose_hashed_distinct was sometimes making different choices than
choose_hashed_grouping, so that queries like these:
select distinct x from ... ;
select x from ... group by 1;
might get different plans even
Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-08-19 14:28:28 -0400, Tom Lane wrote:
One possibility is to do the initial check somewhere shortly after
ChangeToDataDir(), and have the GUC check hook only attempt to make a
check in SIGHUP context. Unfortunately we
On Mon, Aug 19, 2013 at 09:27:57PM -0400, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
I vote for adapting the patch to additionally zero out the file via
write(). In your tests that seemed to perform at least as good as the
old method... It also has the advantage
On Tue, Aug 20, 2013 at 08:38:52AM +0530, Amit Kapila wrote:
On Tue, Aug 20, 2013 at 8:27 AM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
If both are okay, then I would like to go with second option (include
file mechanism).
I think by default,
On Wed, Aug 21, 2013 at 2:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
What I'm wondering is whether to back-patch this or leave well enough
alone. The risk of back-patching is that it might destabilize plan
choices that people like. (In Tomas' original example, the underestimate
of the table
On Tue, Aug 20, 2013 at 10:02 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Stephen Frost escribió:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Well, all the relative paths in include/includedir directives would be
relative to the directory specified by the -c config_file param,
On Wed, Aug 21, 2013 at 7:29 AM, Bruce Momjian br...@momjian.us wrote:
On Tue, Aug 20, 2013 at 08:38:52AM +0530, Amit Kapila wrote:
On Tue, Aug 20, 2013 at 8:27 AM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
If both are okay, then I would like to
91 matches
Mail list logo
