The SE-PostgreSQL patches (for v8.5) are updated:
http://sepgsql.googlecode.com/files/sepgsql-01-sysatt-8.4beta1-r1891.patch
http://sepgsql.googlecode.com/files/sepgsql-02-core-8.4beta1-r1891.patch
http://sepgsql.googlecode.com/files/sepgsql-03-writable-8.4beta1-r1891.patch
http://sepgsql.googleco
Hi,
Sorry for the delay.
On Thu, May 14, 2009 at 6:04 AM, Simon Riggs wrote:
>> but before we go to DB_IN_PRODUCTION?
>
> I think it can be either, so I'll go with your proposal.
I also think so.
> (I'm aware Fujii-san is asleep right now, so we should expect another
> viewpoint before tomorro
Hi,
Cristina M writes:
> For each varchar column - I add an extra 4 bytes
>
>
> For each numeric column - I add an extra 8 bytes
>
Hi,
On Mon, May 4, 2009 at 11:07 PM, K, Niranjan (NSN - IN/Bangalore)
wrote:
> Hi,
>
> Re-opening the discussion related to triggers to promote standby server.
> In the earlier dicussion, there were 2 proposals, Trigger based on file
> and trigger based on signals. I think there was no conclusion
Hi,
On Thu, May 14, 2009 at 8:16 PM, Fujii Masao wrote:
> Hi,
>
> On Mon, May 4, 2009 at 11:07 PM, K, Niranjan (NSN - IN/Bangalore)
> wrote:
>> Hi,
>>
>> Re-opening the discussion related to triggers to promote standby server.
>> In the earlier dicussion, there were 2 proposals, Trigger based on
Em Qui, 2009-05-14 às 09:35 +0300, Heikki Linnakangas escreveu:
> Dickson S. Guedes wrote:
> > Hi all,
> >
> > Attached is a patch to fix a command line example in charset.sgml.
>
> No, the options really are called LC_COLLATE and LC_CTYPE now. They were
> renamed on 6th of April, just before be
On Wed, 2009-05-13 at 21:43 +0100, Simon Riggs wrote:
> On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:
>
> > This whole thing can be considered to be a new feature.
>
> recovery.conf will contain a new optional parameter:
>
> recovery_end_command (string)
Implemented.
Some poss
In a thread on -perform it has been observed that our Read-Only
scalability is not as good as it could be. One problem being that we
need to scan the whole of the ProcArray to derive a snapshot, which
becomes the dominant task with many users.
If we think about a situation where write transaction
Simon Riggs writes:
> In a thread on -perform it has been observed that our Read-Only
> scalability is not as good as it could be. One problem being that we
> need to scan the whole of the ProcArray to derive a snapshot, which
> becomes the dominant task with many users.
GetSnapshotData doesn't t
On Thu, May 14, 2009 at 1:28 PM, Tom Lane wrote:
> Simon Riggs writes:
>> In a thread on -perform it has been observed that our Read-Only
>> scalability is not as good as it could be. One problem being that we
>> need to scan the whole of the ProcArray to derive a snapshot, which
>> becomes the d
Robert Haas writes:
> On Thu, May 14, 2009 at 1:28 PM, Tom Lane wrote:
>> GetSnapshotData doesn't take an exclusive lock. Neither does start or
>> end of a read-only transaction. AFAIK there is no reason, and certainly
>> no shred of experimental evidence, to think that ProcArrayLock
>> content
On Thu, 2009-05-14 at 13:28 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > In a thread on -perform it has been observed that our Read-Only
> > scalability is not as good as it could be. One problem being that we
> > need to scan the whole of the ProcArray to derive a snapshot, which
> > becomes
On Thu, May 14, 2009 at 1:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, May 14, 2009 at 1:28 PM, Tom Lane wrote:
>>> GetSnapshotData doesn't take an exclusive lock. Neither does start or
>>> end of a read-only transaction. AFAIK there is no reason, and certainly
>>> no shred of exper
On Thu, 2009-05-14 at 14:06 -0400, Robert Haas wrote:
> Supposing that the patch can be shown to improve performance for
> all-read-only workloads, and supposing further that the patch can be
> shown to have no material negative impact on write-heavy workloads, it
> would also be interesting to t
Hi,
On Fri, May 15, 2009 at 12:36 AM, Simon Riggs wrote:
>
> On Wed, 2009-05-13 at 21:43 +0100, Simon Riggs wrote:
>> On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:
>>
>> > This whole thing can be considered to be a new feature.
>>
>> recovery.conf will contain a new optional parame
Fujii Masao wrote:
On Fri, May 15, 2009 at 12:36 AM, Simon Riggs wrote:
On Wed, 2009-05-13 at 21:43 +0100, Simon Riggs wrote:
On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:
This whole thing can be considered to be a new feature.
recovery.conf will contain a new optional parame
On Fri, 2009-05-15 at 03:49 +0900, Fujii Masao wrote:
> Hi,
>
> On Fri, May 15, 2009 at 12:36 AM, Simon Riggs wrote:
> >
> > On Wed, 2009-05-13 at 21:43 +0100, Simon Riggs wrote:
> >> On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:
> >>
> >> > This whole thing can be considered to b
On May 13, 5:37 pm, gsm...@gregsmith.com (Greg Smith) wrote:
> On Wed, 13 May 2009, Kevin Field wrote:
> > Or would the only way to do this be to actually create a view and then
> > call pg_get_viewdef() and then delete the view?
>
> Just make it a temporary view and then it drops when the session
On May 14, 2:22 pm, Kevin Field wrote:
>
> Something I ran into though when trying to extend this logic to rules:
> for some reason rule definitions are compiled with "create rule x as "
> in front of them, unlike views, which just have everything after the
> "as". I can keep the two parts separa
On May 14, 2:22 pm, Kevin Field wrote:
>
> Something I ran into though when trying to extend this logic to rules:
> for some reason rule definitions are compiled with "create rule x as "
> in front of them, unlike views, which just have everything after the
> "as". I can keep the two parts separa
I've finally committed Simon's recovery_end_command patch, as well as
the changes to pg_standby. There's now smart and fast failover modes,
chosen by the content of the trigger file, smart mode is the default. A
"fast" trigger file is truncated, turning it into a "smart" trigger for
subsequent
Alvaro Herrera writes:
> Heikki Linnakangas wrote:
>> Log Message:
>> ---
>> Add recovery_end_command option to recovery.conf. recovery_end_command
>> is run at the end of archive recovery, providing a chance to do external
>> cleanup. Modify pg_standby so that it no longer removes the tri
Was just running the regression tests under valgrind and aside from the usual
false positives caused by structure padding I noticed this:
==19366== Source and destination overlap in memcpy(0x4BB7FC0, 0x4BB7FC0, 12)
==19366==at 0x4026B12: memcpy (mc_replace_strmem.c:402)
==19366==by 0x8389
Alvaro Herrera wrote:
> Log Message:
> ---
> Translation updates
I just now remembered that we have a new rule about including only >80%
files, so some of these files may need to be removed. Sorry for the
mess :-(
--
Alvaro Herrerahttp://www.CommandPrompt
And lest anyone think Teodor and Oleg are the only ones that have that kind of
problem, here are two in resolve_polymorphic_tupdesc that fire several times
in the regression tests:
==20391== Source and destination overlap in strncpy(0x4BD91DA, 0x4BD91DA, 64)
==20391==at 0x4026CC4: strncpy (mc
Jaime Casanova writes:
> maybe we want to update share/recovery.conf.sample too?
Good catch, done.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
Gregory Stark writes:
> Was just running the regression tests under valgrind and aside from the usual
> false positives caused by structure padding I noticed this:
> ==19366== Source and destination overlap in memcpy(0x4BB7FC0, 0x4BB7FC0, 12)
> ==19366==at 0x4026B12: memcpy (mc_replace_strmem
> Yeah, it looks like the memcpy is sometimes unnecessary because res and
> ptr point to the same place. It might be worth cleaning up just to
> avoid the valgrind warning, but I doubt it would save any noticeable
> number of cycles.
I assume valgrind is warning about it because memcpy's behaviou
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Log Message:
> > ---
> > Translation updates
>
> I just now remembered that we have a new rule about including only >80%
> files, so some of these files may need to be removed. Sorry for the
> mess :-(
This is the list of files that would
Greg Stark writes:
>> Yeah, it looks like the memcpy is sometimes unnecessary because res and
>> ptr point to the same place. It might be worth cleaning up just to
>> avoid the valgrind warning, but I doubt it would save any noticeable
>> number of cycles.
> I assume valgrind is warning about it
Alvaro Herrera writes:
>> I just now remembered that we have a new rule about including only >80%
>> files, so some of these files may need to be removed. Sorry for the
>> mess :-(
> It is a long list of files to remove so I'm not sure about removing them
> hastily for today's beta. We can furt
Simon,
So we can optimize away the scan through the procarray by doing two "if"
tests, one outside of the lock, one inside. In normal running, both will
be optimized away, though in read-only periods we would avoid much work.
How much work would it be to work up a test patch?
--
Josh Berkus
P
Hi,
On Fri, May 15, 2009 at 5:31 AM, Heikki Linnakangas
wrote:
> I've finally committed Simon's recovery_end_command patch, as well as the
> changes to pg_standby. There's now smart and fast failover modes, chosen by
> the content of the trigger file, smart mode is the default. A "fast" trigger
>
Andrew, Tom,
Just wanted to remark on my tests of this feature since the last set of
patches.
First of all, no locking. Yay.
Andrew's latest algorithm tends to result in building indexes on the
same table at the same time. This is excellent for most users; I'm on a
client's site which is
Tom Lane wrote:
Alvaro Herrera writes:
Heikki Linnakangas wrote:
Log Message:
---
Add recovery_end_command option to recovery.conf. recovery_end_command
is run at the end of archive recovery, providing a chance to do external
cleanup. Modify pg_standby so that it no longer removes the
35 matches
Mail list logo
