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 me
(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 pgsql-
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
>> 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,
>>
>> ERR
(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 m
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_
On Jul 14, 2011, at 5:13 PM, "David E. Wheeler" wrote:
> On Jul 14, 2011, at 3:05 PM, Tom Lane wrote:
>
>> Josh Berkus 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
On Thu, Jul 14, 2011 at 6:22 PM, Simon Riggs wrote:
> On Thu, Jul 14, 2011 at 4:57 PM, Pavan Deolasee
> 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.
>
>
No problem. Please revie
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 mark
On Thu, Jul 14, 2011 at 4:57 PM, Pavan Deolasee
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 rare issue, because of all
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 histogram
On Jul 14, 2011, at 3:05 PM, Tom Lane wrote:
> Josh Berkus 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
>> 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.
Josh Berkus 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 multi-vers
> 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 som
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
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
--
Sen
> 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 cod
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 */ )
{
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,
On Thursday, July 14, 2011, Josh Berkus 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 always b
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 appen
On Thu, Jul 14, 2011 at 8:01 PM, 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 o
On Thu, Jul 14, 2011 at 21:59, Josh Berkus 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 alway
On Wed, Jul 13, 2011 at 10:56 PM, Peter Geoghegan 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 power consumption
> 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 bec
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
> > !
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 k
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 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 sentenc
2011/7/14 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of jue jul 14 16:25:56 -0400 2011:
>> 2011/7/14 Alvaro Herrera :
>> > 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?
>
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.
Excerpts from Pavel Stehule's message of jue jul 14 16:25:56 -0400 2011:
> 2011/7/14 Alvaro Herrera :
> > 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 Herrera
The PostgreSQL Comp
2011/7/14 Alvaro Herrera :
> 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 into a table with three
> columns: name, type, description.
"David E. Wheeler" 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?
-Kevin
--
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.
>
> Pa
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
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 into a table with three
columns: name, type, description.
This seems poor style:
+
On 14.07.2011 22:10, Tom Lane wrote:
Heikki Linnakangas 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 cheaper,
Bruce Momjian 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 don't
change a
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:
http://www.postgres
Heikki Linnakangas 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 cheaper, as you could just append to
Heikki Linnakangas 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 around February or so.
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 t
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:
http://www.postgresql.org/mailpref/pgsql-hacker
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 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 going
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 data
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" m
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 Riggs
>> wrote:
>>
>>> I'd say that seems way too complex for such a small use case and we've
>>>
>>> only j
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 l
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 ht
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 li
On Wed, Jun 15, 2011 at 10:53, Ahmed Shinwari 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 R2/Windows 7
Than
On Jul 13, 2011, at 12:29 PM, "Fernando Acosta Torrelly"
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?
>
> Thanks in adv
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 te
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 ta
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 ve
"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 front of
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 fron
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 de
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 b
On 14.07.2011 18:57, Pavan Deolasee wrote:
On Thu, Jul 14, 2011 at 11:46 AM, Simon Riggs 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 that such changes are
On Thu, Jul 14, 2011 at 10:53 AM, Heikki Linnakangas
wrote:
> On 14.07.2011 12:42, Simon Riggs wrote:
>>
>> On Thu, Jul 14, 2011 at 9:57 AM, Fujii Masao
>> wrote:
>>
>>> Currently walwriter might write out the WAL before a transaction commits.
>>> IOW, walwriter tries to write out the WAL in wal_
On 14.07.2011 12:42, Simon Riggs wrote:
On Thu, Jul 14, 2011 at 9:57 AM, Fujii Masao 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 gener
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
On ons, 2011-07-13 at 11:58 +0200, Nicolas Barbier wrote:
> 2011/6/29, Florian Pflug :
>
> > 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 that c
On Tue, Jul 12, 2011 at 9:47 PM, Pavan Deolasee
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 work is HOT-pruned so
On Thu, Jul 14, 2011 at 11:46 AM, Simon Riggs 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 really
> worth it.
>
On Mon, Jun 6, 2011 at 10:33 AM, Heikki Linnakangas
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.
>
>> @@ -2518,7 +2518,7
2011/5/26 MauMau :
> 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
> http://archive
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 ar
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 con
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 integer
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 par
On Thu, Jul 14, 2011 at 9:57 AM, Fujii Masao 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
> records before com
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 b
On Thu, Jul 14, 2011 at 5:39 PM, Simon Riggs wrote:
> On Wed, Jul 13, 2011 at 10:56 PM, Peter Geoghegan
> 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 se
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 - Pe
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 (pgsql-hackers@postgresql
79 matches
Mail list logo
