On Saturday, May 25, 2013 12:50 AM Alvaro Herrera wrote:
> Hi,
> While going through Andres' BDR code I noticed that it has a shmem
> startup hook, which installs a on_shmem_exit() callback to write stuff
> at shutdown time. This works fine but seems somewhat of a hazard: it is
> having postmas
Re: Cédric Villemain 2013-05-25 <201305251641.28401.ced...@2ndquadrant.com>
> I just took time to inspect our contribs, USE_PGXS is not supported by all of
> them atm because of SHLIB_PREREQS (it used submake) I have a patch pending
> here to fix that. Once all our contribs can build with USE_PGX
On Sat, May 25, 2013 at 9:56 AM, Gurjeet Singh wrote:
> When Postgres encounters a long list of AND/OR chains, it errors out at
> check_stack_depth() after a limit of few thousand. At around 10,000
> elements, the recursion at assign_expr_collations() causes the error. But
> at a little higher el
On Sun, May 26, 2013 at 6:16 AM, Fujii Masao wrote:
> I found that the normal exit (i.e., with exit code 0) of bgworker
> always leads to
> the immediate restart of bgworker whatever bgw_restart_time is. Is
> this intentional?
>
Yes, per the docs:
http://www.postgresql.org/docs/devel/static/bgwor
Could this scenario not be handled by a step that orders the two tables
independently, then for the view interleaves the presorted results?
Merging two sorted sets into a single sorted set is usually a trivial
task, and it could still take advantage of the existing indexes.
William King
Senior Eng
Hi
I've encountered a fundamental problem which - to me - can only be
solved with an (future/possible) real index on views in PostgreSQL
(like the exist already in MS SQL Server and Ora):
Given following schema:
1. TABLE a and TABLE b, each with INDEX on attribute geom.
2. A VIEW with union:
C
Andres,
> all visible is only set in vacuum and it determines which parts of a
> table will be scanned in a non full table vacuum. So, since we won't
> regularly start vacuum in the insert only case there will still be a
> batch of work at once. But nearly all of that work is *already*
> performed
Hi,
I found that the normal exit (i.e., with exit code 0) of bgworker
always leads to
the immediate restart of bgworker whatever bgw_restart_time is. Is
this intentional?
Not only crash but also normal exit should go along with bgw_restart_time?
I'm now writing the bgworker which is allowed to be
Fujii Masao escribió:
> On Sat, May 25, 2013 at 6:18 PM, Simon Riggs wrote:
> > I think we should treat this as a bug and fix it in 9.3 while we're
> > still in beta.
>
> +1
>
> > Why? Because once we begin using the topXid as the
> > filename we can't then change later to using the vxid.
>
>
On Sat, May 25, 2013 at 6:18 PM, Simon Riggs wrote:
> On 21 May 2013 19:16, Fujii Masao wrote:
>
>> We cannot run parallel pg_dump on the standby server because
>> pg_export_snapshot() always fails on the standby. Is this the oversight
>> of parallel pg_dump or pg_export_snapshot()?
>>
>> pg_expo
On Sat, May 25, 2013 at 10:39:30AM +0100, Simon Riggs wrote:
> There are a number of changes we'd probably like to make to the way
> things work in Postgres. This thread is not about discussing what
> those are, just to say that requirements exist and have been discussed
> in various threads over t
On Thu, May 16, 2013 at 7:05 PM, Greg Smith wrote:
> On 5/16/13 9:16 AM, Jon Nelson wrote:
>>
>> Am I doing this the right way? Should I be posting the full patch each
>> time, or incremental patches?
>
>
> There are guidelines for getting your patch in the right format at
> https://wiki.postgresq
On 25 May 2013 18:13, Jeff Davis wrote:
> On Sat, 2013-05-25 at 10:39 +0100, Simon Riggs wrote:
>> The constraint on such changes is that we've decided that we must have
>> an upgrade path from release to release.
>
> Is this proposal only relaxing the binary upgrade requirement, or would
> it als
On Sat, 2013-05-25 at 10:39 +0100, Simon Riggs wrote:
> The constraint on such changes is that we've decided that we must have
> an upgrade path from release to release.
Is this proposal only relaxing the binary upgrade requirement, or would
it also relax other compatibility requirements, such as
On Sat, May 25, 2013 at 4:39 AM, Simon Riggs wrote:
> There are a number of changes we'd probably like to make to the way
> things work in Postgres. This thread is not about discussing what
> those are, just to say that requirements exist and have been discussed
> in various threads over time.
>
>
> > If it seems to be on the right way, I'll keep fixing EXTENSION building
> > with VPATH.
>
> I haven't tried the patch, but let me just say that Debian (and
> apt.postgresql.org) would very much like the VPATH situation getting
> improved. At the moment we seem to have to invent a new build rec
When Postgres encounters a long list of AND/OR chains, it errors out at
check_stack_depth() after a limit of few thousand. At around 10,000
elements, the recursion at assign_expr_collations() causes the error. But
at a little higher element count, around 15,000, the recursion check errors
out a lit
On 24 May 2013 17:00, Robert Haas wrote:
> On Fri, May 24, 2013 at 11:29 AM, Robert Haas wrote:
>> On Fri, May 24, 2013 at 10:53 AM, Andres Freund
>> wrote:
[all-visible cannot restore hint bits without FPI because of torn pages]
>>>
>>> I haven't yet thought about this sufficiently yet. I
There are a number of changes we'd probably like to make to the way
things work in Postgres. This thread is not about discussing what
those are, just to say that requirements exist and have been discussed
in various threads over time.
The constraint on such changes is that we've decided that we mu
On Sat, May 25, 2013 at 10:05 AM, Amit kapila wrote:
>> In a nutshell, the idea is to do copy everything that has changed
>> between the cluster, like rsync does, but instead of reading through all
>> files, use the WAL to determine what has changed. Here's a somewhat more
>> detailed explanation,
On 21 May 2013 19:16, Fujii Masao wrote:
> We cannot run parallel pg_dump on the standby server because
> pg_export_snapshot() always fails on the standby. Is this the oversight
> of parallel pg_dump or pg_export_snapshot()?
>
> pg_export_snapshot() fails in the standby because it always assigns
On Thursday, May 23, 2013 4:40 PM Heikki Linnakangas wrote:
> Hi,
> I've been hacking on a tool to allow resynchronizing an old master
> server after failover. The need to do a full backup/restore has been a
> common complaint ever since we've had streaming replication. I saw on
> the wiki that t
22 matches
Mail list logo
