Tom Lane wrote:
Bruce Momjian 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, I've gotten two
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 b
On 14 August 2010 23:22, Dean Rasheed 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:
http://archives.postgresql.org/pgsql-hackers/2010-08/msg01030.php
Comments
On Wed, Aug 11, 2010 at 23:10, Heikki Linnakangas
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 merge commits, correct author
Robert Haas wrote:
On Sun, Aug 15, 2010 at 11:03 PM, Tom Lane 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 you really need somet
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 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 (pgsql-hackers@postg
2010/8/16 Thom Brown :
> On 16 August 2010 10:52, Pavel Stehule 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 Linux user: #
fixed spelling
Regards
Pavel Stehule
2010/8/16 Pavel Stehule :
> 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 13
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 SERVIC
On Mon, Aug 16, 2010 at 4:00 AM, Greg Smith 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 sure
>> that
On Mon, Aug 16, 2010 at 12:49 PM, Quan Zongliang
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 register -N "s-
On 05/08/10 13:40, Fujii Masao wrote:
On Wed, Aug 4, 2010 at 12:35 AM, Heikki Linnakangas
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 its main loop, walsender will reset
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 wit
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 19:
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
commit
On Mon, Aug 16, 2010 at 09:05:12AM +0100, Dean Rasheed wrote:
> On 14 August 2010 23:22, Dean Rasheed 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:
>
2010/8/5 Heikki Linnakangas :
> 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;
> $$;
> ERROR: failed to find c
Magnus Hagander 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 buy then ;)
Co
* Tom Lane [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 repository r
On Mon, Aug 16, 2010 at 15:58, Tom Lane wrote:
> Magnus Hagander 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 cal
Magnus Hagander writes:
> On Mon, Aug 16, 2010 at 15:58, Tom Lane 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 the actual lock-out.
> To pre
On Mon, Aug 16, 2010 at 9:58 AM, Tom Lane 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 make it imposs
>Stephen Frost 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 Wisconsin Courts, a
On Mon, Aug 16, 2010 at 10:15 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 16, 2010 at 15:58, Tom Lane 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
On Mon, Aug 16, 2010 at 16:15, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 16, 2010 at 15:58, Tom Lane 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 la
On Mon, Aug 16, 2010 at 9:38 AM, Magnus Hagander 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 every commit
> you
=?ISO-8859-1?Q?C=E9dric_Villemain?= 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.
Uh ... what do you base that
2010/8/16 KaiGai Kohei :
> 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 confidence at all
Andrew Dunstan 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 routines.
Hmm,
* 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 woul
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 wrote:
> Andrew Dunstan 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
>>
2010/8/16 Magnus Hagander :
> 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 my address to ita
On Mon, Aug 16, 2010 at 11:18 AM, Tom Lane 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)
> elog(FATAL, "bogus
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 Excep
On Mon, Aug 16, 2010 at 11:21 AM, Robert Haas wrote:
> On Mon, Aug 16, 2010 at 11:05 AM, Tom Lane wrote:
>> Andrew Dunstan 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 con
On Mon, 2010-08-16 at 11:40 -0400, Christopher Browne wrote:
> On Mon, Aug 16, 2010 at 11:21 AM, Robert Haas wrote:
> > On Mon, Aug 16, 2010 at 11:05 AM, Tom Lane wrote:
> >> Andrew Dunstan writes:
> >>> If BSON is simply in effect an efficient encoding of JSON, then it's not
> >>> clear to me t
Robert Haas writes:
> On Mon, Aug 16, 2010 at 11:18 AM, Tom Lane 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 read it during startup,
>> it's
On Mon, 2010-08-16 at 16:19 +0200, Magnus Hagander wrote:
> On Mon, Aug 16, 2010 at 16:15, Tom Lane wrote:
> > Magnus Hagander writes:
> >> On Mon, Aug 16, 2010 at 15:58, Tom Lane wrote:
> >>> I can see the point of wanting to be dead certain the repository isn't
> >>> changing under you during
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 a
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
The Pos
Dmitriy Igrishin 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 Routine Except
Alvaro Herrera 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 consider fsync'ing it
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
> http://marc.info/?l=pgsql-hackers&m=
Alvaro Herrera 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 cracks, but we should
sur
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
> migratio
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 c
On 8/16/10 8:40 AM, Christopher Browne wrote:
On Mon, Aug 16, 2010 at 11:21 AM, Robert Haas wrote:
On Mon, Aug 16, 2010 at 11:05 AM, Tom Lane wrote:
Andrew Dunstan writes:
If BSON is simply in effect an efficient encoding of JSON, then it's not
clear to me that we would wa
On 16/08/10 03:35, Tom Lane wrote:
Heikki Linnakangas 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 to
convert the param to the right typ
On Mon, Aug 16, 2010 at 17:20, Itagaki Takahiro
wrote:
> 2010/8/16 Magnus Hagander :
>> 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 abo
On Sun, Aug 15, 2010 at 11:47 PM, Andrew Dunstan 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, and
> maybe also
On 16 August 2010 14:45, David Fetter wrote:
> Please add this to the next commitfest :)
>
Done.
Thanks,
Dean
> https://commitfest.postgresql.org/action/commitfest_view?id=7
>
> Cheers,
> David.
> --
> David Fetter http://fetter.org/
> Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
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 performance,
On 15 August 2010 18:38, Dean Rasheed 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 while it is
possible to dis
I wrote:
> Magnus Hagander 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
Dean Rasheed writes:
> On 15 August 2010 18:38, Dean Rasheed 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.
AFAIK the only r
Magnus Hagander 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 that branch/tag)
On Mon, Aug 16, 2010 at 1:47 PM, Tom Lane wrote:
> I wrote:
>> Magnus Hagander 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 origina
On Mon, Aug 16, 2010 at 20:11, Tom Lane wrote:
> Magnus Hagander 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 missin
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 path
On Sun, Aug 15, 2010 at 7:44 AM, Hitoshi Harada 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 patch reviews and
Magnus Hagander writes:
> On Mon, Aug 16, 2010 at 20:11, Tom Lane 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 do "git log ", e.g. "git log
>
On Mon, Aug 16, 2010 at 20:27, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 16, 2010 at 20:11, Tom Lane 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?
>
>>
Robert Haas 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"? We have a
patc
On 16 August 2010 18:50, Tom Lane wrote:
> Dean Rasheed writes:
>> On 15 August 2010 18:38, Dean Rasheed 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
>> t
Magnus Hagander writes:
> On Mon, Aug 16, 2010 at 20:27, Tom Lane 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 usually do that
first for the ne
On Mon, Aug 16, 2010 at 20:45, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 16, 2010 at 20:27, Tom Lane 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 r
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
> Dmitriy Igrishin writes:
> > According to
> > ht
"Kevin Grittner" 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 said "Feel free
> to
Robert Haas 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 way since 8.2.
Ju
On Mon, Aug 16, 2010 at 02:25:50PM -0400, Robert Haas wrote:
> On Sun, Aug 15, 2010 at 7:44 AM, Hitoshi Harada 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
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
> 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 i
Josh Berkus 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
there was a post-8
Robert Haas 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 suggested, because I'm
On Mon, Aug 16, 2010 at 12:45, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 16, 2010 at 20:27, Tom Lane 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 r
Alex Hunsaker 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 the same
> com
On Mon, Aug 16, 2010 at 3:00 PM, David Fetter 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 partitioning.
On Mon, Aug 16, 2010 at 4:33 PM, Tom Lane 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 while and save the
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 on
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 i
On Mon, Aug 16, 2010 at 04:34:07PM -0400, Robert Haas wrote:
> On Mon, Aug 16, 2010 at 3:00 PM, David Fetter 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
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 = M
On 8/15/10 8:47 PM, Andrew Dunstan wrote:
On 08/15/2010 11:03 PM, Tom Lane wrote:
Charles Pritchard 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
available,
I knew
Charles Pritchard 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
BSON (if the
On Mon, Aug 16, 2010 at 14:33, Tom Lane wrote:
> Alex Hunsaker 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, not being a -commiter I don't
Robert Haas writes:
> On Mon, Aug 16, 2010 at 4:33 PM, Tom Lane 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
Alex Hunsaker writes:
> On Mon, Aug 16, 2010 at 14:33, Tom Lane 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 it would be to hard to code
"Kevin Grittner" writes:
> Charles Pritchard 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
1;2403;0cOn Mon, Aug 16, 2010 at 05:02:47PM -0500, Kevin Grittner wrote:
> Charles Pritchard 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.
>
On Mon, Aug 16, 2010 at 7:24 PM, Tom Lane 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 bells and whi
(2010/08/16 23:40), Robert Haas wrote:
> 2010/8/16 KaiGai Kohei:
>> 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 si
Magnus Hagander 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 buy then ;)
>
2010/8/17 KaiGai Kohei :
> 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
--
Sent via pgsql-hackers
(2010/08/17 9:02), Itagaki Takahiro wrote:
> 2010/8/17 KaiGai Kohei:
>> 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 memor
> 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
> 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
> expectatio
1 - 100 of 125 matches
Mail list logo
