On Thu, Jun 26, 2014 at 8:17 PM, Vik Fearing wrote:
> I didn't quite follow your ALTER TABLE example because I don't think
> it's necessary,
I was asking to split the ALTER SYSTEM command like it's there
for ALTER TABLE (AlterTableStmt:
ALTER TABLE relation_expr alter_table_cmds).
It would have ma
On Wed, Jul 30, 2014 at 1:11 AM, Marco Nenciarini
wrote:
> "differential backup" is widely used to refer to a backup that is always
> based on a "full backup". An "incremental backup" can be based either on
> a "full backup" or on a previous "incremental backup". We picked that
> name to emphasize
"Baker, Keith [OCDUS Non-J&J]" writes:
> If there are existing tests I can run to ensure the QNX port meets your
> criteria for robust failure handling in this area I would be happy to run
> them.
> If not, perhaps someone can provide a quick list of failure modes to consider.
> As-is:
> - start
Thank you to all who have responded to this proposal.
PostgreSQL manages to meet all production requirements on Windows without
System V shared memory, so I would think this can be achieved on QNX/Linux.
The old PostgreSQL QNX port ran on the very old "QNX4" (1991), so I understand
why it would
Robert Haas writes:
> On Fri, Jul 25, 2014 at 6:29 PM, Tom Lane wrote:
>> This isn't really acceptable for production usage; if it were, we'd have
>> done it already. The POSIX APIs lack any way to tell how many processes
>> are attached to a shmem segment, which is *necessary* functionality for
On 1/14/14, 6:15 PM, Tom Lane wrote:
We don't actually implement this in PG yet, except for trivial cases, but
it will certainly happen eventually. I think your sketch above deviates
unnecessarily from what the standard says for UPDATE. In particular
I think it'd be better to write things like
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> PG 8.4.x is EOL as of last week's releases, so it's time to remove that
> branch from any auto-update scripts you might have, reconfigure buildfarm
> members that are force-building it, etc.
I've removed it from the Coverity weekly runs.
Thanks,
On 28 Jul 2014, at 5:23 PM, Peter Geoghegan wrote:
> On Mon, Jul 28, 2014 at 5:14 PM, Wim Lewis wrote:
>> A quick glance at OSX's strxfrm() suggests they're using an implementation
>> of strxfrm() from FreeBSD. You can find the source here:
>>
>>
>> http://www.opensource.apple.com/source/Li
I have just pushed two optimization patches for multixacts to HEAD only.
I hesitate to backpatch them to 9.3 right away, but will consider doing
so if people think differently.
I also have a patch that supposedly fixes the performance regression
reported in bug #8470, but it's considerably more ob
On Sun, Jul 27, 2014 at 12:00 AM, Peter Geoghegan wrote:
> I attach a new revision.
I think that I may have missed a trick here.
It turns out that it isn't expensive to also hash original text
values, to track their cardinality using HyperLogLog - it's hardly
measurable when done at an opportune
On Tue, Jul 29, 2014 at 3:06 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On 25 July 2014 20:47, Tom Lane wrote:
>>> Another idea would be to
>
>> ...persist the optimal dump order in the database.
>
>> That way we can maintain the correct dump order each time we do DDL,
>> which is only a small
Simon Riggs writes:
> On 25 July 2014 20:47, Tom Lane wrote:
>> Another idea would be to
> ...persist the optimal dump order in the database.
> That way we can maintain the correct dump order each time we do DDL,
> which is only a small incremental cost, no matter how many objects we
> have.
I
On 25 July 2014 20:47, Tom Lane wrote:
> Another idea would be to
...persist the optimal dump order in the database.
That way we can maintain the correct dump order each time we do DDL,
which is only a small incremental cost, no matter how many objects we
have.
--
Simon Riggs
On Tue, Jul 29, 2014 at 9:56 AM, Robert Haas wrote:
> I think it would be advisable to separate the syntax from the
> implementation. Presumably you can make your implementation use some
> reasonable syntax we can all agree on, and conversely my proposed
> syntax could be made to have a different
On Mon, Jul 28, 2014 at 1:43 PM, Peter Geoghegan wrote:
> On Mon, Jul 28, 2014 at 8:37 AM, Robert Haas wrote:
>> AFAIUI, this is because your implementation uses lwlocks in a way that
>> Andres and I both find unacceptable.
>
> That's not the case. My implementation uses page-level heavyweight
>
On Mon, Jul 28, 2014 at 1:50 PM, Andres Freund wrote:
> Don't get me wrong, I don't object to anything in here. It's just that
> the bigger picture can help giving sensible feedback.
Right. I did not get you wrong. :-)
The reason I'm making a point of it is that, if somebody wants to
object to
Robert Haas writes:
> On Mon, Jul 28, 2014 at 10:55 AM, Tom Lane wrote:
>> If we had something like that, I'd be strongly inclined to get rid of
>> the existing convention whereby comments and ACL commands are separate
>> TOC entries, and make them part of the parent object's TOC entry (which'd
>
Il 25/07/14 20:44, Robert Haas ha scritto:
> On Fri, Jul 25, 2014 at 2:21 PM, Claudio Freire
> wrote:
>> On Fri, Jul 25, 2014 at 10:14 AM, Marco Nenciarini
>> wrote:
>>> 1. Proposal
>>> =
>>> Our proposal is to introduce the concept of a backup profile. The backup
On Tue, Jul 29, 2014 at 1:24 PM, Marco Nenciarini
wrote:
>> On Fri, Jul 25, 2014 at 10:14 AM, Marco Nenciarini
>> wrote:
>>> 1. Proposal
>>> =
>>> Our proposal is to introduce the concept of a backup profile. The backup
>>> profile consists of a file with one line
On Mon, Jul 28, 2014 at 10:55 AM, Tom Lane wrote:
> Stephen Frost writes:
>> If we're going to change this, it seems to me that the only option would
>> be to change the dump format... Just off-the-cuff, I'm wondering if we
>> could actually not change the real 'format' but simply promote each A
Il 25/07/14 20:21, Claudio Freire ha scritto:
> On Fri, Jul 25, 2014 at 10:14 AM, Marco Nenciarini
> wrote:
>> 1. Proposal
>> =
>> Our proposal is to introduce the concept of a backup profile. The backup
>> profile consists of a file with one line per file detailing
Il 25/07/14 16:15, Michael Paquier ha scritto:
> On Fri, Jul 25, 2014 at 10:14 PM, Marco Nenciarini
> wrote:
>> 0. Introduction:
>> =
>> This is a proposal for adding incremental backup support to streaming
>> protocol and hence to pg_basebackup command.
> Not sure
On Tue, Jun 24, 2014 at 10:58:54AM +0800, Craig Ringer wrote:
> Hi all
>
> Someone recently mentioned that there's no generate_series(numeric,
> numeric, numeric) .
>
> That strikes me as a great candidate for a
> new-developer-learning-PostgreSQL TODO.
>
>
> A couple of other things I occasion
On Tue, Jul 29, 2014 at 09:08:38AM -0400, Bruce Momjian wrote:
> On Thu, Jun 26, 2014 at 09:59:59AM -0400, Stephen Frost wrote:
> > Simon,
> >
> > * Simon Riggs (si...@2ndquadrant.com) wrote:
> > > "Which tables are audited" would be available via the reloptions
> > > field.
> >
> > RLS could be
On Thu, Jun 26, 2014 at 09:59:59AM -0400, Stephen Frost wrote:
> Simon,
>
> * Simon Riggs (si...@2ndquadrant.com) wrote:
> > "Which tables are audited" would be available via the reloptions
> > field.
>
> RLS could be implemented through reloptions too. Would it be useful to
> some people? Lik
On Tue, Jul 29, 2014 at 7:30 PM, Heikki Linnakangas
wrote:
> I don't understand how this works. A full-page image contains the new page
> contents *after* the WAL-logged operation. For example, in a heap insert,
> the full-page image contains the new tuple. How can you compare that with
> what's o
On Mon, Jul 28, 2014 at 3:17 PM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
> > Now drop the i_t1_pkey_1 and check the query plan again.
> >
> > drop index i_t1_pkey_1;
> > explain (costs off, analyze off) select * from t,t1 where t.a=t1.a
order by
> > t1.a,t1.b,t1.c,t1.d;
> >
On Mon, Jul 28, 2014 at 11:33 PM, Fujii Masao wrote:
> There is other side effect on this patch. With the patch, when reloading
> the configurartion file, the server cannot warm an invalid setting value
> if it's not the last setting of the parameter. This may cause problematic
> situation as foll
On 07/10/2014 12:41 AM, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
On 06/23/2014 08:07 PM, Alvaro Herrera wrote:
I feel that the below would nevertheless be simpler:
I wonder if it would be simpler to just always store the revmap
pages in the beginning of the index, before any other pa
On 07/23/2014 05:14 PM, Michael Paquier wrote:
On Tue, Jul 22, 2014 at 4:49 PM, Michael Paquier
wrote:
Then, looking at the code, we would need to tweak XLogInsert for the
WAL record construction to always do a FPW and to update
XLogCheckBufferNeedsBackup. Then for the redo part, we would need
I have improved the patch by making following changes:
1. Since stream_stop() was redundant, stream_stop() at the time of WAL file
closing was deleted.
2. Change the Flash judging timing for the readability of source code.
I have changed the Flash judging timing , from the continuous messag
On Fri, Jun 20, 2014 at 05:15:05PM +0200, Christoph Berg wrote:
> Another nitpick here: What pg_upgrade outputs doesn't even work on
> most systems, you need to ./analyze_new_cluster.sh or "sh
> analyze_new_cluster.sh".
Well, the output is:
Optimizer statistics are not transferred by pg_u
On Wed, Jun 18, 2014 at 05:41:06PM +0200, Christoph Berg wrote:
> Hi,
>
> now that we have vacuumdb --all --analyze-in-stages in 9.4, wouldn't
> it make sense to get rid of the analyze_new_cluster.sh file which
> pg_upgrade writes? The net content is a single line which could as
> well be printed
Attached B patch does turn incorrect setrandom syntax into errors instead of
ignoring extra parameters.
First A patch is repeated to help commitfest references.
Oops, I applied the change on the wrong part:-(
Here is the change on part A which checks setrandom syntax, and B for
completenes
2014-07-29 9:41 GMT+02:00 Marti Raudsepp :
> On Tue, Jul 29, 2014 at 9:49 AM, Pavel Stehule
> wrote:
> > I dislike this proposal - it is strongly inconsistent with current
> trigger
> > design
>
> The real point I was trying to convey (in my previous email) is that
> these declarations should be
Hello Robert,
3. Similarly, I suggest that the use of gaussian or uniform be an
error when argc < 6 OR argc > 6. I also suggest that the
parenthesized distribution type be dropped from the error message in
all cases.
I wish to agree, but my interpretation of the previous code is that they
we
On Tue, Jul 29, 2014 at 9:49 AM, Pavel Stehule wrote:
> I dislike this proposal - it is strongly inconsistent with current trigger
> design
The real point I was trying to convey (in my previous email) is that
these declarations should be part of the trigger *function* not the
function-to-table re
37 matches
Mail list logo
