sorry, there was a broken message
2010/11/24 Pavel Stehule :
> 2010/11/24 Robert Haas :
>> On Tue, Nov 23, 2010 at 8:56 PM, Cédric Villemain
>> wrote:
>>> 2010/11/23 Robert Haas :
On Mon, Nov 22, 2010 at 11:55 PM, Pavel Stehule
wrote:
> ok, I can only recapitulate so this feature
2010/11/24 Robert Haas :
> On Tue, Nov 23, 2010 at 8:56 PM, Cédric Villemain
> wrote:
>> 2010/11/23 Robert Haas :
>>> On Mon, Nov 22, 2010 at 11:55 PM, Pavel Stehule
>>> wrote:
ok, I can only recapitulate so this feature was proposed cca two
months ago, and minimally Tom and maybe you
On 24.11.2010 07:07, Robert Haas wrote:
Per previous threats, I spent some time tonight running oprofile
(using the directions Tom Lane was foolish enough to provide me back
in May). I took testlibpq.c and hacked it up to just connect to the
server and then disconnect in a tight loop without doi
Hi,
I work on implementing binary protocol, during test "select ?::int" has
been
executed few times to compile it to server prepared statement, but after
this
backend returned field format = text, but sent field data in binary mode.
The parameter is long and is sent to in text mode, with oid 0,
Josh Berkus writes:
>> Well, very little about pg_dump is very [E], IMNSHO. The question in my
>> mind here is what format the list file will take
> I was thinking same format as pg_restore -l, only without the dumpIDs.
Nope ... those strings are just helpful comments, they aren't really
guarant
Eliot Gable wrote:
However, I have not seen much in the way of a serious attempt at
multi-master write scaling.
Scaling writes across nodes using PL/Proxy works.
Of course, I am assuming the disk system would be RAID 1, RAID 10,
RAID 5, or RAID 6 for reliability purposes and that it is suffi
Peter, glad to know you succeeded. FYI, a year ago we developed GiST
extension for rdkit.org.
Oleg
On Tue, 23 Nov 2010, Peter Tanski wrote:
I found another off-by-one error in my Picksplit() algorithm and the GiST index
contains one leaf tuple for each row in the table now. The error was to
=?ISO-8859-1?Q?C=E9dric_Villemain?= writes:
> I think you (Robert) misunderstood dramatically what Pavel try to do.
> Pavel did an excellent optimization work for a specific point. This
> specific point looks crucial for me in the current behavior of
> PostgreSQL[1]. AFAIS Pavel didn't want to imp
Robert Haas wrote:
Did this get eaten by the email goblin, or you're still working on it?
Fell behind due to an unfortunately timed bit of pneumonia. Hurray for
the health benefits of cross country flights. Will fix this up, rebase
my other patch, and head toward some more review/'Fest c
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> Possibly the cleanest fix is to implement pg_ping as a libpq function.
> > >> You do have to distinguish connection failures (ie connection refused)
> > >> from errors that came back from the postmaster,
On Wed, Nov 24, 2010 at 12:07 AM, Robert Haas wrote:
> Per previous threats, I spent some time tonight running oprofile
> (using the directions Tom Lane was foolish enough to provide me back
> in May). I took testlibpq.c and hacked it up to just connect to the
> server and then disconnect in a ti
Per previous threats, I spent some time tonight running oprofile
(using the directions Tom Lane was foolish enough to provide me back
in May). I took testlibpq.c and hacked it up to just connect to the
server and then disconnect in a tight loop without doing anything
useful, hoping to measure the
.
> Well, very little about pg_dump is very [E], IMNSHO. The question in my
> mind here is what format the list file will take
I was thinking same format as pg_restore -l, only without the dumpIDs.
--
-- Josh Berkus
PostgreS
On Tue, Nov 23, 2010 at 8:45 AM, Heikki Linnakangas
wrote:
> On 19.11.2010 23:46, Joachim Wieland wrote:
>>
>> FATAL: too many KnownAssignedXids. head: 0, tail: 0, nxids: 9978,
>> pArray->maxKnownAssignedXids: 6890
>
> Hmm, that's a lot of entries in KnownAssignedXids.
>
> Can you recompile with
Hi,
http://archives.postgresql.org/pgsql-hackers/2010-11/msg01303.php
When I did unusual operations (e.g., suspend bgwriter by gdb,
pgbench -i and issue txid_current many times) on the master
in order to try to reproduce the above HS error, I encountered
the following assertion error.
Since I co
On Tue, Nov 23, 2010 at 10:24 PM, Andrew Dunstan wrote:
> Well, very little about pg_dump is very [E], IMNSHO. The question in my mind
> here is what format the list file will take. For example, how would we
> specify a function? Would we need to specify all the argument types (or at
> least the I
On 11/23/2010 09:33 PM, Josh Berkus wrote:
Hackers,
I just thought of a good feature to put on the [E] list for TODO, if
people agree: a switch to pg_dump called "--from-list" which would take
a filename and dump the list of objects in that file.
Objections to putting this on the TODO?
Well
On Tue, Nov 23, 2010 at 09:37:57PM -0500, Josh Kupershmidt wrote:
> On Fri, Oct 29, 2010 at 10:33 AM, David Fetter wrote:
> > That seems like a matter for a separate patch. Looking this over, I
> > found I'd created a query that can never get used, so please find
> > enclosed the next version of
On Mon, Nov 22, 2010 at 6:54 AM, Heikki Linnakangas
wrote:
> On 21.11.2010 15:18, Robert Haas wrote:
>>
>> On Sat, Nov 20, 2010 at 4:07 PM, Tom Lane wrote:
>>>
>>> Robert Haas writes:
So what DO we need to guard against here?
>>>
>>> I think the general problem can be stated as "proces
I found another off-by-one error in my Picksplit() algorithm and the GiST index
contains one leaf tuple for each row in the table now. The error was to start
from 1 instead of 0 when assigning the entries. Thanks to everyone for your
help.
For the record, this is the only GiST index I know of
2010/11/23 KaiGai Kohei :
>> What
>> I'm not quite sure about is where to put the definitions you've added
>> to a new file utils/hooks.h; I don't feel that's a very appropriate
>> location. It's tempting to put them in utils/acl.h just because this
>> is vaguely access-control related and that he
Thanks for your reviewing, and sorry for the late reply.
I've not been available for a few days.
(2010/11/22 12:11), Robert Haas wrote:
> 2010/11/12 KaiGai Kohei:
>> (2010/11/12 19:34), KaiGai Kohei wrote:
>>> I revised my patch according to the prior suggestions.
>>>
>> I'm sorry. I revised my pa
On Tue, Nov 23, 2010 at 8:56 PM, Cédric Villemain
wrote:
> 2010/11/23 Robert Haas :
>> On Mon, Nov 22, 2010 at 11:55 PM, Pavel Stehule
>> wrote:
>>> ok, I can only recapitulate so this feature was proposed cca two
>>> months ago, and minimally Tom and maybe you did agreement - with
>>> request o
On Fri, Oct 29, 2010 at 10:33 AM, David Fetter wrote:
> That seems like a matter for a separate patch. Looking this over, I
> found I'd created a query that can never get used, so please find
> enclosed the next version of the patch :)
I like "deletables" better than "deleteables" for
Query_for_
Hackers,
I just thought of a good feature to put on the [E] list for TODO, if
people agree: a switch to pg_dump called "--from-list" which would take
a filename and dump the list of objects in that file.
Objections to putting this on the TODO?
--
-- Josh Berkus
2010/11/21 Andres Freund :
> On Sunday 21 November 2010 23:19:30 Martijn van Oosterhout wrote:
>> For a similar problem we had (kernel buffering too much) we had success
>> using the fadvise and madvise WONTNEED syscalls to force the data to
>> exit the cache much sooner than it would otherwise. Th
2010/11/23 Robert Haas :
> On Mon, Nov 22, 2010 at 11:55 PM, Pavel Stehule
> wrote:
>> ok, I can only recapitulate so this feature was proposed cca two
>> months ago, and minimally Tom and maybe you did agreement - with
>> request on syntax - do you remember? I am little bit tired so this
>> agre
On Sun, Nov 21, 2010 at 11:07 PM, Andy Colson wrote:
> After all this... there are too many numbers for me. I have no idea what
> this means.
I think what it means that is that, for you, unlogged tables were
almost as fast as shutting off all of synchronous_commit,
full_page_writes, and fsync, a
On 11/24/2010 05:18 AM, Magnus Hagander wrote:
Or you set the handler always, and have the handler only actually
create the dump if the directory exists. That way you can add the
directory and still get a dump from both existing backends and the
postmaster itself without a restart.
That's way
On 24/11/10 09:43, Eliot Gable wrote:
However, it occurs to me that if you had a shared disk system via
either iSCSI, Fiber Channel, NFS, or whatever (which also had higher
I/O capabilities than a single server could utilize)
Yeah, current Postgres multi-master projects seem to be focusing on
Magnus Hagander writes:
> On Tue, Nov 23, 2010 at 15:09, Craig Ringer
> wrote:
>> Yep. That's how I'd want to do it in 9.1 - test for the directory and use
>> that to decide whether to set the handler during early backend startup. That
>> way you don't need a GUC, and should be able to load it *
On Tue, Nov 23, 2010 at 15:09, Craig Ringer wrote:
> On 11/23/2010 01:46 AM, Tom Lane wrote:
>
>>> * However, when storing it in crashdumps, I think the code would need
>>> to create that directory if it does not exist, doesn't it?
>>
>> If it didn't do so, then manual creation/removal of the dire
On Tue, Nov 23, 2010 at 15:02, Craig Ringer wrote:
>>> However, I am not clear what benefit we get from moving this into core
>>> in 9.1. If it's still going to require a full postmaster restart, the
>>> GUC you have to change may as well be shared_preload_libraries as a
>>> new one.
>
> There's
Eliot Gable wrote:
> the locks would ensure a strict ordering of queries.
PostgreSQL doesn't support S2PL. I'm not sure what locks you mean.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
On Tue, Nov 23, 2010 at 3:43 PM, Eliot Gable
> wrote:
> Other than that, is there anything else I am missing? Wouldn't this type of
> setup be far simpler to implement and provide better scalability than trying
> to do multi-master replication using log shipping or binary object shipping
> or an
On ons, 2010-11-17 at 21:05 +0100, Dimitri Fontaine wrote:
> Code wise, though, I wonder about the name of the "recursing"
> parameter of the renameatt_internal function is
> src/backend/commands/tablecmds.c,
> which seems to only get used to detect erroneous attempt at renaming
> the table column
I know there has been a lot of talk about replication getting built into
Postgres and I know of many projects that aim to fill the role. However, I
have not seen much in the way of a serious attempt at multi-master write
scaling. I understand the fundamental problem with write scaling across
multip
On Nov 23, 2010, at 1:37 PM, Yeb Havinga wrote:
j = 0;
for (i = FirstOffsetNumber; i < maxoff; i = OffsetNumberNext(i)) {
FPrint* v = deserialize_fprint(entv[i].key);
>>>
>>> Isn't this off by one? Offset numbers are 1-based, so the maxoff
>>> computation is wrong.
> The first fo
On Tue, 2010-11-23 at 14:48 -0500, Robert Haas wrote:
> On Tue, Nov 23, 2010 at 2:01 PM, David E. Wheeler
> wrote:
> > On Nov 22, 2010, at 6:03 PM, Josh Berkus wrote:
> >
> >> ... "original patch". Sorry. Let's not fiddle with the names.
> >
> > To be clear, as things stand now, the new command
On Nov 23, 2010, at 11:48 AM, Robert Haas wrote:
>> So while the term in the SQL statement is "VALUE," it's called a "label" in
>> the documentation. I think that's confusing. Does anyone else?
>
> Yes. As between the two options, I favor changing the command. And
> let's also paint it pink.
On Tue, Nov 23, 2010 at 2:01 PM, David E. Wheeler wrote:
> On Nov 22, 2010, at 6:03 PM, Josh Berkus wrote:
>
>> ... "original patch". Sorry. Let's not fiddle with the names.
>
> To be clear, as things stand now, the new command is:
>
> ALTER TYPE name ADD VALUE new_enum_value [ { BEFORE | AFT
Excerpts from Pavel Stehule's message of lun nov 22 10:01:23 -0300 2010:
> sorry - it is related to tests from FOR-IN-ARRAY thread
> test query: select avg(array_upper(filter02(x,'%AA%', 10),1)) from t1000;
Yeah, I can measure a 25x improvement in that test with the patch
applied.
--
Álvaro He
On sön, 2010-11-21 at 18:48 -0500, Tom Lane wrote:
> Yeah. I'm actually not sure that the SQL committee has thought very
> hard about this, because the spec is worded as though they think that
> "Unicode case normalization" is all they have to say to uniquely
> define what to do. The Unicode guys
On Nov 22, 2010, at 6:03 PM, Josh Berkus wrote:
> ... "original patch". Sorry. Let's not fiddle with the names.
To be clear, as things stand now, the new command is:
ALTER TYPE name ADD VALUE new_enum_value [ { BEFORE | AFTER }
existing_enum_value ]
So while the term in the SQL statement
On Mon, Nov 22, 2010 at 11:55 PM, Pavel Stehule wrote:
> ok, I can only recapitulate so this feature was proposed cca two
> months ago, and minimally Tom and maybe you did agreement - with
> request on syntax - do you remember? I am little bit tired so this
> agreement was changed when I spent my
On Tue, Nov 23, 2010 at 5:09 AM, Shigeru HANADA
wrote:
> I've separated the patch into tree parts. They have codes, documents
> and tests within, and file_fdw and pgsql_fdw can be applied onto
> fdw_core for each, or together. I hope the separation helps the
> review of the patches. Contents of
On Tue, 2010-11-23 at 20:18 +0200, Heikki Linnakangas wrote:
> On 23.11.2010 14:22, Shigeru HANADA wrote:
> > OID is supported to get oid from the source table (yes, it works only
> > for postgresql_fdw but it seems useful to support).
>
> I don't think that's worthwhile. Oids on user tables is a
On Tue, Nov 23, 2010 at 5:51 PM, Tom Lane wrote:
> The case I was worried about is dumping from one database and reloading
> into another one with a different locale. Although I suppose there are
> enough *other* reasons why that might fail that adding changes of
> downcasing behavior might not b
On 23.11.2010 14:22, Shigeru HANADA wrote:
On Tue, 23 Nov 2010 12:30:52 +0200
Heikki Linnakangas wrote:
The docs need some work. The CREATE FOREIGN TABLE reference page seems
to be copy-pasted from CREATE TABLE, because it talks about constraints
and WITH/WITHOUT OIDS which surely don't apply t
Greg Stark writes:
> I'm not sure I understand the danger if a user creates an object in a
> database with a particular encoding and locale using that locale for
> downcasing in the future.
The case I was worried about is dumping from one database and reloading
into another one with a different l
On Tue, Nov 23, 2010 at 5:12 PM, Tom Lane wrote:
> And, after you've hacked your way through all that, you still end up
> with case-folding behavior that depends on the prevailing locale.
> Which is dangerous for the previously cited reasons, and arguably not
> spec-compliant.
>
So I thought the
On 11/23/2010 11:14 AM, Greg Stark wrote:
On Mon, Nov 22, 2010 at 12:38 AM, Tom Lane wrote:
No, especially if it results in queries that used to work breaking,
which it well could. But I'm not sure where to go with it from there,
beyond throwing up my hands.
Well, that's why there's been no
Greg Stark writes:
> On Mon, Nov 22, 2010 at 12:38 AM, Tom Lane wrote:
>> Well, that's why there's been no movement on this since 2004 :-(. The
>> amount of work needed for a better solution seems far out of proportion
>> to the benefits.
> We could extend the existing logic to handle multi-byt
So I'm still trying to look into:
http://archives.postgresql.org/pgsql-hackers/2010-11/msg00686.php
which is still broken in 8.4-STABLE even after toms patch, to get better
debugging I was trying to get non-translated error messages in the log
which seems to be completely impossible in window
Picksplit() seems to be an exceptional case here: the first and last
numbers in entryvec are invalid so
entryvec->vector[entryvec->n - 1]
is invalid. All the other GiST code Picksplit() functions use the
same convention. For example, see the btree_gist picksplit function, at
http://doxyge
On Tue, Nov 23, 2010 at 11:37 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane wrote:
>>> It would be the first, because simply assigning another strategy number
>>> only satisfies one of the unique constraints on pg_amop. To allow
>>> arbitrary flexibilit
I wrote:
> We will probably *also* want to pass these details explicitly to the
> index AM, but that doesn't solve the problem that some catalog somewhere
> has to say what it is that the opclass can do.
... although having said that, the obvious question is why that catalog
has to be pg_amop. Ma
I should correct what I just wrote: the first and last entries in
entryvec->vector are invalid.
On Nov 23, 2010, at 11:39 AM, Peter Tanski wrote:
Picksplit() seems to be an exceptional case here: the first and last
numbers in entryvec are invalid so
entryvec->vector[entryvec->n - 1]
is in
Robert Haas writes:
> On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane wrote:
>> It would be the first, because simply assigning another strategy number
>> only satisfies one of the unique constraints on pg_amop. To allow
>> arbitrary flexibility here, we would have to include all components of
>> the
On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane wrote:
>>> I'm satisfied to say that only one sort order can be associated with a
>>> particular operator in a particular opclass, which is what would be
>>> implied by using AMO
On Mon, Nov 22, 2010 at 12:38 AM, Tom Lane wrote:
>> No, especially if it results in queries that used to work breaking,
>> which it well could. But I'm not sure where to go with it from there,
>> beyond throwing up my hands.
>
> Well, that's why there's been no movement on this since 2004 :-(.
Robert Haas writes:
> On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane wrote:
>> I'm satisfied to say that only one sort order can be associated with a
>> particular operator in a particular opclass, which is what would be
>> implied by using AMOP_SEARCH/AMOP_ORDER as the unique key component.
> Does
On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane wrote:
>>> On balance I'm inclined to leave the unique key as per previous proposal
>>> (with a "purpose" column) and add the which-sort-order-is-that
>>> information as payload c
On Tue, Nov 23, 2010 at 2:33 AM, Kris Jurka wrote:
>
>
> On Mon, 22 Nov 2010, Itagaki Takahiro wrote:
>
>> On Fri, Oct 15, 2010 at 03:40, Rados?aw Smogura
>> wrote:
Regarding JDBC in the CF process -- other interfaces are handled
there. I haven't seen one patch this size for JDBC
On Tue, Nov 23, 2010 at 3:42 AM, Heikki Linnakangas
wrote:
> That's an interesting idea. You pickyback setting the vm bit on the freeze
> WAL record, on the assumption that you have to write the freeze record
> anyway. However, if that assumption doesn't hold, because the tuples are
> deleted befo
Excerpts from Peter Tanski's message of mar nov 23 12:00:52 -0300 2010:
> There are checks inside the Picksplit() function for the number of entries:
>
> OffsetNumber maxoff = entryvec->n - 1;
> int n_entries, j;
> n_entries = Max(maxoff, 1) - 1;
>
> j = 0;
> for (i = FirstOffsetNumber
Thanks for the advice. I ran a row-by-row test, including debug output. I'll
put a test case together as well but I believe I have narrowed down the problem
somewhat. The first split occurrs when the 6th row is inserted and there are 6
calls to Compress(), however picksplit only receives 4 of
On 11/23/2010 01:56 AM, Heikki Linnakangas wrote:
On 22.11.2010 19:47, Robert Haas wrote:
I am as conservative about back-patching as anybody here, but
debugging on Windows is not an easy thing to do, and I strongly
suspect we are going to point people experiencing crashes on Windows
to this cod
On 11/23/2010 01:46 AM, Tom Lane wrote:
* However, when storing it in crashdumps, I think the code would need
to create that directory if it does not exist, doesn't it?
If it didn't do so, then manual creation/removal of the directory could
be used as an on/off switch for the feature.
Yep. T
On 11/23/2010 01:30 AM, Tom Lane wrote:
I'm not really sure why we're even considering the notion of
back-patching this item. Doing so would not fit with any past practice
or agreed-on project management practices, not even under our lax
standards for contrib (and I keep hearing people claim th
However, I am not clear what benefit we get from moving this into core
in 9.1. If it's still going to require a full postmaster restart, the
GUC you have to change may as well be shared_preload_libraries as a
new one.
There's no reason it should require a postmaster restart. New backends
spawn
On Tue, 23 Nov 2010 12:30:52 +0200
Heikki Linnakangas wrote:
> The docs need some work. The CREATE FOREIGN TABLE reference page seems
> to be copy-pasted from CREATE TABLE, because it talks about constraints
> and WITH/WITHOUT OIDS which surely don't apply to foreign tables.
Thanks for the comm
On 22.11.2010 03:35, Robert Haas wrote:
On Sun, Nov 21, 2010 at 8:10 PM, Itagaki Takahiro
wrote:
On Wed, Oct 20, 2010 at 01:36, Dimitri Fontaine wrote:
Ah yes, thinking it's an easy patch is not helping. Please find attached
a revised version of it.
I checked cfparser.v2.patch.
It exports
On 23.11.2010 12:09, Shigeru HANADA wrote:
On Sun, 21 Nov 2010 21:16:05 -0500
Robert Haas wrote:
Ultimately, we probably want and need to get this patch down to chunks
of less than 2000 lines each. But for starters, it looks quite simple
to break this into three chunks: one for the PostgreSQL
Alvaro Herrera writes:
> the handling of relative vs absolute paths is bogus here. I think it'd
> make more sense to have a bool "are we including"; and if that's false and
> the path is not absolute, then the file is relative to CWD; or maybe we
> make it absolute by prepending PGDATA; maybe som
On 22.11.2010 21:24, Robert Haas wrote:
Eh, so. Suppose - for the sake of argument - we do the following:
1. Allocate an additional infomask(2) bit that means "xmin is frozen,
no need to call XidInMVCCSnapshot()". When we freeze a tuple, we set
this bit in lieu of overwriting xmin. Note that
Alvaro Herrera writes:
> Hmm, the first thought that comes to mind is that the GucContext param
> to ParseConfigFile is unused and can be removed. This is probably an
> oversight from when include files were introduced in 2006.
Thanks for caring about that part.
> I don't like the fact that thi
Robert Haas writes:
> Especially because you also posted some revs of the ALTER EXTENSION ..
> SET SCHEMA patch on this thread
Yes, I tried to answer where questions have been raised, and that's not
helping so much at review time. That's why I take the time to update the
commit fest applicati
Can we just log the change of VM in log_heap_clean() for redo?
Thanks
--
GaoZengqi
pgf...@gmail.com
zengqi...@gmail.com
On Tue, Nov 23, 2010 at 3:24 AM, Robert Haas wrote:
> On Mon, Jun 14, 2010 at 1:19 AM, Heikki Linnakangas
> wrote:
> >> I *think* that the answer to this parenthesized quest
79 matches
Mail list logo
