Hi,
> At the moment, all you've done is show examples of how Oracle does
>> partitioning and restate my requirements document, significant chunks
>> completely verbatim. If you do that I think it fair to ask for a
>> specific credit on that. But even so, thank you for the compliment.
>>
>> It was
Jeff Davis wrote:
On Wed, 2008-12-17 at 17:10 -0600, Kenneth Marshall wrote:
On Wed, Dec 17, 2008 at 06:07:41PM -0500, Jaime Casanova wrote:
On Wed, Dec 17, 2008 at 5:47 PM, Kenneth Marshall wrote:
Rebuilding a hash index for the case
for which it is preferred (large, large tables) would be e
Robert,
You do not need to use qgen.exe to generate queries as you are not
running the TPC-H benchmark test. Attached is an example of the 22
sample TPC-H queries according to the benchmark.
We have not tested using the TPC-H queries for this particular patch and
only use the TPC-H database as
On Thu, Dec 18, 2008 at 12:04:00AM -0500, Emmanuel Cecchet wrote:
> Hi David,
>
> Could you explain me what do you mean by putting a partition offline?
I sometimes use pg_dump to archive a partition, then drop that table,
bringing it offline, but if needed, it's there in the archive, ready
to rest
Simon Riggs wrote:
> Latest version of rmgr hooks patch for later review in current
> commitfest.
> (Minor update to CVS HEAD).
It doesn't work on Window (EXEC_BACKEND platform) because
shared_preload_libraries are not loaded in startup process.
So, there are no timing to initialize rmgr_hook.
Hi Robert,
Thanks all for the time you are spending commenting on this during this
busy Commit Fest.
I am not a fan of the proposed syntax. It is conceptually similar to
what we already do with constraints, but invents a whole new syntax to
no obvious benefit that I can see.
Actually I did n
Hi David,
Could you explain me what do you mean by putting a partition offline?
I am just starting to get familiar with the use cases at Aster Data
Systems that are probably not covering all the requirements that
everyone has seen so far in the field. So I am eager to learn and try to
integrat
Simon,
At the moment, all you've done is show examples of how Oracle does
partitioning and restate my requirements document, significant chunks
completely verbatim. If you do that I think it fair to ask for a
specific credit on that. But even so, thank you for the compliment.
It was not my inte
Dr. Lawrence:
I'm still working on reviewing this patch. I've managed to load the
sample TPCH data from tpch1g1z.zip after changing the line endings to
UNIX-style and chopping off the trailing vertical bars. (If anyone is
interested, I have the results of pg_dump | bzip2 -9 on the resulting
data
Hi,
On Thu, Dec 18, 2008 at 4:49 AM, Robert Lor wrote:
> Alvaro Herrera wrote:
>>
>> But there are 5 callers of XLogWrite ... why aren't the other ones being
>> tracked too?
>>
>>
>
> This probe originally came from Simon, so it can't possibly be wrong :-)
>
> My understanding is that we only wan
"Fujii Masao" wrote:
> > ISTM we should offer a simple boolean function which says whether
> > streaming replication is connected or not. If people want to defer
> > connection until replication is connected then they can create a more
> > complex startup script, just as they do to ensure correc
Hi,
On Thu, Dec 18, 2008 at 11:19 AM, Simon Riggs wrote:
>
> On Thu, 2008-12-18 at 11:03 +0900, Fujii Masao wrote:
>> Hi,
>>
>> Thanks for the helpful comments!
>>
>> On Wed, Dec 17, 2008 at 8:50 PM, Simon Riggs wrote:
>> >
>> > On Wed, 2008-12-17 at 12:07 +0900, Fujii Masao wrote:
>> >
>> >> OK
Hi,
On Thu, Dec 18, 2008 at 9:55 AM, Simon Riggs wrote:
>
> On Tue, 2008-12-16 at 14:27 +0900, Fujii Masao wrote:
>
>> I'd like to clarify the coding TODO of Synch Rep for 8.4. If indispensable
>> TODO item is not listed, please feel free to let me know.
>
>> Since there are many TODO items, I'm
I created a function for testing the patch, but when i run following command,
the function always raise an exception
select test_in_params('first');
ERROR: plpython: function "test_in_params" failed
DETAIL: exceptions.NameError: global name 'first' is not defined
here is the script of fucntio
Michael Meskes wrote:
> It appears to work for other tests though, but your
> regression.diffs suggests it doesn't here. Could you please check this by
> checking out the changes, re-running "make checktcp" and checking whether the
> regression.diffs file changes?
I re-ran the test and got 'sou
On Wed, 2008-12-17 at 23:28 -0300, Alvaro Herrera wrote:
> Hmm, it doesn't seem like you understood my suggestion ... basically I'm
> saying that a hash index insert/delete should put out this WAL record:
>
> HEAP update address-of-pg_index-tuple set indisvalid=false
>
> (I'm just guessing at i
On Wed, 2008-12-17 at 23:32 -0300, Alvaro Herrera wrote:
> Simon Riggs escribió:
>
> > Please let me know how I can make the reviewer's job easier. Diagrams,
> > writeups, whatever. Thanks,
>
> A link perhaps?
There is much confusion on this point for which I'm very sorry.
I originally wrote "
Simon Riggs escribió:
> Please let me know how I can make the reviewer's job easier. Diagrams,
> writeups, whatever. Thanks,
A link perhaps?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers m
Simon Riggs wrote:
>
> On Wed, 2008-12-17 at 21:23 -0300, Alvaro Herrera wrote:
> > Maybe we should add a WAL record that's the physical representation for
> > "mark this index invalid", and have any transaction that modifies a hash
> > index write that to WAL. It should be simple code to write,
On Wed, 2008-12-17 at 18:20 -0800, Jeff Davis wrote:
> On Wed, 2008-12-17 at 17:10 -0600, Kenneth Marshall wrote:
> > On Wed, Dec 17, 2008 at 06:07:41PM -0500, Jaime Casanova wrote:
> > > On Wed, Dec 17, 2008 at 5:47 PM, Kenneth Marshall wrote:
> > > > Rebuilding a hash index for the case
> > > >
On Wed, 2008-12-17 at 21:26 +, Simon Riggs wrote:
> Hot Standby won't work with hash indexes because they are
> non-recoverable.
>
> We have a number of ways of dealing with this:
> 2. Specific Solution: make hashcostestimate() massively increase cost of
> scans during recovery so that they
On Wed, 2008-12-17 at 18:09 -0800, Josh Berkus wrote:
> Are we really releasing an index type without recoverability for 8.4?
> Will this be in /contrib?
Worse than that, I'm talking about hash indexes (which are already here,
without WAL)
I would not contemplate a new index type without WAL.
On Wed, 2008-12-17 at 17:10 -0600, Kenneth Marshall wrote:
> On Wed, Dec 17, 2008 at 06:07:41PM -0500, Jaime Casanova wrote:
> > On Wed, Dec 17, 2008 at 5:47 PM, Kenneth Marshall wrote:
> > > Rebuilding a hash index for the case
> > > for which it is preferred (large, large tables) would be excrut
On Thu, 2008-12-18 at 11:03 +0900, Fujii Masao wrote:
> Hi,
>
> Thanks for the helpful comments!
>
> On Wed, Dec 17, 2008 at 8:50 PM, Simon Riggs wrote:
> >
> > On Wed, 2008-12-17 at 12:07 +0900, Fujii Masao wrote:
> >
> >> OK. I will extend synchronous_replication, make walsender send XLOG
> >
All,
Are we really releasing an index type without recoverability for 8.4?
Will this be in /contrib?
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
Thanks for the helpful comments!
On Wed, Dec 17, 2008 at 8:50 PM, Simon Riggs wrote:
>
> On Wed, 2008-12-17 at 12:07 +0900, Fujii Masao wrote:
>
>> OK. I will extend synchronous_replication, make walsender send XLOG
>> with synchronization mode flag and make walreceiver perform according
>>
On Thu, 2008-11-20 at 10:10 +, Simon Riggs wrote:
> On Thu, 2008-11-20 at 15:19 +0530, Pavan Deolasee wrote:
>
> > Do you intend to split the patch into smaller pieces ? The latest hot
> > standby patch is almost 10K+ lines. Splitting that would definitely
> > help the review process.
>
> If
> On Tue, 2008-12-16 at 21:48 -0500, Emmanuel Cecchet wrote:
> I'm glad you're looking to work on it. I have a few comments.
> Others have suggested different syntax also, so you need to come up with
> arguments in favour of this particular syntax.
I am not a fan of the proposed syntax. It is con
On Wed, 2008-12-17 at 21:23 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> >
> > On Wed, 2008-12-17 at 18:01 -0500, Jaime Casanova wrote:
> > > On Wed, Dec 17, 2008 at 5:54 PM, Simon Riggs
> > > wrote:
> > >
> > > > We don't yet have a mechanism for an
> > > > index AM to say "damn, this
On Tue, 2008-12-16 at 14:27 +0900, Fujii Masao wrote:
> I'd like to clarify the coding TODO of Synch Rep for 8.4. If indispensable
> TODO item is not listed, please feel free to let me know.
> Since there are many TODO items, I'm worried about the deadline.
> When is the deadline of this commit
Simon Riggs wrote:
>
> On Wed, 2008-12-17 at 18:01 -0500, Jaime Casanova wrote:
> > On Wed, Dec 17, 2008 at 5:54 PM, Simon Riggs wrote:
> >
> > > We don't yet have a mechanism for an
> > > index AM to say "damn, this index is screwed up, don't use it".
> >
> > mark pg_index.indisvalid and/or pg
2008/12/18 Pavel Stehule :
> 2008/12/18 Tom Lane :
>> "Pavel Stehule" writes:
>>> 2008/12/17 Tom Lane :
Experimenting with the revised code, I found a curious case that might
be worth worrying about. Consider the example that started all this:
>>
>>> do you remember on request for using
2008/12/18 Tom Lane :
> "Pavel Stehule" writes:
>> 2008/12/17 Tom Lane :
>>> Experimenting with the revised code, I found a curious case that might
>>> be worth worrying about. Consider the example that started all this:
>
>> do you remember on request for using "default" keyword in funccall?
>>
"Pavel Stehule" writes:
> 2008/12/17 Tom Lane :
>> Experimenting with the revised code, I found a curious case that might
>> be worth worrying about. Consider the example that started all this:
> do you remember on request for using "default" keyword in funccall?
> This should be solution. In vi
On 12/16/08, Bruce Momjian wrote:
> Would someone who understand pgcrypto please review this?
> Marc Munro wrote:
> > I am attaching a patch to eliminate duplicate b64_encode and decode
> > functions from pgcrypto, and to expose those functions for use by
> > add-ins (I want to use them in Ve
2008/12/17 Tom Lane :
> I wrote:
>> * Two functions that could match a given call after adding defaults
>> are considered ambiguous only if they would add the same number of
>> defaults; otherwise we prefer the one with fewer parameters. This
>> generalizes the rule that an exact match (no default
"Pavel Stehule" writes:
> 2008/12/17 Gregory Stark :
>> My inclination would be to say zero arguments is zero arguments and you get a
>> zero-length array. We could eliminate the problem with anyelement by saying
>> the variadic argument can't be the only polymorphic argument.
> I disagree. Polym
2008/12/17 Gregory Stark :
> Tom Lane writes:
>
>> Peter Eisentraut writes:
>>> On Wednesday 17 December 2008 20:50:22 Tom Lane wrote:
The behavior at zero arguments is
certainly a judgment call, but it seems to me that we'll wind up with
more warts and less flexibility if we try t
On Wed, 2008-12-17 at 18:01 -0500, Jaime Casanova wrote:
> On Wed, Dec 17, 2008 at 5:54 PM, Simon Riggs wrote:
>
> > We don't yet have a mechanism for an
> > index AM to say "damn, this index is screwed up, don't use it".
> >
>
> mark pg_index.indisvalid and/or pg_index.indisready to false in t
On Wed, Dec 17, 2008 at 05:10:40PM -0600, Kenneth Marshall wrote:
> On Wed, Dec 17, 2008 at 06:07:41PM -0500, Jaime Casanova wrote:
> > On Wed, Dec 17, 2008 at 5:47 PM, Kenneth Marshall wrote:
> > > Rebuilding a hash index for the case
> > > for which it is preferred (large, large tables) would be
On Wed, Dec 17, 2008 at 06:07:41PM -0500, Jaime Casanova wrote:
> On Wed, Dec 17, 2008 at 5:47 PM, Kenneth Marshall wrote:
> > Rebuilding a hash index for the case
> > for which it is preferred (large, large tables) would be excrutiating.
> >
>
> there's such a situation?
>
As of 8.4, yes.
Ken
On Wed, Dec 17, 2008 at 5:47 PM, Kenneth Marshall wrote:
> Rebuilding a hash index for the case
> for which it is preferred (large, large tables) would be excrutiating.
>
there's such a situation?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sist
On Wed, Dec 17, 2008 at 10:58:11PM +, Simon Riggs wrote:
>
> On Wed, 2008-12-17 at 16:47 -0600, Kenneth Marshall wrote:
>
> > I think having your index survive a server power outage or other
> > crash is a very good thing. Rebuilding a hash index for the case
> > for which it is preferred (la
On Wed, Dec 17, 2008 at 5:54 PM, Simon Riggs wrote:
> We don't yet have a mechanism for an
> index AM to say "damn, this index is screwed up, don't use it".
>
mark pg_index.indisvalid and/or pg_index.indisready to false in the
hot standby node?
--
Atentamente,
Jaime Casanova
Soporte y capacita
On Wed, 2008-12-17 at 16:47 -0600, Kenneth Marshall wrote:
> I think having your index survive a server power outage or other
> crash is a very good thing. Rebuilding a hash index for the case
> for which it is preferred (large, large tables) would be excrutiating.
Completely agree.
We may be o
On Wed, 2008-12-17 at 17:42 -0500, Jaime Casanova wrote:
> On Wed, Dec 17, 2008 at 4:26 PM, Simon Riggs wrote:
> > Hot Standby won't work with hash indexes because they are
> > non-recoverable.
> >
> > We have a number of ways of dealing with this:
> >
>
> i don't see a reason for inventing the
I wrote:
> * Two functions that could match a given call after adding defaults
> are considered ambiguous only if they would add the same number of
> defaults; otherwise we prefer the one with fewer parameters. This
> generalizes the rule that an exact match (no defaults) is preferred
> over one t
will see, may be it's needed to update the patch
Ibrar Ahmed wrote:
Hi Teodor Sigaev,
I am getting server crash in contrib regression. May be I am doing
something wrong here. Regression diff is attached.
BTW these queries work fine outside the regression.
--
Ibrar Ahmed
EnterpriseDB
On Wed, Dec 17, 2008 at 05:42:41PM -0500, Jaime Casanova wrote:
> On Wed, Dec 17, 2008 at 4:26 PM, Simon Riggs wrote:
> > Hot Standby won't work with hash indexes because they are
> > non-recoverable.
> >
> > We have a number of ways of dealing with this:
> >
>
> i don't see a reason for inventin
On Wed, Dec 17, 2008 at 4:26 PM, Simon Riggs wrote:
> Hot Standby won't work with hash indexes because they are
> non-recoverable.
>
> We have a number of ways of dealing with this:
>
i don't see a reason for inventing the wheel, we don't have wal for
hash indexes because makes those more slow wi
On Tue, 2008-12-16 at 21:48 -0500, Emmanuel Cecchet wrote:
> I have put a first draft of the wiki page dedicated to the table
> partitioning development at
> http://wiki.postgresql.org/wiki/Table_partitioning
>
> The page is still incomplete and need much more work but it should be a
> good s
Hot Standby won't work with hash indexes because they are
non-recoverable.
We have a number of ways of dealing with this:
1. Workaround: Implement WAL for hash indexes
2. Specific Solution: make hashcostestimate() massively increase cost of
scans during recovery so that they will very seldom be
Pldebugger uses its own PLUGIN implementation that is ok for make utility but
when we try to compile the code on Windows Perl build scripts fail because it
don’t understand Makefile without pgxs.mk variables. If we add plugin logic in
pgxs.mk and windows Perl build scripts , it would be simple
On Wed, 2008-12-17 at 15:21 +, Simon Riggs wrote:
> http://wiki.postgresql.org/wiki/Hot_Standby
>
> now contains a link to latest version of this patch. This is still at
> "v5", just brought forward to CVS HEAD.
>
> I will be doing further work on the patch from here and will reply to
> this
Tom Lane writes:
> Peter Eisentraut writes:
>> On Wednesday 17 December 2008 20:50:22 Tom Lane wrote:
>>> The behavior at zero arguments is
>>> certainly a judgment call, but it seems to me that we'll wind up with
>>> more warts and less flexibility if we try to make the system install a
>>> def
Alvaro Herrera wrote:
But there are 5 callers of XLogWrite ... why aren't the other ones being
tracked too?
This probe originally came from Simon, so it can't possibly be wrong :-)
My understanding is that we only want to track the XLogWrite when
advancing to the next buffer page, and if
On Tue, Dec 16, 2008 at 09:48:35PM -0500, Emmanuel Cecchet wrote:
> Hi all,
>
> I have put a first draft of the wiki page dedicated to the table
> partitioning development at
> http://wiki.postgresql.org/wiki/Table_partitioning
>
> The page is still incomplete and need much more work but it should
Has anyone ever managed to get uuid generation working on FreeBSD?
There seems to be no way to build contrib/uuid-ossp successfully,
and no apparent agreement anywhere as to whether this is problem
with pg or with the misc/ossp-uuid port.
(I tried this, without success, a couple of weeks back in r
Latest version of rmgr hooks patch for later review in current
commitfest.
(Minor update to CVS HEAD).
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Index: src/backend/access/transam/rmgr.c
==
Peter Eisentraut writes:
> On Wednesday 17 December 2008 20:50:22 Tom Lane wrote:
>> The behavior at zero arguments is
>> certainly a judgment call, but it seems to me that we'll wind up with
>> more warts and less flexibility if we try to make the system install a
>> default behavior for that cas
On Wednesday 17 December 2008 20:50:22 Tom Lane wrote:
> The behavior at zero arguments is
> certainly a judgment call, but it seems to me that we'll wind up with
> more warts and less flexibility if we try to make the system install a
> default behavior for that case.
Maybe we'll just let it be f
Peter Eisentraut writes:
> Another point against that: If you wanted something else besides an empty
> array as "default", you can handle that inside the function body by just
> looking at how many arguments were passed. Using the default mechanism
> provides no added functionality.
Well, the
Jeff Davis writes:
> On Tue, 2008-12-16 at 19:07 -0500, Tom Lane wrote:
>> ISTM one could make a pretty good argument that this last case should
>> succeed, producing an empty-array argument.
> We had a similar discussion before, and you replied here:
> http://archives.postgresql.org/pgsql-patche
On Wednesday 17 December 2008 06:03:06 Tom Lane wrote:
> and it leaves the door open for someone to use something
> besides an empty array as the default. (Who are we to say that such a
> thing is never useful? NULL seems like a possibly useful default for
> instance.)
Another point against that
Jeff Davis writes:
> Previous discussion link:
> http://archives.postgresql.org/pgsql-patches/2008-07/msg00149.php
> You can make either mechanism do what you want by defining the right set
> of functions. If a minimum of one argument per variadic parameter is
> required, you can work around it b
On Tue, 2008-12-16 at 19:07 -0500, Tom Lane wrote:
> regression=# select fv(1);
> ERROR: function fv(integer) does not exist
> LINE 1: select fv(1);
>^
> HINT: No function matches the given name and argument types. You might need
> to add explicit type casts.
>
> ISTM one could
Hi Teodor Sigaev,
I am getting server crash in contrib regression. May be I am doing something
wrong here. Regression diff is attached.
BTW these queries work fine outside the regression.
--
Ibrar Ahmed
EnterpriseDB http://www.enterprisedb.com
regression.diffs
Description: Binary data
On Wed, 2008-12-17 at 19:43 +0200, Peter Eisentraut wrote:
> That looks like a bug to me. Anything that you can do with 1 to N items
> should also work for zero.
>
Previous discussion link:
http://archives.postgresql.org/pgsql-patches/2008-07/msg00149.php
You can make either mechanism do what
"Pavel Stehule" writes:
> 2008/12/17 Peter Eisentraut :
>> That looks like a bug to me. Anything that you can do with 1 to N items
>> should also work for zero.
> no, when we discused about variadic functions we defined, so variadic
> parameter should not be empty Please, look to archive.
Yeah,
2008/12/17 Peter Eisentraut :
> On Wednesday 17 December 2008 02:07:35 Tom Lane wrote:
>> Oh, and another thing --- should variadic parameters be defaultable?
>> The current patch doesn't allow it but it looks more like an oversight
>> than anything that was thought through. The boundary case for
On Wednesday 17 December 2008 06:03:06 Tom Lane wrote:
> This method
> eliminates the discrepancy between anyarray and other types of variadic
> parameters, and it leaves the door open for someone to use something
> besides an empty array as the default. (Who are we to say that such a
> thing is n
On Wednesday 17 December 2008 06:03:06 Tom Lane wrote:
> "Brendan Jurd" writes:
> > So if I had these two functions ...
> >
> > var1(a int, b variadic int[])
> > var2(a int, b variadic anyarray)
> >
> > ... it would be okay to write var1(8), which resolves as var1(8,
> > array[]::int[]). But if I
On Wednesday 17 December 2008 02:07:35 Tom Lane wrote:
> Oh, and another thing --- should variadic parameters be defaultable?
> The current patch doesn't allow it but it looks more like an oversight
> than anything that was thought through. The boundary case for variadic
> parameters is a bit weir
Robert Lor escribió:
> Fujii Masao wrote:
>> Hi,
>>
>> On Wed, Dec 17, 2008 at 4:53 AM, Robert Lor wrote:
>> Why is TRACE_POSTGRESQL_WAL_BUFFER_WRITE_START/DONE called
>> only in AdvanceXLInsertBuffer? We can trace only a part of WAL buffer write?
>>
> The intention of these probes is to deter
Fujii Masao wrote:
Hi,
On Wed, Dec 17, 2008 at 4:53 AM, Robert Lor wrote:
@@ -1313,12 +1318,14 @@ AdvanceXLInsertBuffer(bool new_segment)
* Have to write buffers while holding insert
lock. This is
* not good, so only write as m
On Wed, Dec 17, 2008 at 12:09:01PM +0900, ITAGAKI Takahiro wrote:
> Hi, I found the cause.
Thanks a lot. Patch just checked in, please try again with CVS HEAD.
> The attached patch fixes the segfault. Regression tests can finish
> successfully but there is still a difference. The diff seems to be
On Wed, Dec 17, 2008 at 07:40:20AM -0500, Andrew Dunstan wrote:
> This test is not run by the buildfarm. It's not part of ecpg's
> "installcheck" suite.
I was under the impression that at least some members do run it. What else is
the test good for? Back when it was implemented it was taken out
On Wed, 2008-12-17 at 15:43 +, Gregory Stark wrote:
> Simon Riggs writes:
>
> > On Wed, 2008-12-17 at 17:12 +0200, Heikki Linnakangas wrote:
> >
> >> Hmm, could well be related to the visibility map or FSM. Although those
> >> messages suggest that it's a heap/index page that's missing, not
Simon Riggs writes:
> On Wed, 2008-12-17 at 17:12 +0200, Heikki Linnakangas wrote:
>
>> Hmm, could well be related to the visibility map or FSM. Although those
>> messages suggest that it's a heap/index page that's missing, not FSM or
>> VM page. Any idea how to reproduce that?
>
> Regrettably,
Currently SIGINT is ignored during in transaction, but we have
recently agreed to allow this to cancel the transaction. We said we
would do this in all cases, so this is a separate feature/patch (though
Hot Standby requires it).
A simple change allows the transaction to be cancelled, but there ar
http://wiki.postgresql.org/wiki/Hot_Standby
now contains a link to latest version of this patch. This is still at
"v5", just brought forward to CVS HEAD.
I will be doing further work on the patch from here and will reply to
this post each time I submit a new version.
--
Simon Riggs w
On Wed, 2008-12-17 at 17:12 +0200, Heikki Linnakangas wrote:
> Hmm, could well be related to the visibility map or FSM. Although those
> messages suggest that it's a heap/index page that's missing, not FSM or
> VM page. Any idea how to reproduce that?
Regrettably, none. I will ask to see if th
Peter Eisentraut wrote:
>> worry too much about the function pointers getting stale due to library
>> changes and reloads, as that requires some deliberate actions as a
>> superuser.
>
> I never understood that reload business complete anyway. If you think
> there are issues at run time, they sho
Simon Riggs wrote:
I've had a private report of these error messages in a test of Hot
Standby, but IMHO these aren't related to that patch. It seems more
likely to be related to the new VACUUM code? Certainly hot standby does
nothing to the normal flow of existing WAL records.
LOG: database sys
I've had a private report of these error messages in a test of Hot
Standby, but IMHO these aren't related to that patch. It seems more
likely to be related to the new VACUUM code? Certainly hot standby does
nothing to the normal flow of existing WAL records.
LOG: database system was interrupted;
2008/12/17 Tom Lane :
> So to summarize what I think we agreed to yesterday:
>
> * CREATE OR REPLACE FUNCTION has to prevent reducing the pronargdefaults
> value of an existing function (ie, you can add more defaults but not
> remove any). This ensures a function that matched a given call before
>
Zdenek Kotala writes:
> What's about add second bit which mark frozen page (all tuples have freeze
> XID)? It should avoid full scan, but extend size of map.
That would only really work if you have a very static table where entire pages
get frozen and stay frozen long before the freeze_max_age i
Merlin Moncure wrote:
On Mon, Mar 26, 2007 at 10:30 AM, Andrew Dunstan wrote:
This feature (ability to add a message payload to a NOTIFY) is on the TODO
list and I had undertaken to implement it. However, pressure of other work
has conspired to make that difficult, and Abhijit Menon-Sen re
So to summarize what I think we agreed to yesterday:
* CREATE OR REPLACE FUNCTION has to prevent reducing the pronargdefaults
value of an existing function (ie, you can add more defaults but not
remove any). This ensures a function that matched a given call before
will continue to do so.
* CREAT
On Mon, Mar 26, 2007 at 10:30 AM, Andrew Dunstan wrote:
>
> This feature (ability to add a message payload to a NOTIFY) is on the TODO
> list and I had undertaken to implement it. However, pressure of other work
> has conspired to make that difficult, and Abhijit Menon-Sen recently very
> kindly o
Zdenek Kotala wrote:
What's about add second bit which mark frozen page (all tuples have
freeze XID)? It should avoid full scan, but extend size of map.
First of all, we'd still have to make the decision of when to scan pages
that need freezing, and when to only scan pages that have dead tuple
"Pavan Deolasee" writes:
> OTOH I think we can still set PD_ALL_VISIBLE page header flag even
> when there are DEAD line pointers.
That would mean the header flag means something different than the
map bit does, which would mean extra tests need to be made before
propagating the flag bit to the m
On Wed, Dec 17, 2008 at 7:11 PM, Tom Lane wrote:
>
>
> I think what you are suggesting is that we should set the visibility map
> bit while dead line pointers (tombstones) still remain. If that's what
> you meant it's a bad idea.
No, I'm not suggesting that. I understand the problem there. I was
"Pavan Deolasee" writes:
> On Wed, Dec 17, 2008 at 3:29 PM, Heikki Linnakangas
> wrote:
>> I don't quite understand this paragraph. If there's any DEAD tuples or
>> line-pointers, the all-visible flag can't be set.
> No, I am saying, HOT-prune removes all DEAD tuples from the page (not
> the DEA
ITAGAKI Takahiro wrote:
Andrew Dunstan wrote:
I did this, but it turned out that the problem was a logic error that I
found once I had managed to get a working debugger. However, the Windows
thread code should now be more robust, so thanks to Andrew and Magnus
for the suggestions.
What's about add second bit which mark frozen page (all tuples have freeze XID)?
It should avoid full scan, but extend size of map.
Zdenek
Heikki Linnakangas napsal(a):
The way VACUUM works with the visibility map is that if any pages are
skipped, relfrozenxid can't b
Tom Lane wrote:
ITAGAKI Takahiro writes:
Hi, I found the cause.
...
Actual error occurs in vfprintf() because act->name can be NULL.
sprintf(..., "%s", NULL) could work on some platform (the result is '(null)'),
but it crashes on Windows (msvcrt). We need to avoid passing NULLs as
argument
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
BTree space reservation is more complicated.
Do you need to pre-reserve the space for b-tree? I think you can just
split it at upgrade, in the new version. The problem with doing that
for
On Wed, 2008-12-17 at 12:07 +0900, Fujii Masao wrote:
> OK. I will extend synchronous_replication, make walsender send XLOG
> with synchronization mode flag and make walreceiver perform according
> to the flag.
Sounds good.
> > My perspective is that synchronous_replication specifies how long t
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
BTree space reservation is more complicated.
Do you need to pre-reserve the space for b-tree? I think you can just
split it at upgrade, in the new version. The problem with doing that
for heaps is that to move a heap tu
1 - 100 of 108 matches
Mail list logo
