On Sat, 2004-10-09 at 05:35, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > I tried to use regclass() in a plpgsql function to derive a tablename
> > from its oid so as to build a command string, but I am unable to use the
> > value returned because it cannot be cast to anything.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What do people think about using (sizeof(struct passwd) + BUFLEN/2) rather
> than BUFLEN for the getpwuid_r size, or (sizeof(struct passwd) + MAXPGPATH*2)?
> That would reduce the stack requirements and still be safe, I think.
Why bother?
Peter did not
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Reini Urban wrote:
>>> Now that postgres 8.0 is win32 native is it still necessary support the
>>> cygwin ?
>>
>> FYI: If you drop it I will still provide cygwin packages. I just need it
>> for testing and writing applications targetted to unix. With w
Oliver Elphick <[EMAIL PROTECTED]> writes:
> I tried to use regclass() in a plpgsql function to derive a tablename
> from its oid so as to build a command string, but I am unable to use the
> value returned because it cannot be cast to anything. Therefore I will
> have to use a complex query on th
What do people think about using (sizeof(struct passwd) + BUFLEN/2) rather
than BUFLEN for the getpwuid_r size, or (sizeof(struct passwd) + MAXPGPATH*2)?
That would reduce the stack requirements and still be safe, I think.
--
Tom Lane wrote:
> "Dave Page" <[EMAIL PROTECTED]> writes:
> > I was hoping this would be in for beta 3, but alas - can someone
> > *please* commit the win32 version patch at:
> > http://candle.pha.pa.us/mhonarc/patches/msg0.html
>
> Personally I was holding off in hopes of seeing a cleaner sol
Even though I am unsure about the feature addition, I am keeping this
for 8.1 in case someone else finds it useful.
This has been saved for the 8.1 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Danie
No one has ever asked for a kerberos service name different from
"postgres". Unless someone else says this is a useful feature, I
think we are better off leaving our code unchanged.
Kerberos is pretty complicated so adding another configuration options
isn't always a good idea.
Oliver Elphick wrote:
I tried to use regclass() in a plpgsql function to derive a tablename
from its oid so as to build a command string, but I am unable to use the
value returned because it cannot be cast to anything. Therefore I will
have to use a complex query on the catalog to do the same work
"Querying the Internet with PIER" is an interesting recent paper.
Authored at Berkeley -- same spawning grounds as PostgreSQL.
;-)
Authors:
Ryan Huebsch, Joseph M. Hellerstein, Nick Lanham, Boon Thau Loo, Scott
Shenker, Ion Stoica
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto
Reini Urban wrote:
> Gaetano Mendola schrieb:
> > Bruce Momjian wrote:
> >> I just made some major Win32 modifications in the past few days. Would
> >> you try Cygwin compile and see if the following warnings are removed and
> >> the rest of the system builds OK?
> >
> > Now that postgres 8.0 is
Michael Paesold wrote:
> Alvaro Herrera Munoz wrote:
>
> > I think it would be wise to create a function to discover what savepoints
> > are available, and from that know when to release an automatically-
> > established savepoint.
> >
> > Of course, the function would only work when the backend i
Release 8.0.0.0beta3
I tried to use regclass() in a plpgsql function to derive a tablename
from its oid so as to build a command string, but I am unable to use the
value returned because it cannot be cast to anything. Therefore I will
have to use a complex query on the catalog to do the same work
> "Yann" == Yann Michel <[EMAIL PROTECTED]> writes:
Yann> O.K. I downloaded it :-) We will see if and how I can
Yann> help
FYI .. in case you aren't aware already:
http://portal.acm.org/citation.cfm?id=98720
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
IMHO the best references to parallelizing query plans are in the
Volcano papers. The Exchange operator is a really clean abstraction -
the idea is to place the Exchange operator in query plans and that way
you don't have to paralellize any other operator. Exchange takes care
of managing the IPC qu
> "Marc" == Marc G Fournier <[EMAIL PROTECTED]> writes:
Marc> On Thu, 7 Oct 2004, Bruce Momjian wrote:
>> Added to TODO:
>>
>> * Consider parallel processing a single query
>>
>> This would involve using multiple threads or processes to do
>> optimization, sortin
Gaetano Mendola schrieb:
Bruce Momjian wrote:
I just made some major Win32 modifications in the past few days. Would
you try Cygwin compile and see if the following warnings are removed and
the rest of the system builds OK?
Now that postgres 8.0 is win32 native is it still necessary support the
c
Bruce Momjian wrote:
I just made some major Win32 modifications in the past few days. Would
you try Cygwin compile and see if the following warnings are removed and
the rest of the system builds OK?
Now that postgres 8.0 is win32 native is it still necessary support the cygwin ?
Regards
Gaetano M
Mariposa was an interesting cost-based distributed query engine based
upon PostgreSQL.
Perhaps that study may prove valuable insights.
http://epoch.cs.berkeley.edu:8000/mariposa/
---(end of broadcast)---
TIP 8: explain analyze is your friend
A while back I was looking the backend code in preparation to start
beginning to look at parallelization techniques for PG ;)... My
thought was instead of trying to parallelize each individual plan node
(multi-process sort, etc.) I would look at creating worker
threads/processes for each plan node
Postgresql Hackers,
Just a quick but heartfelt "Thank You!" to all of you who make
postgresql as sturdy as it is. Noon today, our datacenter provider
suffered an, um, interruption in their uninterruptable redundant power
supply systems. Power was restored seconds later, and this is what the
pos
Euler Taveira de Oliveira <[EMAIL PROTECTED]> writes:
> Sorry for the delay (I have some trouble with my modem). Attached is
> the initdb and backend bootstrap backtrace. Seems to be something in
> the smgr, I couldn't figure out.
Whatever this is, it's local to your build, because no one else is
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Not sure how serious this is since we have gotten few complaints about
it but clearly it should be fixed.
Personally I'm inclined to leave it for 8.1. The inet/cidr code is
really designed around the assumption that these datatypes
Alvaro Herrera Munoz wrote:
I think it would be wise to create a function to discover what savepoints
are available, and from that know when to release an automatically-
established savepoint.
Of course, the function would only work when the backend is not in abort
state, but I think that's a reaso
Hi Josh,
On Fri, Oct 08, 2004 at 10:18:27AM -0700, Josh Berkus wrote:
>
> > I'd like to help you, but I think, that my C-Experience is not good
> > enough for beeing able to. I mean, I coded some C-stuff and I know how
> > bitmap indexes (should) work but I guess that this won't be enough. In
> >
On Fri, Oct 08, 2004 at 08:40:56PM +0200, Michael Paesold wrote:
> I hope you will be willing to comment on the issues when times come. I am
> not really satisfied myself, but without further discussion I did not want
> to continue to work on it. Anyway, I understand this is not the right time
Bruce Momjian <[EMAIL PROTECTED]> wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I assume this is to be saved for 8.1.
I assumed that to, so I did not want to disturb any more now.
> This has been saved for the 8.1 release:
> http:/momjian.postgresql.org/cgi-bin/pgpatches2
Tom Lane wrote:
It i
Andreas Pflug wrote:
"W. Europe Daylight Time" on my system.
With my german system it is "Westeuropäische Sommerzeit".
which is longer then the actual timestamp:
2004-09-26 11:56:55
Westeuropäische Sommerzeit
Any fix is appreciated!
Best Regards,
Michael Paesold
---(end of b
Bruce Momjian <[EMAIL PROTECTED]> writes:
> However, I actually prefer the mail header style of timezone to EST/EDT
> anyway:
Agreed, but AFAIK there's no portable way to ask strftime for that,
so you're still stuck with a compatibility problem. We could teach
pg_strftime to do it, but that's som
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I was thinking of adding %z as an option to log_line prefix, so to get
the current output you would do '%t %z'. I was not suggesting changing
the %Z passed to strftime if they ask for timezone.
I think this is a bad idea, mainly because yo
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I was thinking of adding %z as an option to log_line prefix, so to get
> > the current output you would do '%t %z'. I was not suggesting changing
> > the %Z passed to strftime if they ask for timezone.
>
> I think this is a bad idea,
Yann,
> I'd like to help you, but I think, that my C-Experience is not good
> enough for beeing able to. I mean, I coded some C-stuff and I know how
> bitmap indexes (should) work but I guess that this won't be enough. In
> addidtion I never took a look into postgresql's sources.
Well, there's no
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was thinking of adding %z as an option to log_line prefix, so to get
> the current output you would do '%t %z'. I was not suggesting changing
> the %Z passed to strftime if they ask for timezone.
I think this is a bad idea, mainly because you couldn't
Hi Josh,
On Fri, Oct 08, 2004 at 09:59:41AM -0700, Josh Berkus wrote:
>
> > > Lots of people have talked about it but I don't know anyone coding it.
>
> I would love to have bitmap indexes in Postgres, as would a lot of other
> community members. However, they are far from trivial to code. A
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am still trying to figure out a good way to fix this. On unix my log
> > shows EDT but Win32 shows US/Eastern and some zones are much longer.
> > Should we add %z and not print the timezone information for %t? That
> > seems like t
Yann,
> > Lots of people have talked about it but I don't know anyone coding it.
I would love to have bitmap indexes in Postgres, as would a lot of other
community members. However, they are far from trivial to code. Are you
offering to help?
--
Josh Berkus
Aglio Database Solutions
San Fra
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am still trying to figure out a good way to fix this. On unix my log
> shows EDT but Win32 shows US/Eastern and some zones are much longer.
> Should we add %z and not print the timezone information for %t? That
> seems like the only reasonable solutio
Andreas Pflug wrote:
Bruce Momjian wrote:
I am still trying to figure out a good way to fix this. On unix my log
shows EDT but Win32 shows US/Eastern and some zones are much longer.
"W. Europe Daylight Time" on my system.
Should we add %z and not print the timezone information for %t? That
seems
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Not sure how we can fix this without modifying the system tables.
We can't: the only possible fix is to make inet-to-cidr not be a binary
compatible conversion but instead have an actual conversion function.
IMO the other direction should probably not b
Neil Conway wrote:
> Marc G. Fournier wrote:
> > Do we have 'make backend thread safe' listed yet? As I recall it, until
> > that gets done, parallelization of anything was considered to be a
> > relatively onerous task, no?
>
> ISTM there's no reason we couldn't parallelize query execution usi
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I assume this is to be saved for 8.1.
>
> > This has been saved for the 8.1 release:
> > http:/momjian.postgresql.org/cgi-bin/pgpatches2
>
> It is not remotely ready to apply yet, so please do not put it in the
> queue.
That que
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I assume this is to be saved for 8.1.
> This has been saved for the 8.1 release:
> http:/momjian.postgresql.org/cgi-bin/pgpatches2
It is not remotely ready to apply yet, so please do not put it in the
queue.
regards, tom l
Bruce Momjian wrote:
I am still trying to figure out a good way to fix this. On unix my log
shows EDT but Win32 shows US/Eastern and some zones are much longer.
"W. Europe Daylight Time" on my system.
Should we add %z and not print the timezone information for %t? That
seems like the only reasona
I assume this is to be saved for 8.1.
This has been saved for the 8.1 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Michael Paesold wrote:
> Tom Lane wrote:
>
> > "Michael Paesold" <[EMAIL PROTECTED
Marc G. Fournier wrote:
Do we have 'make backend thread safe' listed yet? As I recall it, until
that gets done, parallelization of anything was considered to be a
relatively onerous task, no?
ISTM there's no reason we couldn't parallelize query execution using the
same IPC techniques that we us
Marc G. Fournier wrote:
> On Thu, 7 Oct 2004, Bruce Momjian wrote:
>
> >
> > Added to TODO:
> >
> > * Consider parallel processing a single query
> >
> > This would involve using multiple threads or processes to do optimization,
> > sorting, or execution of single query. The major advantage of
On Thu, 7 Oct 2004, Bruce Momjian wrote:
Added to TODO:
* Consider parallel processing a single query
This would involve using multiple threads or processes to do optimization,
sorting, or execution of single query. The major advantage of such a
feature would be to allow multiple CPUs to work t
I am still trying to figure out a good way to fix this. On unix my log
shows EDT but Win32 shows US/Eastern and some zones are much longer.
Should we add %z and not print the timezone information for %t? That
seems like the only reasonable solution.
Yesterday I applied a patch that fixed incorrect restriction checking on
CIDR data. Our old code didn't check the last byte for non-zero values
so '1.1.1.1/25'::cidr would be accepted but '1.1.1.1/24'::cidr would
not. Both should be rejected as cidr types, though they are OK for
inet.
The new pr
"Zeugswetter Andreas DAZ SD" <[EMAIL PROTECTED]> writes:
>> Good point. Should we obscure pg_tablespace similarly to
>> what we do for pg_shadow?
> Hmm, I can not see how a person with file access could not easily find the
> file for a specific table without pg_tablespace anyway (since oid name
Hi Gavin,
> > > > I saw a initdb crashes when it is creating the template1
> database.
> > > I
> > > > couldn't figure out what is wrong. I attached the backtrace and
> > > some
> > > > architecture/compiler info.
> > > > If someone needs more info, drop me a line.
> > >
> > > Can you run initdb
> > If they are using tablespaces is it OK that anyone can see their
> > location?
>
> Good point. Should we obscure pg_tablespace similarly to
> what we do for pg_shadow?
Hmm, I can not see how a person with file access could not easily find the
file for a specific table without pg_tablespac
On Fri, 8 Oct 2004, Yann Michel wrote:
Hi,
On Fri, Oct 08, 2004 at 10:09:18AM +0100, Dave Page wrote:
I think what Reini was asking was why do you think you need bitmap
indexes as opposed to any existing type?
due to I'm developing a datawarehousing application we have lots of
fact-data in our cent
On R, 2004-10-08 at 12:45, Yann Michel wrote:
> Hi,
>
> On Fri, Oct 08, 2004 at 10:09:18AM +0100, Dave Page wrote:
> > I think what Reini was asking was why do you think you need bitmap
> > indexes as opposed to any existing type?
>
> due to I'm developing a datawarehousing application we have l
Hi,
On Fri, Oct 08, 2004 at 10:09:18AM +0100, Dave Page wrote:
> I think what Reini was asking was why do you think you need bitmap
> indexes as opposed to any existing type?
due to I'm developing a datawarehousing application we have lots of
fact-data in our central fact-table. As I know how to
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Yann Michel
> Sent: 08 October 2004 08:28
> To: Reini Urban
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] plans for bitmap indexes?
>
>
> I don't know what this means to my questin, but anyway..
Hi,
On Thu, Oct 07, 2004 at 06:54:15PM -0400, Bruce Momjian wrote:
> > I'd like to know if there are any plans on introducing bitmap indexes
> > into postgresql. I think this could mean a big performance improvement
> > especially for datawarehousing applications. I know that there is an
> > index
Hi,
On Thu, Oct 07, 2004 at 10:41:04PM +0200, Reini Urban wrote:
> >I'd like to know if there are any plans on introducing bitmap indexes
> >into postgresql. I think this could mean a big performance improvement
> >especially for datawarehousing applications. I know that there is an
> >index type
58 matches
Mail list logo
