Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
OK, I put it back, but I still feel we might not need it anymore.
Even if you're willing to believe that the questions will stop once
we have this feature, that won't happen for more than a year.
As a general comment on this,
Tom Lane wrote:
Nobody else seems to have commented, but maybe what this suggests is
we need to be able to individually disable a few of the most expensive
checks. I'm not sure what a reasonable API is for that ... not sure
that I like the thought of a GUC for each one.
I'd really like to
On 14 August 2010 23:22, Dean Rasheed dean.a.rash...@gmail.com wrote:
I'll try to post an updated patch then, with some real trigger code,
I've moved this to a new thread, with a WIP patch that allow 3 types
of triggers to be added to VIEWs:
On Wed, Aug 11, 2010 at 23:10, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 21/07/10 23:40, Magnus Hagander wrote:
I've also set up the git server and the scripts around it, that we can
eventually use. This includes commit email sending, commit policy
enforcement
(no
Robert Haas wrote:
On Sun, Aug 15, 2010 at 11:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I knew there would be a lot of critters crawling out as soon as we
turned over this rock. Which other data-formats-of-the-week shall
we immortalize as core PG types?
PER-encoded ASN.1, for when
Although nobody paid an attention, it seems to me a problem to be fixed.
The attached patch fixes the problem using a simple idea which adds
process_shared_preload_libraries() at PostgresMain() when we launched
it in single-user mode.
Thanks,
(2010/08/05 15:08), KaiGai Kohei wrote:
I found out
Hello
I found so there are not support for tabcomple of psql variables.
Regards
Pavel Stehule
*** ./src/bin/psql/tab-complete.c.orig 2010-08-14 15:59:49.0 +0200
--- ./src/bin/psql/tab-complete.c 2010-08-16 11:44:49.0 +0200
***
*** 2517,2522
--- 2517,2551
On 16 August 2010 10:52, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
I found so there are not support for tabcomple of psql variables.
Regards
Pavel Stehule
s/out of mempry/out of memory/
--
Thom Brown
Registered Linux user: #516935
--
Sent via pgsql-hackers mailing list
2010/8/16 Thom Brown t...@linux.com:
On 16 August 2010 10:52, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
I found so there are not support for tabcomple of psql variables.
Regards
Pavel Stehule
s/out of mempry/out of memory/
ugh - thank you
Pavel
--
Thom Brown
Registered
fixed spelling
Regards
Pavel Stehule
2010/8/16 Pavel Stehule pavel.steh...@gmail.com:
Hello
I found so there are not support for tabcomple of psql variables.
Regards
Pavel Stehule
*** ./src/bin/psql/tab-complete.c.orig 2010-08-14 15:59:49.0 +0200
---
Hi, all
I modified pg_ctl.c to add a new option for Windows service start-type.
new option is -S [auto|demand]
For example, the command can be used under Windows:
pg_ctl register -N s-name -S auto
or
pg_ctl register -N s-name -S demand
The created service will be SERVICE_AUTO_START or
On Mon, Aug 16, 2010 at 4:00 AM, Greg Smith g...@2ndquadrant.com wrote:
Tom Lane wrote:
Nobody else seems to have commented, but maybe what this suggests is
we need to be able to individually disable a few of the most expensive
checks. I'm not sure what a reasonable API is for that ... not
On Mon, Aug 16, 2010 at 12:49 PM, Quan Zongliang
quanzongli...@gmail.com wrote:
Hi, all
I modified pg_ctl.c to add a new option for Windows service start-type.
new option is -S [auto|demand]
For example, the command can be used under Windows:
pg_ctl register -N s-name -S auto
or
pg_ctl
On 05/08/10 13:40, Fujii Masao wrote:
On Wed, Aug 4, 2010 at 12:35 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
There's some race conditions with the signaling. If another process finishes
XLOG flush and sends the signal when a walsender has just finished one
iteration of
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The purpose of this restriction is to ensure an access control decision
using parent's label being also consistent on child tables.
Robert and I understand the concern that you have. The answer, at least
for now, is that we don't agree with
Hi!
According to the decision at the developer meeting, the migration to
git should happen 17-20 Aug. Here's my proposed timeline. This will
obviously affect development work some, and since the original
timeline called for us having already released 9.0 buy then ;)
1. Tuesday evening, around
Attention committers!! ;)
When we migrate to git, we will do a one-time mapping of your old
username to an email address (as was discussed on the developer
meeting in Ottawa earlier this year). This is stamped on every commit
you have ever done, since that's how git works. It's part of the
On Mon, Aug 16, 2010 at 09:05:12AM +0100, Dean Rasheed wrote:
On 14 August 2010 23:22, Dean Rasheed dean.a.rash...@gmail.com wrote:
I'll try to post an updated patch then, with some real trigger
code,
I've moved this to a new thread, with a WIP patch that allow 3 types
of triggers to be
2010/8/5 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
There's a little problem with EXECUTE USING when the parameters are of type
unknown (going back to 8.4 where EXECUTE USING was introduced):
do $$
BEGIN
EXECUTE 'SELECT to_date($1, $2)' USING '17-DEC-80', 'DD-MON-YY';
END;
Magnus Hagander mag...@hagander.net writes:
According to the decision at the developer meeting, the migration to
git should happen 17-20 Aug. Here's my proposed timeline. This will
obviously affect development work some, and since the original
timeline called for us having already released 9.0
* Tom Lane t...@sss.pgh.pa.us [100816 09:58]:
That's not really going to do, especially since it will also lock out
cvs log. I certainly want to do a final update and cvs2cl after the
last commits have happened, and I imagine other people will want that
too. If there were a way to make the
On Mon, Aug 16, 2010 at 15:58, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
According to the decision at the developer meeting, the migration to
git should happen 17-20 Aug. Here's my proposed timeline. This will
obviously affect development work some, and
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 16, 2010 at 15:58, Tom Lane t...@sss.pgh.pa.us wrote:
I can see the point of wanting to be dead certain the repository isn't
changing under you during the data migration. Perhaps we need an agreed
window between last call for commits and
On Mon, Aug 16, 2010 at 9:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
1. Tuesday evening, around 19:00 central european time, which is 17:00
GMT or 12:00 EST, I will freeze the current cvs repository. I will do
this by disabling committer login on that box, so please note that
this will also
Stephen Frost sfr...@snowman.net wrote:
PG doesn't consider child tables to be independent objects when
they're being accessed through the parent. As such, they don't
have their own permissions checking.
I've been thinking about this from the perspective of possible
eventual use by the
On Mon, Aug 16, 2010 at 10:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 16, 2010 at 15:58, Tom Lane t...@sss.pgh.pa.us wrote:
I can see the point of wanting to be dead certain the repository isn't
changing under you during the data
On Mon, Aug 16, 2010 at 16:15, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 16, 2010 at 15:58, Tom Lane t...@sss.pgh.pa.us wrote:
I can see the point of wanting to be dead certain the repository isn't
changing under you during the data migration.
On Mon, Aug 16, 2010 at 9:38 AM, Magnus Hagander mag...@hagander.net wrote:
Attention committers!! ;)
When we migrate to git, we will do a one-time mapping of your old
username to an email address (as was discussed on the developer
meeting in Ottawa earlier this year). This is stamped on
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes:
Yes, and you point out another thing. EXECUTE is a way to bypass the
named prepare statement, to be sure query is replanned each time.
Unfortunely the current implementation of EXECUTE USING is not working
this way.
2010/8/16 KaiGai Kohei kai...@ak.jp.nec.com:
Although nobody paid an attention, it seems to me a problem to be fixed.
The attached patch fixes the problem using a simple idea which adds
process_shared_preload_libraries() at PostgresMain() when we launched
it in single-user mode.
I have no
Andrew Dunstan and...@dunslane.net writes:
If BSON is simply in effect an efficient encoding of JSON, then it's not
clear to me that we would want another type at all. Rather, we might
want to consider storing the data in this supposedly more efficient
format, and maybe also some conversion
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
Many of the features KaiGai has discussed would fit nicely with
court requirements -- and might even be prerequisites for
considering moving security to the database level. Mandating
identical security for all tables in a hierarchy would
This complaint:
http://archives.postgresql.org/pgsql-admin/2010-08/msg00111.php
seems to suggest that this code in CreateLockFile() is not well-thought-out:
if (other_pid = 0)
elog(FATAL, bogus data in lock file \%s\: \%s\,
On Mon, Aug 16, 2010 at 11:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
If BSON is simply in effect an efficient encoding of JSON, then it's not
clear to me that we would want another type at all. Rather, we might
want to consider storing the data in
2010/8/16 Magnus Hagander mag...@hagander.net:
If you want to *change* your email address from the one in the list
attached here, please let me know *ASAP*. At the latest I need to know
this before tuesday evening european time (see separate email about
migration timeline).
Could you change
On Mon, Aug 16, 2010 at 11:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
This complaint:
http://archives.postgresql.org/pgsql-admin/2010-08/msg00111.php
seems to suggest that this code in CreateLockFile() is not well-thought-out:
if (other_pid = 0)
Hey all,
According to
http://www.postgresql.org/docs/9.0/static/errcodes-appendix.html
some error conditions has non-unique *names*. There are:
modifying_sql_data_not_permitted,
prohibited_sql_statement_attempted,
reading_sql_data_not_permitted
from SQL Routine Exception and External Routine
On Mon, Aug 16, 2010 at 11:21 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Aug 16, 2010 at 11:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
If BSON is simply in effect an efficient encoding of JSON, then it's not
clear to me that we would want
On Mon, 2010-08-16 at 11:40 -0400, Christopher Browne wrote:
On Mon, Aug 16, 2010 at 11:21 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Aug 16, 2010 at 11:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
If BSON is simply in effect an efficient
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 16, 2010 at 11:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
We could perhaps address that risk another way: after having written
postmaster.pid, try to read it back to verify that it contains what we
wrote, and abort if not. Then, if we can't
On Mon, 2010-08-16 at 16:19 +0200, Magnus Hagander wrote:
On Mon, Aug 16, 2010 at 16:15, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 16, 2010 at 15:58, Tom Lane t...@sss.pgh.pa.us wrote:
I can see the point of wanting to be dead certain the
Excerpts from Tom Lane's message of lun ago 16 11:18:32 -0400 2010:
We could perhaps address that risk another way: after having written
postmaster.pid, try to read it back to verify that it contains what we
wrote, and abort if not. Then, if we can't read it during startup,
it's okay to
Excerpts from Tom Lane's message of lun ago 16 11:49:51 -0400 2010:
The bottom line here is that it's not clear to me whether changing this
would be a net reliability improvement or not. Maybe better to leave
it alone.
In that case, maybe consider fsync'ing it.
--
Álvaro Herrera
Dmitriy Igrishin dmit...@gmail.com writes:
According to
http://www.postgresql.org/docs/9.0/static/errcodes-appendix.html
some error conditions has non-unique *names*. There are:
modifying_sql_data_not_permitted,
prohibited_sql_statement_attempted,
reading_sql_data_not_permitted
from SQL
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of lun ago 16 11:49:51 -0400 2010:
The bottom line here is that it's not clear to me whether changing this
would be a net reliability improvement or not. Maybe better to leave
it alone.
In that case, maybe
Excerpts from KaiGai Kohei's message of lun ago 16 00:19:54 -0400 2010:
(2010/08/16 11:50), Robert Haas wrote:
When we were developing largeobject access controls, Tom Lane commented
as follows:
* Re: [HACKERS] [PATCH] Largeobject access controls
Alvaro Herrera alvhe...@commandprompt.com writes:
In that case, maybe consider fsync'ing it.
BTW, I see you already proposed that in the thread at
http://archives.postgresql.org/message-id/e3e180dc0905070719q58136caai23fbb777fd3c0...@mail.gmail.com
I'm not sure how come the idea fell through the
Excerpts from Magnus Hagander's message of lun ago 16 09:38:12 -0400 2010:
If you want to *change* your email address from the one in the list
attached here, please let me know *ASAP*. At the latest I need to know
this before tuesday evening european time (see separate email about
migration
On 08/16/2010 06:38 AM, Magnus Hagander wrote:
The current mapping used is the same one as on git.postgresql.org (see
attached file).
Per discussions earlier on this list, we encourage people to use an
email address that is permanent and stable, and does not for example
change if you change
On 8/16/10 8:40 AM, Christopher Browne wrote:
On Mon, Aug 16, 2010 at 11:21 AM, Robert Haasrobertmh...@gmail.com wrote:
On Mon, Aug 16, 2010 at 11:05 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Andrew Dunstanand...@dunslane.net writes:
If BSON is simply in effect an efficient
On 16/08/10 03:35, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
One approach is to handle the conversion from unknown to the right data
type transparently in the backend. Attached patch adds a
coerce-param-hook for fixed params that returns a CoerceViaIO node
On Mon, Aug 16, 2010 at 17:20, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
2010/8/16 Magnus Hagander mag...@hagander.net:
If you want to *change* your email address from the one in the list
attached here, please let me know *ASAP*. At the latest I need to know
this before tuesday
On Sun, Aug 15, 2010 at 11:47 PM, Andrew Dunstan and...@dunslane.net wrote:
If BSON is simply in effect an efficient encoding of JSON, then it's not
clear to me that we would want another type at all. Rather, we might want to
consider storing the data in this supposedly more efficient format,
On 16 August 2010 14:45, David Fetter da...@fetter.org wrote:
Please add this to the next commitfest :)
Done.
Thanks,
Dean
https://commitfest.postgresql.org/action/commitfest_view?id=7
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM:
On 16/08/10 20:17, Joseph Adams wrote:
Also, an idea would be to make json_send and json_recv (binary JSON
send/receive) use BSON rather than JSON-encoded text, as
sending/receiving JSON-encoded text is exactly what text send/receive
do.
The usual reason to use the binary format is
On 15 August 2010 18:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
There are still a number of things left todo:
- extend ALTER VIEW with enable/disable trigger commands
On further reflection, I wonder if the ability to disable VIEW
triggers is needed/wanted at all. I just noticed that
I wrote:
Magnus Hagander mag...@hagander.net writes:
According to the decision at the developer meeting, the migration to
git should happen 17-20 Aug. Here's my proposed timeline. This will
obviously affect development work some, and since the original
timeline called for us having already
Dean Rasheed dean.a.rash...@gmail.com writes:
On 15 August 2010 18:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
There are still a number of things left todo:
- extend ALTER VIEW with enable/disable trigger commands
On further reflection, I wonder if the ability to disable VIEW
triggers
Magnus Hagander mag...@hagander.net writes:
Attached is a ZIP file with the diffs generated when converting the
cvs repo to git based off a cvs snapshot from this morning. It
contains a diff file for every branch and every tag present. (If a
file is missing, that means there were no diffs for
On Mon, Aug 16, 2010 at 1:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Magnus Hagander mag...@hagander.net writes:
According to the decision at the developer meeting, the migration to
git should happen 17-20 Aug. Here's my proposed timeline. This will
obviously affect development work
On Mon, Aug 16, 2010 at 20:11, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Attached is a ZIP file with the diffs generated when converting the
cvs repo to git based off a cvs snapshot from this morning. It
contains a diff file for every branch and every tag
All,
This is something I'd swear we fixed around 8.3.2. However, I'm seeing
it again in production, and was wondering if anyone could remember what
the root cause was and how we fixed it.
The problem is that sometimes (but not the majority of times) autovaccum
with cost_delay is going into a
On Sun, Aug 15, 2010 at 7:44 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
We (Marko, David Fetter and I) discussed on IRC about design of
writeable CTEs. It does and will contain not only syntax but also
miscellaneous specifications, general rules and restrictions. I hope
this will help the
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 16, 2010 at 20:11, Tom Lane t...@sss.pgh.pa.us wrote:
The other thing that I'd like to see some data on is the commit log
entries. Can we produce anything comparable to cvs2cl output from
the test repository?
For a single branch, just
On Mon, Aug 16, 2010 at 20:27, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 16, 2010 at 20:11, Tom Lane t...@sss.pgh.pa.us wrote:
The other thing that I'd like to see some data on is the commit log
entries. Can we produce anything comparable to
Robert Haas robertmh...@gmail.com wrote:
That sounds good, except for the part about nobody doing anything
about the 9.0 open issues. Those issues are:
[four issues listed]
Nobody responded when I asked about this recently, but shouldn't
that list include BUG #5607: memmory leak in ecpg?
On 16 August 2010 18:50, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
On 15 August 2010 18:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
There are still a number of things left todo:
- extend ALTER VIEW with enable/disable trigger commands
On further
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 16, 2010 at 20:27, Tom Lane t...@sss.pgh.pa.us wrote:
Second, does git offer a way to collate matching log entries across
multiple branches?
But what really is the usecase there?
Generating back-branch update release notes, mainly. We
On Mon, Aug 16, 2010 at 20:45, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 16, 2010 at 20:27, Tom Lane t...@sss.pgh.pa.us wrote:
Second, does git offer a way to collate matching log entries across
multiple branches?
But what really is the
Thanks for you answer, Tom!
I've implemented mapping between SQLSTATE codes and C++ exception
classes of my library. And of course, I've resolved the conflict of names
by giving a proper name to my classes.
Regards,
Dmitriy
2010/8/16 Tom Lane t...@sss.pgh.pa.us
Dmitriy Igrishin
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Nobody responded when I asked about this recently, but shouldn't
that list include BUG #5607: memmory leak in ecpg? We have a
patch from Zoltán Böszörményi from before this bug report which
seems to address the issue and which Michael Meskes
Robert Haas robertmh...@gmail.com writes:
That sounds good, except for the part about nobody doing anything
about the 9.0 open issues. Those issues are:
* Backup procedure is wrong? - Nobody's been able to clearly
articulate what the problem is, and according to Fujii Masao it's been
this
On Mon, Aug 16, 2010 at 02:25:50PM -0400, Robert Haas wrote:
On Sun, Aug 15, 2010 at 7:44 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
We (Marko, David Fetter and I) discussed on IRC about design of
writeable CTEs. It does and will contain not only syntax but also
miscellaneous
On 08/16/2010 11:24 AM, Josh Berkus wrote:
All,
This is something I'd swear we fixed around 8.3.2. However, I'm seeing
it again in production, and was wondering if anyone could remember what
the root cause was and how we fixed it.
I've also recently heard a report of vacuum hanging on 8.3.x
I've also recently heard a report of vacuum hanging on 8.3.x on Solaris
Sparc. Any chance you can get a backtrace from a build with debug symbols?
The problem is that we haven't been able to reproduce the bug in
testing. Like I said, it only seems to happen occasionally ... like
maybe once in
Josh Berkus j...@agliodbs.com writes:
This is something I'd swear we fixed around 8.3.2. However, I'm seeing
it again in production, and was wondering if anyone could remember what
the root cause was and how we fixed it.
Hmm, I can't find anything in the 8.3-series CVS logs suggesting that
Robert Haas robertmh...@gmail.com writes:
5. Since I'm hoping Tom will read this, I ran it through filterdiff. :-)
OK, I looked ;-). It mostly looks good, but of course I've got some
opinions...
2. I haven't done anything about moving the definition of
ObjectAddress elsewhere, as Alvaro
On Mon, Aug 16, 2010 at 12:45, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 16, 2010 at 20:27, Tom Lane t...@sss.pgh.pa.us wrote:
Second, does git offer a way to collate matching log entries across
multiple branches?
But what really is the
Alex Hunsaker bada...@gmail.com writes:
How exactly patches get applied into back branches? Has that been
spelled out somewhere? There are a lot of ways to do it. For
instance git.git seems to apply the patch to the earliest branch first
and then merge it on up so that everything can share
On Mon, Aug 16, 2010 at 3:00 PM, David Fetter da...@fetter.org wrote:
There has been previous talk of allowing WITH (COPY ...) and I am
personally of the opinion that it would be nice to be able to do
WITH (EXPLAIN ...). DDL seems like a poor idea.
It may be, but I can see use cases for
On Mon, Aug 16, 2010 at 4:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd be satisfied with a tool that merges commit reports if they have the
same log message and occur at approximately the same time, which is the
heuristic that cvs2cl uses.
So how do you run cvs2cl? Do you run it once in a
On 08/16/2010 12:12 PM, Josh Berkus wrote:
I've also recently heard a report of vacuum hanging on 8.3.x on Solaris
Sparc. Any chance you can get a backtrace from a build with debug symbols?
The problem is that we haven't been able to reproduce the bug in
testing. Like I said, it only
Excerpts from Joe Conway's message of lun ago 16 16:47:19 -0400 2010:
On 08/16/2010 12:12 PM, Josh Berkus wrote:
I've also recently heard a report of vacuum hanging on 8.3.x on Solaris
Sparc. Any chance you can get a backtrace from a build with debug symbols?
The problem is that we
On Mon, Aug 16, 2010 at 04:34:07PM -0400, Robert Haas wrote:
On Mon, Aug 16, 2010 at 3:00 PM, David Fetter da...@fetter.org wrote:
There has been previous talk of allowing WITH (COPY ...) and I am
personally of the opinion that it would be nice to be able to do
WITH (EXPLAIN ...). DDL
Excerpts from Alvaro Herrera's message of lun ago 16 16:58:31 -0400 2010:
I suspect that the problem may lie in the cost_delay rebalance code in
autovacuum.
Hmm, so we have this code:
void
AutoVacuumUpdateDelay(void)
{
if (MyWorkerInfo)
{
VacuumCostDelay =
On 8/15/10 8:47 PM, Andrew Dunstan wrote:
On 08/15/2010 11:03 PM, Tom Lane wrote:
Charles Pritchardch...@jumis.com writes:
I'd originally sent this to Joseph Adams, as he has been working on
adding a JSON datatype.
I've suggested supporting BSON, as there are many client
implementations
Charles Pritchard ch...@jumis.com wrote:
Storing internally as BSON (if it holds up to its premise) would
mean more efficient traversal of internal objects in the future,
if we were to have JSON-related functions/selectors.
How about the fact that not all JSON objects can be represented in
On Mon, Aug 16, 2010 at 14:33, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
How exactly patches get applied into back branches?
There was discussion about that before, but I don't know whether we
really have a solution that will work comfortably.
I don't either,
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 16, 2010 at 4:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd be satisfied with a tool that merges commit reports if they have the
same log message and occur at approximately the same time, which is the
heuristic that cvs2cl uses.
So how do
Alex Hunsaker bada...@gmail.com writes:
On Mon, Aug 16, 2010 at 14:33, Tom Lane t...@sss.pgh.pa.us wrote:
I'd be satisfied with a tool that merges commit reports if they have the
same log message and occur at approximately the same time, which is the
heuristic that cvs2cl uses.
I dont think
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Charles Pritchard ch...@jumis.com wrote:
Storing internally as BSON (if it holds up to its premise) would
mean more efficient traversal of internal objects in the future,
if we were to have JSON-related functions/selectors.
How about the
1;2403;0cOn Mon, Aug 16, 2010 at 05:02:47PM -0500, Kevin Grittner wrote:
Charles Pritchard ch...@jumis.com wrote:
Storing internally as BSON (if it holds up to its premise) would
mean more efficient traversal of internal objects in the future,
if we were to have JSON-related
On Mon, Aug 16, 2010 at 7:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, if it's not just a binary encoding of JSON, I think we can forget
about it ... certainly it won't work in the form I was visualizing.
regards, tom lane
I just read the spec, and BSON has a lot of
(2010/08/16 23:40), Robert Haas wrote:
2010/8/16 KaiGai Koheikai...@ak.jp.nec.com:
Although nobody paid an attention, it seems to me a problem to be fixed.
The attached patch fixes the problem using a simple idea which adds
process_shared_preload_libraries() at PostgresMain() when we launched
Magnus Hagander mag...@hagander.net writes:
According to the decision at the developer meeting, the migration to
git should happen 17-20 Aug. Here's my proposed timeline. This will
obviously affect development work some, and since the original
timeline called for us having already released 9.0
2010/8/17 KaiGai Kohei kai...@ak.jp.nec.com:
I want to kick this job in single-user mode, not normal processing mode,
Does an explicit LOAD work in single-user mode?
I think LOAD just after login works as same as it was preloaded,
unless it allocates shared memory.
--
Itagaki Takahiro
--
(2010/08/17 9:02), Itagaki Takahiro wrote:
2010/8/17 KaiGai Koheikai...@ak.jp.nec.com:
I want to kick this job in single-user mode, not normal processing mode,
Does an explicit LOAD work in single-user mode?
I think LOAD just after login works as same as it was preloaded,
unless it
Another idea that comes to mind is that you have vacuum_cost_page_dirty
set to an unreasonably large value, so that autovac is blocking whenever
it has to write even one page.
Nope. Default. And total cost was raised to 1000.
--
-- Josh Berkus
(2010/08/16 22:14), Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The purpose of this restriction is to ensure an access control decision
using parent's label being also consistent on child tables.
Robert and I understand the concern that you have. The answer,
but BSON pidgenholes numeric values to either double, int32, int64, or
a 12-byte MongoDB Object ID. Thus, for people who expect JSON to be
able to hold arbitrary-precision numbers (which the JSON data type in
my patch can), using BSON for transfer or storage will violate that
expectation.
1 - 100 of 124 matches
Mail list logo
