2014/1/12 Florian Pflug
> On Jan12, 2014, at 22:37 , Pavel Stehule 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 GU
2014/1/13 Gavin Flower
> On 13/01/14 11:44, Florian Pflug wrote:
>
>> On Jan12, 2014, at 22:37 , Pavel Stehule 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 stra
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 me
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
> 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_t
On Sun, Jan 12, 2014 at 12:41 PM, Amit Kapila 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 discussed
> in thread:
> h
2014/1/12 Florian Pflug
> On Jan12, 2014, at 22:37 , Pavel Stehule 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 GU
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 pgsql_o
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 wo
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 ab
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 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
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 :)
https://commitfest.postgr
-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,
-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
On 01/12/2014 11:20 PM, Peter Geoghegan wrote:
On Sun, Jan 12, 2014 at 8:12 AM, Andreas Karlsson 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
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 /tmp/tblspc1:$(pwd)/bac
-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 con
-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.
On Sun, Jan 12, 2014 at 12:48:40PM -0500, Tom Lane wrote:
> Bruce Momjian 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
> >> c
-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
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 t
On 01/13/2014 02:04 AM, Tom Lane wrote:
> Craig Ringer 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 the rush for th
On 13/01/14 11:44, Florian Pflug wrote:
On Jan12, 2014, at 22:37 , Pavel Stehule 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 fo
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:
>>
>> http://www.postgresql.org/message-id/37b9f104d5a838eec9b75f3668517
On Jan12, 2014, at 22:37 , Pavel Stehule 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 plpgsql.variable_conflict thre
On Sun, Jan 12, 2014 at 8:12 AM, Andreas Karlsson 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 projects i
2014/1/12 Florian Pflug
> On Jan12, 2014, at 06:51 , Marko Tiikkaja 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 r
On 1/12/14, 10:19 PM, Florian Pflug wrote:
On Jan12, 2014, at 06:51 , Marko Tiikkaja 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.
This is exactly
On Jan12, 2014, at 06:51 , Marko Tiikkaja 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 might kn
* 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'
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*?! Certa
Josh Berkus 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
> "synchronou
* 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 d
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
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
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
>
>
>
> 2014/1/12 Marko Tiikkaja
>
>> On 1/12/14, 5:33 PM, I wrote:
>>
>>> On 1/9/14, 11:41 PM, Pavel Stehule wrote:
>>>
>>>
Craig Ringer 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 problematic because
putting
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
> > simplificati
Bruce Momjian 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 just
>> l
2014/1/12 Marko Tiikkaja
> On 1/12/14, 7:47 AM, Pavel Stehule wrote:
>
>> 2014/1/12 Marko Tiikkaja
>>
>> 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
2014/1/12 Marko Tiikkaja
> 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, bu
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 sta
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
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/
director
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 wo
On Jan11, 2014, at 18:53 , Andres Freund 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, however, that does
On Sat, Jan 11, 2014 at 9:45 PM, Peter Eisentraut wrote:
> On Thu, 2013-10-24 at 20:37 +0200, Magnus Hagander wrote:
> > On Thu, Oct 24, 2013 at 8:35 PM, Peter Eisentraut
> > wrote:
> > > On 10/18/12, 7:20 AM, Magnus Hagander wrote:
> > >> 1. krb5 authentication. We've had gssapi since 8.3 (whic
On Sun, Jan 12, 2014 at 5:26 AM, Bruce Momjian 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 Jan12, 2014, at 08:50 , David Rowley 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?
>
> 1.
On 1/12/14, 7:47 AM, Pavel Stehule wrote:
2014/1/12 Marko Tiikkaja
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 query returns
Hello
2014/1/11 Tomas Vondra
> 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 it co
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 stu
On 01/09/2014 06:48 PM, Dean Rasheed wrote:
> On 8 January 2014 10:19, Dean Rasheed 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 invoked, since they
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 feedb
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?
>
On 01/12/2014 12:00 AM, Tom Lane wrote:
> Craig Ringer 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 this. I don't
56 matches
Mail list logo
