On Fri, Oct 24, 2014 at 7:18 AM, Peter Eisentraut wrote:
> On 10/21/14 1:16 PM, Tom Lane wrote:
>> If you do any Postgres development on OS X, you've probably gotten
>> seriously annoyed by the way that, every single time you reinstall the
>> postmaster executable, you get a dialog box asking whet
(2014/10/21 17:40), Etsuro Fujita wrote:
(2014/10/14 20:00), Etsuro Fujita wrote:
Here are separated patches.
fdw-chk.patch - CHECK constraints on foreign tables
fdw-inh.patch - table inheritance with foreign tables
The latter has been created on top of [1].
[1] http://www.postgresql.org/
On 10/23/2014 09:21 PM, Robert Haas wrote:
> Agreed - I think if you want an error check here it should use elog()
> or ereport(), not Assert().
That's what I originally did, but it's too early for elog.
I'm reluctant to just fprintf(...) to stderr, as there's no way for the
user to suppress that
On 10/21/14 1:16 PM, Tom Lane wrote:
> If you do any Postgres development on OS X, you've probably gotten
> seriously annoyed by the way that, every single time you reinstall the
> postmaster executable, you get a dialog box asking whether you'd like
> to allow it to accept incoming network connect
On Thu, Oct 23, 2014 at 6:43 PM, Peter Geoghegan wrote:
> Documentation
> ===
>
> The documentation has been updated, incorporating feedback. I also
> made the cardinality violation error a lot clearer than before, since
> Craig said that was unclear.
For the convenience of those that wa
Dag-Erling Smørgrav wrote:
> Alvaro Herrera writes:
> > OpenSSL just announced a week or two ago that they're abandoning support
> > for 0.9.8 by the end of next year[1], which means its replacements have
> > been around for a really long time.
>
> RHEL5 still has 0.9.8e with backported patches a
Florian Pflug wrote:
> It seems that README.tuplock never got updated when the KEY SHARE patch's
> lock level were changed from being KEY UPDATE / UPDATE / SHARE / KEY SHARE
> to UPDATE / NO KEY UPDATE / SHARE / KEY SHARE.
You're right. We changed the tuple lock modes at the last minute and
I fo
On Fri, Oct 17, 2014 at 1:08 PM, Tom Lane wrote:
> This looks to me like re-fighting the last war. Such a GUC has zero value
> *unless* some situation exactly like the POODLE bug comes up again, and
> the odds of that are not high.
I think it's pretty common for flaws to be discovered in particu
Brightwell, Adam wrote:
> > If we were to make it consistent and use the old wording, what do you
> > think about providing an "errhint" as well?
> >
> > Perhaps for example in slotfuncs.c#pg_create_physical_replication_stot:
> >
> > errmsg - "permission denied to create physical replication slot"
I wrote:
> More generally, it seems like we ought to have a test in the type_sanity
> regression script that checks that type I/O functions aren't volatile,
> because there are various embedded assumptions that this is so, cf
> commits aab353a60b95aadc00f81da0c6d99bde696c4b75 and
> 3db6524fe63f0598
>> I noticed something strange while perusing this patch, but the issue
>> predates the patch. Some messages say "must be superuser or replication
>> role to foo", but our longstanding practice is to say "permission denied
>> to foo". Why do we have this inconsistency? Should we remove it? If
>
Joe Van Dyk writes:
> Seems like casting ltree to text and the subtree function should be
> immutable?
Hm, yeah, I can see no reason why ltree_in and ltree_out shouldn't be
immutable. They surely ought not be volatile, which is the way they
are marked (by default) right now. The other types in
On Thu, Oct 23, 2014 at 5:41 AM, David Rowley wrote:
> On Thu, Oct 23, 2014 at 1:27 AM, Craig Ringer wrote:
>> Here's an updated patch addressing David's points.
>> I haven't had a chance to test it yet, on win2k8 or win2k12 due to
>> pgconf.eu .
>>
> Hi Craig, thanks for the fast turnaround.
>
>
Tom Lane writes:
> Anyone who is feeling paranoid about shutting off SSLv3 despite (1)
> can do so via the existing ssl_ciphers GUC parameter [...] the ciphers
> string includes categories corresponding to protocol versions, so you
> can shut off an old protocol version there if you need to.
The
On Oct23, 2014, at 17:45 , Kevin Grittner wrote:
> Every way I look at it, inside a REPEATABLE READ or SERIALIZABLE
> transaction a check for child rows when validating a parent DELETE
> should consider both rows which exist according to the transaction
> snapshot and according to a "current" snap
On Wed, Oct 22, 2014 at 9:21 PM, Alvaro Herrera
wrote:
>
> Sawada Masahiko wrote:
>
> > Thank you for reviewing.
> > I agree 2) - 5).
> > Attached patch is latest version patch I modified above.
> > Also, I noticed I had forgotten to add the patch regarding document of
> > reindexdb.
>
> Please do
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= writes:
> Alvaro Herrera writes:
>> OpenSSL 0.9.7 has already not gotten fixes for all the latest flurry of
>> security issues, so anyone *is* using SSL but not at least the 0.9.8
>> branch, they are in trouble.
> The latest 0.9.8 still only has TLS 1.0, unle
On Thu, Oct 23, 2014 at 8:39 AM, Andrew Dunstan wrote:
>
> On 10/23/2014 09:27 AM, Merlin Moncure wrote:
>>
>> On Thu, Oct 23, 2014 at 4:34 AM, Pavel Stehule
>> wrote:
>>>
>>> Hi
>>>
>>> here is a prototype
>>>
>>> postgres=# select row_to_json(row(10 as A, row(30 as c, 20 AS B) as x));
>>>
Alvaro Herrera writes:
> OpenSSL just announced a week or two ago that they're abandoning support
> for 0.9.8 by the end of next year[1], which means its replacements have
> been around for a really long time.
RHEL5 still has 0.9.8e with backported patches and will be supported
until 2017-03-31.
On Tue, Oct 21, 2014 at 12:00 PM, Andres Freund wrote:
> On 2014-10-09 15:01:19 -0400, Robert Haas wrote:
>> /*
>> @@ -960,18 +966,38 @@ AtEOXact_Inval(bool isCommit)
> ...
>> + /*
>> + * We create invalidation stack entries lazily, so the parent
>> might
>> +
On Thu, Oct 23, 2014 at 8:51 AM, Andrew Dunstan wrote:
>
> On 10/23/2014 11:36 AM, David G Johnston wrote:
>
>> Andrew Dunstan wrote
>>
>>> On 10/23/2014 09:57 AM, Florian Pflug wrote:
>>>
On Oct23, 2014, at 15:39 , Andrew Dunstan <
>>> andrew@
>>> > wrote:
>>>
On 10/23/2014 09:27
Alvaro,
> I noticed something strange while perusing this patch, but the issue
> predates the patch. Some messages say "must be superuser or replication
> role to foo", but our longstanding practice is to say "permission denied
> to foo". Why do we have this inconsistency? Should we remove it?
On 10/23/2014 11:36 AM, David G Johnston wrote:
Andrew Dunstan wrote
On 10/23/2014 09:57 AM, Florian Pflug wrote:
On Oct23, 2014, at 15:39 , Andrew Dunstan <
andrew@
> wrote:
On 10/23/2014 09:27 AM, Merlin Moncure wrote:
On Thu, Oct 23, 2014 at 4:34 AM, Pavel Stehule <
pavel.stehule@
> wro
2014-10-23 17:36 GMT+02:00 David G Johnston :
> Andrew Dunstan wrote
> > On 10/23/2014 09:57 AM, Florian Pflug wrote:
> >> On Oct23, 2014, at 15:39 , Andrew Dunstan <
>
> > andrew@
>
> > > wrote:
> >>> On 10/23/2014 09:27 AM, Merlin Moncure wrote:
> On Thu, Oct 23, 2014 at 4:34 AM, Pavel Steh
Kevin Grittner wrote:
> Florian Pflug wrote:
>> Also, note that after the DELETE FROM parent, further SELECTS in
>> the same transaction will use the original snapshot again, und
>> thus will see the conflicting child rows again that were ignored
>> by the RI trigger. But they won't, of course,
06.10.2014, 17:42, Andres Freund kirjoitti:
> I think we can pretty much apply Oskari's patch after replacing
> acquire/release with read/write intrinsics.
Attached a patch rebased to current master using read & write barriers.
/ Oskari
From a994c0f4feff74050ade183ec26d726397fa14a7 Mon Sep 17 00:
Andrew Dunstan wrote
> On 10/23/2014 09:57 AM, Florian Pflug wrote:
>> On Oct23, 2014, at 15:39 , Andrew Dunstan <
> andrew@
> > wrote:
>>> On 10/23/2014 09:27 AM, Merlin Moncure wrote:
On Thu, Oct 23, 2014 at 4:34 AM, Pavel Stehule <
> pavel.stehule@
> > wrote:
> postgres=# select row
On Wed, Oct 22, 2014 at 5:29 PM, Tom Lane wrote:
>> I was thinking that the hook would return a RelationParam. When parse
>> analysis sees the returned RelationParam, it adds an entry for that to
>> the range table, and creates the RangeTblRef for it. The way you
>> describe it works too, but mani
On 10/23/2014 06:01 PM, Simon Riggs wrote:
On 23 October 2014 15:39, Fujii Masao wrote:
Sorry, I'm going around in the circle. But I'd like to say again, I don't think
this is good idea. It prevents asynchronous pg_receivexlog from fsyncing
WAL data and sending feedbacks more frequently at all
On 23 October 2014 15:39, Fujii Masao wrote:
> Sorry, I'm going around in the circle. But I'd like to say again, I don't
> think
> this is good idea. It prevents asynchronous pg_receivexlog from fsyncing
> WAL data and sending feedbacks more frequently at all. They are useful,
> for example, whe
On Thu, Oct 23, 2014 at 10:45 AM, Peter Eisentraut wrote:
> Committed your patch and tests.
>
Thanks!
--
Michael
On Wed, Oct 22, 2014 at 10:47 PM, Simon Riggs wrote:
> On 22 October 2014 14:26, Heikki Linnakangas wrote:
>
>> We seem to be going in circles. You suggested having two options,
>> --feedback, and --fsync, which is almost exactly what Furuya posted
>> originally. I objected to that, because I thi
Hi,
It seems that README.tuplock never got updated when the KEY SHARE patch's
lock level were changed from being KEY UPDATE / UPDATE / SHARE / KEY SHARE
to UPDATE / NO KEY UPDATE / SHARE / KEY SHARE.
Thus, as it stands, that file implies that SELECT FOR UPDATE obtains a
weaker lock than an actual
On 10/23/2014 09:57 AM, Florian Pflug wrote:
On Oct23, 2014, at 15:39 , Andrew Dunstan wrote:
On 10/23/2014 09:27 AM, Merlin Moncure wrote:
On Thu, Oct 23, 2014 at 4:34 AM, Pavel Stehule wrote:
postgres=# select row_to_json(row(10 as A, row(30 as c, 20 AS B) as x));
row_to_json
--
On Thu, Oct 23, 2014 at 10:16 PM, Michael Paquier wrote:
> On Thu, Oct 23, 2014 at 1:45 PM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
> That's not right. Should check *after* the write if the segment was
> completed, and close it if so. Like the attached.
>
> Just tested this patch w
Hi all,
pg_recvlogical is missing some "=" signs for a couple of option names where
double-dash is used, like this one:
--username user
should be that:
--username=user
Attached is a patch correcting that.
Regards,
--
Michael
diff --git a/doc/src/sgml/ref/pg_recvlogical.sgml b/doc/src/sgml/ref/pg
On Oct23, 2014, at 15:39 , Andrew Dunstan wrote:
> On 10/23/2014 09:27 AM, Merlin Moncure wrote:
>> On Thu, Oct 23, 2014 at 4:34 AM, Pavel Stehule
>> wrote:
>>> postgres=# select row_to_json(row(10 as A, row(30 as c, 20 AS B) as x));
>>> row_to_json
>>> --
>>
On 10/23/2014 09:27 AM, Merlin Moncure wrote:
On Thu, Oct 23, 2014 at 4:34 AM, Pavel Stehule wrote:
Hi
here is a prototype
postgres=# select row_to_json(row(10 as A, row(30 as c, 20 AS B) as x));
row_to_json
--
{"a":10,"x":{"c":30,"b":20}}
(1 row)
pos
On Tue, Oct 14, 2014 at 8:11 AM, Michael Paquier
wrote:
> On Tue, Oct 14, 2014 at 4:49 AM, Bruce Momjian wrote:
>> On Thu, Sep 4, 2014 at 10:50:58PM +0900, Michael Paquier wrote:
>>> On Thu, Sep 4, 2014 at 1:44 PM, Fujii Masao wrote:
>>> > On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao
>>> > wr
On Thu, Oct 23, 2014 at 4:34 AM, Pavel Stehule wrote:
> Hi
>
> here is a prototype
>
> postgres=# select row_to_json(row(10 as A, row(30 as c, 20 AS B) as x));
> row_to_json
> --
> {"a":10,"x":{"c":30,"b":20}}
> (1 row)
>
> postgres=# select row_to_json(row(10
On Thu, Oct 23, 2014 at 1:45 PM, Heikki Linnakangas wrote:
> On 10/23/2014 01:25 PM, Michael Paquier wrote:
>
>> On Thu, Oct 23, 2014 at 10:09 AM, Heikki Linnakangas <
>> hlinnakan...@vmware.com> wrote:
>>
>> On 10/23/2014 08:59 AM, Fujii Masao wrote:
>>> Sounds reasonable, for back-branches. Al
On Thu, Oct 23, 2014 at 2:34 PM, Fujii Masao wrote:
> On Thu, Oct 23, 2014 at 9:23 PM, Fujii Masao
> wrote:
> > On Thu, Oct 23, 2014 at 8:45 PM, Heikki Linnakangas
> > wrote:
> >> On 10/23/2014 01:25 PM, Michael Paquier wrote:
> >>>
> >>> On Thu, Oct 23, 2014 at 10:09 AM, Heikki Linnakangas <
>
On 10/23/2014 11:41 AM, David Rowley wrote:
> I'm not a big fan of this. It seems quite strange to be using Assert in
> this way. I'd rather see any error just silently fall back
> on GetSystemTimeAsFileTime() instead of this.
That's fair. I'd like some visibility into it, but I don't think it's
On Thu, Oct 23, 2014 at 9:23 PM, Fujii Masao wrote:
> On Thu, Oct 23, 2014 at 8:45 PM, Heikki Linnakangas
> wrote:
>> On 10/23/2014 01:25 PM, Michael Paquier wrote:
>>>
>>> On Thu, Oct 23, 2014 at 10:09 AM, Heikki Linnakangas <
>>> hlinnakan...@vmware.com> wrote:
>>>
On 10/23/2014 08:59 AM,
On Thu, Oct 23, 2014 at 8:45 PM, Heikki Linnakangas
wrote:
> On 10/23/2014 01:25 PM, Michael Paquier wrote:
>>
>> On Thu, Oct 23, 2014 at 10:09 AM, Heikki Linnakangas <
>> hlinnakan...@vmware.com> wrote:
>>
>>> On 10/23/2014 08:59 AM, Fujii Masao wrote:
>>> Sounds reasonable, for back-branches. Al
On Thu, Oct 23, 2014 at 5:09 PM, Heikki Linnakangas
wrote:
> On 10/23/2014 08:59 AM, Fujii Masao wrote:
>>
>> On Mon, Oct 20, 2014 at 3:26 PM, Michael Paquier
>> wrote:
>>>
>>> On Fri, Oct 17, 2014 at 10:37 PM, Michael Paquier
>>> wrote:
On Fri, Oct 17, 2014 at 9:23 PM, Fujii Masa
On 10/23/2014 01:25 PM, Michael Paquier wrote:
On Thu, Oct 23, 2014 at 10:09 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
On 10/23/2014 08:59 AM, Fujii Masao wrote:
Sounds reasonable, for back-branches. Although I'm still worried we might
miss some corner-case unless we go with a mo
On Thu, Oct 23, 2014 at 10:09 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 10/23/2014 08:59 AM, Fujii Masao wrote:
> Sounds reasonable, for back-branches. Although I'm still worried we might
> miss some corner-case unless we go with a more wholesale solution.
>
Don't really want
Dag-Erling Smørgrav wrote:
> Martijn van Oosterhout writes:
> > Dag-Erling Smørgrav writes:
> > > Martijn van Oosterhout writes:
> > > > Since you can already specify the cipher list, couldn't you just
> > > > add -SSLv3 to the cipher list and be done?
> > > I didn't want to change the existing
On Thu, Oct 23, 2014 at 1:27 AM, Craig Ringer wrote:
> Here's an updated patch addressing David's points.
>
> I haven't had a chance to test it yet, on win2k8 or win2k12 due to
> pgconf.eu .
>
>
Hi Craig, thanks for the fast turnaround.
I've just had a look over the patch again:
+
Hi
here is a prototype
postgres=# select row_to_json(row(10 as A, row(30 as c, 20 AS B) as x));
row_to_json
--
{"a":10,"x":{"c":30,"b":20}}
(1 row)
postgres=# select row_to_json(row(10, row(30, 20)));
row_to_json
--
I don't think that the lock level mentioned in the following comment in
MergeAttributes() in tablecmds.c is right, since that that function has
opened the relation with ShareUpdateExclusiveLock, not with
AccessShareLock. Patch attached.
1749 /*
1750 * Close the parent rel, but ke
On 10/23/2014 08:59 AM, Fujii Masao wrote:
On Mon, Oct 20, 2014 at 3:26 PM, Michael Paquier
wrote:
On Fri, Oct 17, 2014 at 10:37 PM, Michael Paquier
wrote:
On Fri, Oct 17, 2014 at 9:23 PM, Fujii Masao wrote:
In this case, the patch seems to make the restartpoint recycle even WAL files
whi
On Mon, Oct 20, 2014 at 5:15 PM, Michael Paquier
wrote:
>
>
> On Fri, Oct 17, 2014 at 10:12 PM, Fujii Masao wrote:
>>
>> On Fri, Oct 17, 2014 at 9:23 PM, Fujii Masao
>> wrote:
>> > On Thu, Oct 9, 2014 at 3:26 PM, Michael Paquier
>> > wrote:
>> >>
>> >>
>> >> On Wed, Oct 8, 2014 at 10:00 PM, Mic
Martijn van Oosterhout writes:
> Dag-Erling Smørgrav writes:
> > Martijn van Oosterhout writes:
> > > Since you can already specify the cipher list, couldn't you just
> > > add -SSLv3 to the cipher list and be done?
> > I didn't want to change the existing behavior; all I wanted was to
> > give
On 10/22/2014 04:13 PM, Tom Lane wrote:
Andreas Karlsson writes:
I have attached a proof of concept
patch which reduces the lock strength to ShareLock.
You're kidding, right? ShareLock isn't even self-exclusive.
Why would it have to be self-exclusive? As far as I know we only need to
ensu
56 matches
Mail list logo
