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 beta1
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
wjzeng zwjing_...@hotmail.com wrote:
In pgsql/src/interfaces/libpq/fe-exec.c, there are two variables:
-
static int static_client_encoding = PG_SQL_ASCII;
static bool static_std_strings = false;
If enable_thread_safety is no, how to insure libpq(dll/so) for
thread-safety?
Use
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
Hi,
Sorry for the delay.
On Thu, May 14, 2009 at 6:04 AM, Simon Riggs si...@2ndquadrant.com 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
Hi,
Cristina M cristina.ma...@yahoo.com 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)
niranja...@nsn.com 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
Hi,
On Thu, May 14, 2009 at 8:16 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
On Mon, May 4, 2009 at 11:07 PM, K, Niranjan (NSN - IN/Bangalore)
niranja...@nsn.com wrote:
Hi,
Re-opening the discussion related to triggers to promote standby server.
In the earlier dicussion, there were 2
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 beta1
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 possibility
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
Simon Riggs si...@2ndquadrant.com 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.
On Thu, May 14, 2009 at 1:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com writes:
On Thu, May 14, 2009 at 1:28 PM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, 2009-05-14 at 13:28 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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,
On Thu, May 14, 2009 at 1:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, May 14, 2009 at 1:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
GetSnapshotData doesn't take an exclusive lock. Neither does start or
end of a read-only transaction. AFAIK there
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
Hi,
On Fri, May 15, 2009 at 12:36 AM, Simon Riggs si...@2ndquadrant.com 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
Fujii Masao wrote:
On Fri, May 15, 2009 at 12:36 AM, Simon Riggs si...@2ndquadrant.com 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
On Fri, 2009-05-15 at 03:49 +0900, Fujii Masao wrote:
Hi,
On Fri, May 15, 2009 at 12:36 AM, Simon Riggs si...@2ndquadrant.com 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
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 ends.
On May 14, 2:22 pm, Kevin Field kevinjamesfi...@gmail.com 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
On May 14, 2:22 pm, Kevin Field kevinjamesfi...@gmail.com 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
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 alvhe...@commandprompt.com 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
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
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 Herrera
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
Jaime Casanova jcasa...@systemguards.com.ec 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:
Gregory Stark st...@enterprisedb.com 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
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 behaviour
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 be removed
Greg Stark st...@enterprisedb.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
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
Hi,
On Fri, May 15, 2009 at 5:31 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
36 matches
Mail list logo
