On Tue, 2011-07-05 at 13:15 -0400, Robert Haas wrote:
On Tue, Jul 5, 2011 at 1:13 PM, Robert Haas robertmh...@gmail.com wrote:
Here is an updated version of the lazy vxid locks patch [1], which
applies over the latest reduce the overhead of frequent table
locks[2] patch.
[1]
Hackers,
This patch needs a new reviewer, per Cedric. Please help!
Hi I am the new reviewer:-)
I have looked into the v6 patches. One thing I would like to suggest
is, enhancing the error message when temp_file_limit will be exceeded.
ERROR: aborting due to exceeding temp file limit
Is
Hi Thomas-san, Ralf-san.
I appreciate your great work.
Thanks!
CC to Postgres-ML.
Regards,
Hiroshi Saito
(2011/07/14 3:49), Thomas Lotterer wrote:
Thanks for the hint.
Our ftp daemon is dumping core.
We are debugging ...
--
Sent via pgsql-hackers mailing list
Hi everybody:
I am using pgmail to send email in an application, but I would like to use
html format
Does anybody has an example how to do this?, or what do you recommend me to
use por doing this?
Thanks in advance for your attention.
Best Regards,
Fernando Acosta
Lima -
On Thu, Jul 14, 2011 at 5:39 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Jul 13, 2011 at 10:56 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
Attached is patch for the WAL writer that removes its tight polling
loop (which probably doesn't get hit often in practice, as we just
On Thu, Jul 14, 2011 at 12:42 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Pinning a buffer that's already in the shared buffer cache is cheap, I
doubt you're gaining much by keeping the private hash table in front of the
buffer cache.
Yes, I see. Pinning a lot of
On Thu, Jul 14, 2011 at 9:57 AM, Fujii Masao masao.fu...@gmail.com wrote:
Currently walwriter might write out the WAL before a transaction commits.
IOW, walwriter tries to write out the WAL in wal_buffers in every wakeups.
This might be useful for long transaction which generates lots of WAL
On Thu, Jul 14, 2011 at 12:56 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
First, notice that we're setting ptr-parent = top. 'top' is the current
node we're processing, and ptr represents the node to the right of the
current node. The current node is *not* the parent of
I have a couple of questions on GIN:
The code seems to assume that it's possible for the same TID to appear
twice for a single key (see addItemPointersToTuple()). I understand that
it's possible for a single heap tuple to contain the same key twice. For
example if you index an array of
On Thu, 14 Jul 2011 15:15:33 +0300, Peter Eisentraut wrote:
On sön, 2011-07-10 at 11:40 -0700, Josh Berkus wrote:
Hackers,
B. 6. Current behaviour _is intended_ (there is if to check
node type) and _natural_. In this particular case user ask for text
content of some node, and this content
On Jul 14, 2011, at 4:38 AM, Alvaro Herrera wrote:
Excerpts from Florian Pflug's message of mié jul 13 20:12:28 -0400 2011:
On Jul14, 2011, at 01:38 , Alvaro Herrera wrote:
One strange thing here is that you could get two such messages; say if a
file has 100 parse errors and there are also
2011/5/26 MauMau maumau...@gmail.com:
Hello,
I wrote and attached a patch for the TODO item below (which I proposed).
Allow multiple Postgres clusters running on the same machine to distinguish
themselves in the event log
http://archives.postgresql.org/pgsql-hackers/2011-03/msg01297.php
On Mon, Jun 6, 2011 at 10:33 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.02.2011 23:09, Simon Riggs wrote:
On Sun, 2011-02-06 at 12:11 -0500, Bruce Momjian wrote:
Did this ever get addressed?
Patch attached.
Seems like the easiest fix I can come up with.
@@
On Thu, Jul 14, 2011 at 11:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
Hi Pavan,
I'd say that seems way too complex for such a small use case and we've
only just fixed the bugs from 8.4 vacuum map complexity. The code's
looking very robust now and I'm uneasy that such changes are
On Tue, Jul 12, 2011 at 9:47 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
http://archives.postgresql.org/pgsql-hackers/2011-05/msg01119.php
PFA a patch which implements the idea with some variation.
At the start of the first pass, we remember the current LSN. Every page that
needs some
On ons, 2011-07-13 at 11:58 +0200, Nicolas Barbier wrote:
2011/6/29, Florian Pflug f...@phlo.org:
Secondly, there is little point in having an type XML if we
don't actually ensure that values of that type can only contain
well-formed XML.
+1. The fact that XPATH() must return a type
On sön, 2011-07-10 at 11:40 -0700, Josh Berkus wrote:
Hackers,
B. 6. Current behaviour _is intended_ (there is if to check node type)
and _natural_. In this particular case user ask for text content of some
node, and this content is actually .
I don't buy that. The check for the
On 14.07.2011 12:42, Simon Riggs wrote:
On Thu, Jul 14, 2011 at 9:57 AM, Fujii Masaomasao.fu...@gmail.com wrote:
Currently walwriter might write out the WAL before a transaction commits.
IOW, walwriter tries to write out the WAL in wal_buffers in every wakeups.
This might be useful for long
On Thu, Jul 14, 2011 at 10:53 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 14.07.2011 12:42, Simon Riggs wrote:
On Thu, Jul 14, 2011 at 9:57 AM, Fujii Masaomasao.fu...@gmail.com
wrote:
Currently walwriter might write out the WAL before a transaction commits.
IOW,
On 14.07.2011 18:57, Pavan Deolasee wrote:
On Thu, Jul 14, 2011 at 11:46 AM, Simon Riggssi...@2ndquadrant.com wrote:
I'd say that seems way too complex for such a small use case and we've
only just fixed the bugs from 8.4 vacuum map complexity. The code's
looking very robust now and I'm uneasy
On Jul 13, 2011, at 12:57 PM, Kevin Grittner wrote:
create or replace function relistemp(rel pg_class)
returns boolean language sql immutable strict as
$$select $1.relpersistence = 't';$$;
Just don't forget to use the table name or alias in front of it... :-)
Oh, nice hack. How far back
On Jul 14, 2011, at 12:05 AM, Hiroshi Saito wrote:
Hi Thomas-san, Ralf-san.
I appreciate your great work.
Thanks!
CC to Postgres-ML.
Regards,
Hiroshi Saito
(2011/07/14 3:49), Thomas Lotterer wrote:
Thanks for the hint.
Our ftp daemon is dumping core.
We are debugging ...
Ah,
On 14.07.2011 19:51, David E. Wheeler wrote:
On Jul 13, 2011, at 12:57 PM, Kevin Grittner wrote:
create or replace function relistemp(rel pg_class)
returns boolean language sql immutable strict as
$$select $1.relpersistence = 't';$$;
Just don't forget to use the table name or alias in
David E. Wheeler da...@kineticode.com wrote:
On Jul 13, 2011, at 12:57 PM, Kevin Grittner wrote:
create or replace function relistemp(rel pg_class)
returns boolean language sql immutable strict as
$$select $1.relpersistence = 't';$$;
Just don't forget to use the table name or alias in
On Jul 14, 2011, at 9:55 AM, Heikki Linnakangas wrote:
Far back. But you only need it in = 9.1. Older versions have the
pg_class.relistemp column anyway.
Yeah.
Not sure how this helps, though. If you modify pgTAP to install that
automatically in pgTAP when dealing with a new server
Florian Pflug wrote:
On Jul13, 2011, at 21:08 , Bruce Momjian wrote:
- OID of the database in which the object exists, or
- zero if the object is a shared object, or
- null if the lock object is on a transaction ID
+ OID of the database in which the lock target
On 14/07/11 18:48, Tatsuo Ishii wrote:
Hi I am the new reviewer:-)
I have looked into the v6 patches. One thing I would like to suggest
is, enhancing the error message when temp_file_limit will be exceeded.
ERROR: aborting due to exceeding temp file limit
Is it possible to add the current
On Jul 13, 2011, at 12:29 PM, Fernando Acosta Torrelly fgaco...@gmail.com
wrote:
Hi everybody:
I am using pgmail to send email in an application, but I would like to use
html format
Does anybody has an example how to do this?, or what do you recommend me to
use por doing this?
On Wed, Jun 15, 2011 at 10:53, Ahmed Shinwari ahmed.shinw...@gmail.com wrote:
Hi All,
I faced a bug on Windows while connecting via SSPI authentication. I was
able to find the bug and have attached the patch. Details listed below;
Postgres Installer: Version 9.0.4
OS: Windows Server 2008
All,
BTW, if we're dumping relistemp, we're going to need to notify every
maker of a PostgreSQL admin interface before we release 9.1.
This is why we should have had a complete set of sysviews ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing
Josh Berkus wrote:
All,
BTW, if we're dumping relistemp, we're going to need to notify every
maker of a PostgreSQL admin interface before we release 9.1.
This is why we should have had a complete set of sysviews ...
Are they not testing our 9.1 betas?
--
Bruce Momjian
I have a couple of questions on GIN:
The code seems to assume that it's possible for the same TID to appear
twice for a single key (see addItemPointersToTuple()). I understand that
it's possible for a single heap tuple to contain the same key twice. For
example if you index an array of integers
On Thu, Jul 14, 2011 at 12:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 14.07.2011 18:57, Pavan Deolasee wrote:
On Thu, Jul 14, 2011 at 11:46 AM, Simon Riggssi...@2ndquadrant.com
wrote:
I'd say that seems way too complex for such a small use case and we've
On Jul14, 2011, at 19:06 , Bruce Momjian wrote:
Florian Pflug wrote:
On Jul13, 2011, at 21:08 , Bruce Momjian wrote:
+ OID of the relation lock target, or null if the lock is not
on a relation or part of a relation
That, however, not so much. relation lock target might easily
Excerpts from Pavan Deolasee's message of jue jul 14 13:54:36 -0400 2011:
On Thu, Jul 14, 2011 at 12:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Seems odd to store relindxvacxlogid/off as two int32 columns. Store it in
one uint64 column, or invent a new datatype
On 7/12/11 11:17 AM, Josh Berkus wrote:
On 7/12/11 7:38 AM, Simon Riggs wrote:
On Sun, Jul 10, 2011 at 7:13 PM, Josh Berkus j...@agliodbs.com wrote:
This patch[1] is for some reason marked waiting on Author. But I
can't find that there's been any review of it searching the list.
What's
pg_dump seems to not dump the owner of extensions. Is that intentional?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
All,
Currently we have 8 patches Ready for Committer in the current CF.
Some of them have been that status for some time.
From traffic on this list, I'm getting the impression that nobody other
than Robert, Heikki and Tom are committing other people's patches. I
know we have more committers
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
pg_dump seems to not dump the owner of extensions. Is that intentional?
Yeah. Partly it was a matter of not wanting to implement ALTER
EXTENSION OWNER, but I think there were some definitional issues too.
See the archives from back
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Why is the posting tree a tree? AFAICS, we never search it using the
TID, it's always scanned in whole. It would be simpler to store the TIDs
in a posting list in no particular order. This could potentially make
insertions
All,
Is the spec for this feature still under discussion? I don't seem to
see a consensus on this thread.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Bruce Momjian br...@momjian.us writes:
Josh Berkus wrote:
BTW, if we're dumping relistemp, we're going to need to notify every
maker of a PostgreSQL admin interface before we release 9.1.
Are they not testing our 9.1 betas?
There has never, ever, been a guarantee that the system catalogs
On 14.07.2011 22:10, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
Why is the posting tree a tree? AFAICS, we never search it using the
TID, it's always scanned in whole. It would be simpler to store the TIDs
in a posting list in no particular order. This could
A couple items for this patch:
The docs state that the variable to receive each diagnostic value needs
to be of the right data type but fails to specify what it is. I think
it'd be good to turn that itemizedlist into a table with three
columns: name, type, description.
This seems poor style:
+
On Jul 14, 2011, at 12:19 PM, Tom Lane wrote:
Are they not testing our 9.1 betas?
There has never, ever, been a guarantee that the system catalogs don't
change across versions. Anybody issuing such queries should expect to
have to retest them and possibly change them in each new major
Florian Pflug wrote:
I still believe the chance of confusion to be extremely small, but since
you feel otherwise, what about Targeted instead of Locked. As in
OID of the relation targeted by the lock, or null if the lock does not
target a relation or part of a relation.
Page number
David E. Wheeler da...@kineticode.com wrote:
A deprecation cycle at least might be useful.
How about a relistemp extension on pgxn.org for the generated
column function to provide the backward compatibility? Is the new
extension mechanism a sane way to help those who need a phase-out
period?
2011/7/14 Alvaro Herrera alvhe...@commandprompt.com:
A couple items for this patch:
The docs state that the variable to receive each diagnostic value needs
to be of the right data type but fails to specify what it is. I think
it'd be good to turn that itemizedlist into a table with three
Excerpts from Pavel Stehule's message of jue jul 14 16:25:56 -0400 2011:
2011/7/14 Alvaro Herrera alvhe...@commandprompt.com:
A couple items for this patch:
it is good idea
Thanks ... I expect you're going to resubmit the patch based on David's
last version and my comments?
--
Álvaro
Do you think using rightlink as pointer to parent page is possible during
index build? It would allow to simplify code significantly, because of no
more need to maintain in-memory structures for parents memorizing.
--
With best regards,
Alexander Korotkov.
2011/7/14 Alvaro Herrera alvhe...@commandprompt.com:
Excerpts from Pavel Stehule's message of jue jul 14 16:25:56 -0400 2011:
2011/7/14 Alvaro Herrera alvhe...@commandprompt.com:
A couple items for this patch:
it is good idea
Thanks ... I expect you're going to resubmit the patch based on
On Jul14, 2011, at 22:18 , Bruce Momjian wrote:
!OID of the database in which the lock target exists, or
!zero if the lock is a shared object, or
!null if the lock is on a transaction ID
For consistency, I think it should say target in the second part
of the sentence
On 14.07.2011 23:41, Alexander Korotkov wrote:
Do you think using rightlink as pointer to parent page is possible during
index build? It would allow to simplify code significantly, because of no
more need to maintain in-memory structures for parents memorizing.
I guess, but where do you store
On Wed, Jul 13, 2011 at 5:59 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
One thing that caught my eye is that when you empty a buffer, you load the
entire subtree below that buffer, down to the next buffered or leaf level,
into memory. Every page in that subtree is kept
Looks good to me.
---
Florian Pflug wrote:
On Jul14, 2011, at 22:18 , Bruce Momjian wrote:
!OID of the database in which the lock target exists, or
!zero if the lock is a shared object, or
!
There has never, ever, been a guarantee that the system catalogs don't
change across versions. Anybody issuing such queries should expect to
have to retest them and possibly change them in each new major release.
I know that's always been our policy. It his, however,
vendor-unfriendly
On Wed, Jul 13, 2011 at 10:56 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Attached is patch for the WAL writer that removes its tight polling
loop (which probably doesn't get hit often in practice, as we just
sleep if wal_writer_delay is under a second), and, at least
potentially, reduces
On Thu, Jul 14, 2011 at 21:59, Josh Berkus j...@agliodbs.com wrote:
There has never, ever, been a guarantee that the system catalogs don't
change across versions. Anybody issuing such queries should expect to
have to retest them and possibly change them in each new major release.
I know
On Thu, Jul 14, 2011 at 8:01 PM, Josh Berkus j...@agliodbs.com wrote:
Currently we have 8 patches Ready for Committer in the current CF.
Some of them have been that status for some time.
From traffic on this list, I'm getting the impression that nobody other
than Robert, Heikki and Tom are
On 14.07.2011 17:28, Teodor Sigaev wrote:
Why is the posting tree a tree? AFAICS, we never search it using the
TID, it's always scanned in whole. It would be simpler to store the TIDs
in a posting list in no particular order. This could potentially make
insertions cheaper, as you could just
On Thursday, July 14, 2011, Josh Berkus j...@agliodbs.com wrote:
There has never, ever, been a guarantee that the system catalogs don't
change across versions. Anybody issuing such queries should expect to
have to retest them and possibly change them in each new major release.
I know that's
On 14.07.2011 11:33, Alexander Korotkov wrote:
On Wed, Jul 13, 2011 at 5:59 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
One thing that caught my eye is that when you empty a buffer, you load the
entire subtree below that buffer, down to the next buffered or leaf level,
I think there's two bugs in the existing gistFindPath code:
if (top-parent XLByteLT(top-parent-lsn,
GistPageGetOpaque(page)-nsn)
GistPageGetOpaque(page)-rightlink !=
InvalidBlockNumber /* sanity check */ )
{
/*
ISTM that you are right that there are other committers that have not
done anything. How strange that you name myself, yet not others.
Touchy today, eh?
And I do name others, read the email again.
Anyway, my question is: the list of committers I know of who have
general knowledge of the
On Jul 14, 2011, at 2:10 PM, Dave Page wrote:
Break compatibility is actually something that is important to us - it
forces us to fix obvious issues, and makes it much harder to
inadvertently miss important changes.
Agreed, but a deprecation cycle would be much appreciated.
David
--
Sent
Josh Berkus wrote:
ISTM that you are right that there are other committers that have not
done anything. How strange that you name myself, yet not others.
Touchy today, eh?
And I do name others, read the email again.
Anyway, my question is: the list of committers I know of who have
As one of said vendors, I completely disagree.
I don't agree that you qualify as a vendor. You're on the friggin' core
team.
I'm talking about vendors like DBVizualizer or TORA, for which
PostgreSQL is just one of the databases they support. If stuff breaks
gratuitously, the reaction of
Josh Berkus j...@agliodbs.com writes:
There are a ton of
things that change with each release, and all we do by putting in
hacks for backwards compatibility is add bloat that needs to be
maintained, and encourage vendors to be lazy.
I don't agree that having comprehensive system views with
I don't agree that having comprehensive system views with multi-version
stability would be a hack.
If we had that, it wouldn't be a hack. Putting in a hack to cover the
specific case of relistemp, on the other hand, is just a hack.
I agree.
--
Josh Berkus
PostgreSQL Experts Inc.
On Jul 14, 2011, at 3:05 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
There are a ton of
things that change with each release, and all we do by putting in
hacks for backwards compatibility is add bloat that needs to be
maintained, and encourage vendors to be lazy.
I don't
Review of patch: https://commitfest.postgresql.org/action/patch_view?id=539
I glanced through the code and played around with the feature and,
in general, it looks pretty good. But I have a some comments/questions.
Design:
First, it makes me uncomfortable that you are using the MCV and
On Thu, Jul 14, 2011 at 4:57 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Thanks Simon for looking at the patch.
Sorry, I didn't notice there was a patch attached. Not reviewed it. I
thought we were still just talking.
I am not sure if the use case is really narrow.
This is a very
Hi Radosław,
Do you plan to comment on this patch (the one that adds support
for XPATH expressions returning scalar values, not the one that
escapes text and attributes nodes which are selected) further,
or should it be marked Ready for Committer?
I'm asking because I just noticed that you
On Thu, Jul 14, 2011 at 6:22 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Jul 14, 2011 at 4:57 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Thanks Simon for looking at the patch.
Sorry, I didn't notice there was a patch attached. Not reviewed it. I
thought we were still just
On Jul 14, 2011, at 5:13 PM, David E. Wheeler da...@kineticode.com wrote:
On Jul 14, 2011, at 3:05 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
There are a ton of
things that change with each release, and all we do by putting in
hacks for backwards compatibility is add bloat
On Jul 14, 2011, at 6:43 PM, Robert Haas wrote:
Is that all I need to do, or is there something else I should be aware of
with regard to unlogged tables?
Probably not, in this case. Just a thought: maybe you could rewrite the query
to check whether the namespace name starts with pg_temp.
(2011/07/15 4:17), Josh Berkus wrote:
All,
Is the spec for this feature still under discussion? I don't seem to
see a consensus on this thread.
Yeah, a remaining concern is whether generic (FDW) options should be
separated from existing attoptions or not.
Indeed, reloptions/attoptions
I have looked into the v6 patches. One thing I would like to suggest
is, enhancing the error message when temp_file_limit will be exceeded.
ERROR: aborting due to exceeding temp file limit
Is it possible to add the current temp file limit to the message? For
example,
ERROR: aborting due
On tor, 2011-07-14 at 12:01 -0700, Josh Berkus wrote:
Currently we have 8 patches Ready for Committer in the current CF.
Some of them have been that status for some time.
From traffic on this list, I'm getting the impression that nobody other
than Robert, Heikki and Tom are committing other
(Going through some loose ends in the information schema ...)
Is my understanding right that the ON COMMIT action of temporary tables
is not recorded in the system catalogs anywhere? Would make sense,
wouldn't be a big problem, just want to make sure I didn't miss
anything.
--
Sent via
Some of these new error messages from the SSI code are a mouthful:
not enough elements in RWConflictPool to record a rw-conflict
not enough elements in RWConflictPool to record a potential rw-conflict
These are basically out of shared memory conditions that could be
moved to a DETAIL
81 matches
Mail list logo
