On 01/12/2014 12:00 AM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
We don't set __declspec(dllexport) on extension functions automatically
when building stand-alone on Windows. So it's necessary to explicitly
specify PGDLLEXPORT for each function.
I'm not sure I believe
On 01/12/2014 04:54 PM, Craig Ringer wrote:
On 01/12/2014 12:00 AM, Tom Lane wrote:
So if it's really necessary to change anything here, I'd rather see us
take the approach of hiding it in PG_FUNCTION_INFO_V1. What happens
if we do that and there's also a manually-written prototype?
That's
On 01/12/2014 06:42 AM, Peter Geoghegan wrote:
Someone suggested to me that I solicit opinion on the chosen syntax of
INSERT...ON DUPLICATE KEY LOCK FOR UPDATE on a separate thread. I'll
do that here, while also giving a formal user-level definition of the
feature. I'd like to solicit feedback
On 01/09/2014 06:48 PM, Dean Rasheed wrote:
On 8 January 2014 10:19, Dean Rasheed dean.a.rash...@gmail.com wrote:
The assertion failure with inheritance and sublinks is a separate
issue --- adjust_appendrel_attrs() is not expecting to find any
unplanned sublinks in the query tree when it is
On 01/10/2014 07:41 AM, David Fetter wrote:
On Thu, Jan 09, 2014 at 04:30:25PM -0600, Jim Nasby wrote:
ISTM that allowing users to pick arbitrary lower array bounds was a
huge mistake. I've never seen anyone make use of it, can't think of
any legitimate use cases for it, and hate the
Hello
2014/1/11 Tomas Vondra t...@fuzzy.cz
Hi,
I've done a quick review of this patch:
1) patch applies fine to the current HEAD, with a few hunks offset
by a few lines
2) the compilation fails because of duplicate OIDs in pg_proc, so
I had to change 3969-3975 to 4033-4039, then
On 1/12/14, 7:47 AM, Pavel Stehule wrote:
2014/1/12 Marko Tiikkaja ma...@joh.to
Greetings fellow elephants,
I would humbly like to submit for your consideration my proposal for
alleviating pain caused by one of the most annoying footguns in PL/PgSQL:
the behaviour of SELECT .. INTO when the
On Jan12, 2014, at 08:50 , David Rowley dgrowle...@gmail.com wrote:
I've been reading the documents on numeric and I can't find any
information on the reason that a query like this:
test=# select n::numeric / 1 from generate_series(1,2) s(n);
?column?
On Sun, Jan 12, 2014 at 5:26 AM, Bruce Momjian br...@momjian.us wrote:
On Sat, Jan 11, 2014 at 12:48:51PM -0800, Adrian Klaver wrote:
pg_upgrade looks in the pg_tablespace in pre-9.2, and uses a function in
9.2+. The query is:
snprintf(query, sizeof(query),
SELECT
On Sat, Jan 11, 2014 at 9:45 PM, Peter Eisentraut pete...@gmx.net wrote:
On Thu, 2013-10-24 at 20:37 +0200, Magnus Hagander wrote:
On Thu, Oct 24, 2013 at 8:35 PM, Peter Eisentraut pete...@gmx.net
wrote:
On 10/18/12, 7:20 AM, Magnus Hagander wrote:
1. krb5 authentication. We've had
On Jan11, 2014, at 18:53 , Andres Freund and...@2ndquadrant.com wrote:
On 2014-01-11 18:28:31 +0100, Florian Pflug wrote:
Hm, I was about to suggest that you can set statement_timeout before
doing COMMIT to limit the amount of time you want to wait for the
standby to respond. Interestingly,
On 01/11/2014 11:42 PM, Peter Geoghegan wrote:
I recently suggested that rather than RETURNING REJECTS, we could have
a REJECTING clause, which would see a DML statement project strictly
the complement of what RETURNING projects in the same context. So
perhaps you could also see what RETURNING
Since 192b4aacad45c16a8a9341644479125977366dab my `make
check-world` runs are generating these two warnings:
desc.pgc:55: WARNING: descriptor outdesc does not exist
desc.pgc:86: WARNING: descriptor outdesc does not exist
The referenced file is in the src/interfaces/ecpg/test/sql/
directory and
On 1/9/14, 11:41 PM, Pavel Stehule wrote:
There are two basic questions:
b) will we support same API still - a reference on plugin_info in exec
state is a issue - described in patch.
Pardon my ignorance, but why does the plugin_info have to be in the
executor state? If we're going to change
On 1/12/14, 5:33 PM, I wrote:
On 1/9/14, 11:41 PM, Pavel Stehule wrote:
There are two basic questions:
b) will we support same API still - a reference on plugin_info in exec
state is a issue - described in patch.
Pardon my ignorance, but why does the plugin_info have to be in the
executor
2014/1/12 Marko Tiikkaja ma...@joh.to
On 1/12/14, 5:33 PM, I wrote:
On 1/9/14, 11:41 PM, Pavel Stehule wrote:
There are two basic questions:
b) will we support same API still - a reference on plugin_info in exec
state is a issue - described in patch.
Pardon my ignorance, but why does
2014/1/12 Marko Tiikkaja ma...@joh.to
On 1/12/14, 7:47 AM, Pavel Stehule wrote:
2014/1/12 Marko Tiikkaja ma...@joh.to
Greetings fellow elephants,
I would humbly like to submit for your consideration my proposal for
alleviating pain caused by one of the most annoying footguns in PL/PgSQL:
Bruce Momjian br...@momjian.us writes:
On Sat, Jan 11, 2014 at 12:48:51PM -0800, Adrian Klaver wrote:
I see, though I have another question. If pg_tablespace and the
symlinks can get out of sync, as you say below, why is pg_tablespace
considered the authority? Or to put it another way, why not
On Sat, Jan 11, 2014 at 02:10:01PM -0500, Bruce Momjian wrote:
On Mon, Jun 3, 2013 at 03:07:27PM -0400, Noah Misch wrote:
A colleague, Korry Douglas, observed a table partitioning scenario where
deserializing pg_constraint.ccbin is a hot spot. The following test case, a
simplification of
Craig Ringer cr...@2ndquadrant.com writes:
Turned out to be trivial to test. If the prototype with PGDLLEXPORT
appears *first*, then all is well. If the prototype with PGDLLEXPORT
appears AFTER a user-provided prototype it fails with:
That's sort of what I thought would happen. It's
Hello
Updated version
I still not happy with plugin_info - it is only per plugin now and should
be per plugin and per function.
Regards
Pavel
2014/1/12 Pavel Stehule pavel.steh...@gmail.com
2014/1/12 Marko Tiikkaja ma...@joh.to
On 1/12/14, 5:33 PM, I wrote:
On 1/9/14, 11:41 PM,
All,
I'm leading this off with a review of the features offered by the actual
patch submitted. My general discussion of the issues of Sync Degrade,
which justifies my specific suggestions below, follows that. Rajeev,
please be aware that other hackers may have different opinions than me
on what
On Fri, Jan 10, 2014 at 09:10:47PM -0500, Tom Lane wrote:
3. Move the MemoryContextInit() call to before set_pglocale_pgservice().
#3 is not too nice either, because it would mean calling MemoryContextInit
in main.c which doesn't seem like a great place for it. On the other
hand, there is a
* Josh Berkus (j...@agliodbs.com) wrote:
On 01/11/2014 08:52 PM, Amit Kapila wrote: It is better than async mode
in a way such that in async mode it never
waits for commits to be written to standby, but in this new mode it will
do so unless it is not possible (all sync standby's goes down).
Josh Berkus j...@agliodbs.com wrote:
Add a new parameter :
synchronous_standalone_master = on | off
I think this is a TERRIBLE name for any such parameter. What does
synchronous standalone even mean? A better name for the parameter
would be auto_degrade_sync_replication or
On 01/12/2014 12:35 PM, Stephen Frost wrote:
* Josh Berkus (j...@agliodbs.com) wrote:
You don't want to handle all of those issues the same way as far as sync
rep is concerned. For example, if the standby is restaring, you
probably want to wait instead of degrading.
*What*?! Certainly not
* Josh Berkus (j...@agliodbs.com) wrote:
Well, then that becomes a reason to want better/more configurability.
I agree with this- the challenge is figuring out what those options
should be and how we should document them.
In the couple of sync rep sites I admin, I *would* want to wait.
That's
On Jan12, 2014, at 06:51 , Marko Tiikkaja ma...@joh.to wrote:
I would humbly like to submit for your consideration my proposal for
alleviating pain caused by one of the most annoying footguns in PL/PgSQL: the
behaviour of SELECT .. INTO when the query returns more than one row. Some
of you
On 1/12/14, 10:19 PM, Florian Pflug wrote:
On Jan12, 2014, at 06:51 , Marko Tiikkaja ma...@joh.to wrote:
set plpgsql.consistent_into to true;
I don't think a GUC is the best way to handle this. Handling
this via a per-function setting similar to #variable_conflict would
IMHO be better.
2014/1/12 Florian Pflug f...@phlo.org
On Jan12, 2014, at 06:51 , Marko Tiikkaja ma...@joh.to wrote:
I would humbly like to submit for your consideration my proposal for
alleviating pain caused by one of the most annoying footguns in PL/PgSQL:
the behaviour of SELECT .. INTO when the query
On Sun, Jan 12, 2014 at 8:12 AM, Andreas Karlsson andr...@proxel.se wrote:
On 01/11/2014 11:42 PM, Peter Geoghegan wrote:
I recently suggested that rather than RETURNING REJECTS, we could have
a REJECTING clause, which would see a DML statement project strictly
the complement of what RETURNING
On Jan12, 2014, at 22:37 , Pavel Stehule pavel.steh...@gmail.com wrote:
There is GUC for variable_conflict already too. In this case I would to
enable this functionality everywhere (it is tool how to simply eliminate
some kind of strange bugs) so it needs a GUC.
We have GUC for
On Sat, January 11, 2014 22:47, Andrew Dunstan wrote:
On 01/11/2014 03:03 PM, Erik Rijkers wrote:
On Sat, January 11, 2014 20:30, Peter Eisentraut wrote:
The documentation doesn't build.
corrective patch is here:
On 13/01/14 11:44, Florian Pflug wrote:
On Jan12, 2014, at 22:37 , Pavel Stehule pavel.steh...@gmail.com wrote:
There is GUC for variable_conflict already too. In this case I would to
enable this functionality everywhere (it is tool how to simply eliminate
some kind of strange bugs) so it
On 01/13/2014 02:04 AM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
I think we can just emit a prototype for the function from
PG_FUNCTION_INFO_V1.
Doesn't sound like it.
On second thought, agreed. The externs tending to appear in headers
kills that.
In that case - after
One comment, this:
/* get 128 random bits */
int err = px_get_random_bytes(buf, 16);
might be better to use px_get_pseudo_random_bytes(). UUIDs don't
need to be unguessable or have perfect entropy; they just need to
be collision-resistant. RFC4122 mentions this I think, and if you
look at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/07/2014 12:41 AM, Joe Conway wrote:
Yes, this pretty much exactly describes how I build PL/R for
Windows. I had to match my build system SDK with the one EDB uses
to get a compatible binary. It would be nice if we had something
equivalent to
On Sun, Jan 12, 2014 at 12:48:40PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Sat, Jan 11, 2014 at 12:48:51PM -0800, Adrian Klaver wrote:
I see, though I have another question. If pg_tablespace and the
symlinks can get out of sync, as you say below, why is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/2014 06:56 PM, Craig Ringer wrote:
On 01/07/2014 12:41 AM, Joe Conway wrote:
Yes, this pretty much exactly describes how I build PL/R for
Windows. I had to match my build system SDK with the one EDB
uses to get a compatible binary. It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2014 11:13 AM, Joe Conway wrote:
Yes, that's more-or-less how I do it. I checked with EDB to be sure
I had the same SDK (looks like last time I did it it was SDK 7.1),
then I:
1) download postgres source 2) copy plr source into contrib
On 01/09/2014 10:10 PM, Steeve Lennmark wrote:
That's a much better solution, I attached a patch with the updated code.
# SELECT oid, pg_tablespace_location(oid) FROM pg_tablespace;
[...]
16388 | /tmp/tblspc1
16389 | /tmp/tblspc2
$ pg_basebackup -Xs -D backup/data -T
On 01/12/2014 11:20 PM, Peter Geoghegan wrote:
On Sun, Jan 12, 2014 at 8:12 AM, Andreas Karlsson andr...@proxel.se wrote:
On 01/11/2014 11:42 PM, Peter Geoghegan wrote:
I recently suggested that rather than RETURNING REJECTS, we could have
a REJECTING clause, which would see a DML statement
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/2014 07:22 PM, Craig Ringer wrote:
On 01/13/2014 11:13 AM, Joe Conway wrote: What I mean is that you
should not need a full Pg build tree to compile extensions. Just as
we use PGXS on *nix, so it is possible to just use Visual Studio to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2014 11:35 AM, Joe Conway wrote:
On 01/12/2014 07:22 PM, Craig Ringer wrote:
On 01/13/2014 11:13 AM, Joe Conway wrote: What I mean is that
you should not need a full Pg build tree to compile extensions.
Just as we use PGXS on *nix, so it
On Wed, Jan 08, 2014 at 03:55:38AM +, Dilip kumar wrote:
Below attached patch is implementing following todo item..
machine-readable pg_controldata?
http://www.postgresql.org/message-id/4b901d73.8030...@agliodbs.com
Please put this in the upcoming Commitfest :)
On 01/12/2014 07:02 PM, Bruce Momjian wrote:
On Sun, Jan 12, 2014 at 12:48:40PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Sat, Jan 11, 2014 at 12:48:51PM -0800, Adrian Klaver wrote:
I see, though I have another question. If pg_tablespace and the
symlinks can get out of
On Sun, Jan 12, 2014 at 07:58:52PM -0800, Adrian Klaver wrote:
Well the problem is that it actually points to a current PGDATA just
the wrong one. To use the source installation path and the suggested
upgrade method from pg_upgrade.
Start.
/usr/local/pgsql/data/tblspc_dir
mv above to
Andreas Karlsson wrote:
On 01/09/2014 10:10 PM, Steeve Lennmark wrote:
That's a much better solution, I attached a patch with the updated code.
Looked at the patch quickly and noticed that it does not support
paths containing colons. Is that an acceptable limitation?
Well, clearly it won't
On 01/12/2014 08:04 PM, Bruce Momjian wrote:
On Sun, Jan 12, 2014 at 07:58:52PM -0800, Adrian Klaver wrote:
Well the problem is that it actually points to a current PGDATA just
the wrong one. To use the source installation path and the suggested
upgrade method from pg_upgrade.
In the
2014/1/12 Florian Pflug f...@phlo.org
On Jan12, 2014, at 22:37 , Pavel Stehule pavel.steh...@gmail.com wrote:
There is GUC for variable_conflict already too. In this case I would to
enable this functionality everywhere (it is tool how to simply eliminate
some kind of strange bugs) so it
On Sun, Jan 12, 2014 at 12:41 PM, Amit Kapila amit.kapil...@gmail.com wrote:
Currently there is no way user can keep the dsm
segments if he wants for postmaster lifetime, so I
have exposed a new API dsm_keep_segment()
to implement the same.
The specs and need for this API is already
On 01/11/2014 08:52 PM, Amit Kapila wrote: It is better than async mode
in a way such that in async mode it never
waits for commits to be written to standby, but in this new mode it will
do so unless it is not possible (all sync standby's goes down).
Can't we use existing wal_sender_timeout,
On 13th January 2013, Josh Berkus Wrote:
I'm leading this off with a review of the features offered by the
actual patch submitted. My general discussion of the issues of Sync
Degrade, which justifies my specific suggestions below, follows that.
Rajeev, please be aware that other hackers may
13.01.2014 04:35, Wim Lewis kirjoitti:
One comment, this:
/* get 128 random bits */
int err = px_get_random_bytes(buf, 16);
might be better to use px_get_pseudo_random_bytes(). UUIDs don't
need to be unguessable or have perfect entropy; they just need to
be collision-resistant. RFC4122
2014/1/13 Gavin Flower gavinflo...@archidevsys.co.nz
On 13/01/14 11:44, Florian Pflug wrote:
On Jan12, 2014, at 22:37 , Pavel Stehule pavel.steh...@gmail.com wrote:
There is GUC for variable_conflict already too. In this case I would to
enable this functionality everywhere (it is tool how
2014/1/12 Florian Pflug f...@phlo.org
On Jan12, 2014, at 22:37 , Pavel Stehule pavel.steh...@gmail.com wrote:
There is GUC for variable_conflict already too. In this case I would to
enable this functionality everywhere (it is tool how to simply eliminate
some kind of strange bugs) so it
56 matches
Mail list logo
