"Josh Berkus" wrote
> > The other is the connection pool architecture: shall we let
> > postmaster manage the slaves or let another process say slave-master to
> > handle them? Currently I am choosing the latter.
>
> Hmmm. Why not the postmaster?
>
Not real reason just feel that's clearer (but
"Bruce Momjian" wrote
>
> Would some people please run the attached test procedure and report back
> the results? I basically need to know the patch is an improvement on
> more platforms than just my own. Thanks
>
Obviously it matches your expectation.
uname: Linux amd64 2.6.9-5.13smp #1 SMP
QingQing,
> I may have some free time recently to work on the master-slave scan idea.
> I've been able to support AS-IS both SeqScan and IndexScan. Are we still
> interested in getting it into 8.2?
I don't know about anyone else, but *I'm* still interested.
> There are still some problems I am n
Buildfarm member emu is failing in some branches with
checking libintl.h usability... yes
checking libintl.h presence... no
configure: WARNING: libintl.h: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: libintl.h: proceeding with the preprocessor's result
checking for
I may have some free time recently to work on the master-slave scan idea.
I've been able to support AS-IS both SeqScan and IndexScan. Are we still
interested in getting it into 8.2?
There are still some problems I am not quite sure the solution. One is the
Xid assignment -- we need this to assure
Would some people please run the attached test procedure and report back
the results? I basically need to know the patch is an improvement on
more platforms than just my own. Thanks
---
Run this script and record the time
Neil Conway <[EMAIL PROTECTED]> writes:
> On Wed, 2006-06-14 at 16:56 -0400, Bruce Momjian wrote:
>> The code churn to do this is going to be quite significant
> Why do you say that? Although the original patch posted to implement
> this was incomplete, it certainly wasn't very large.
IIRC, the o
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> Not really --- that patch was intended to ensure that LWLocks don't
> unnecessarily cross two cache lines. It doesn't ensure that two
> different LWLocks aren't sharing a cache line. You could do that
> by increasing LWLOCK_PADDED_SIZE to the cache line s
Bruce Momjian wrote:
> I assume the conclusion from this email thread is that though the idea
> is interesting, the complexity added would not be worth the saving of a
> few bytes.
I have same understanding about it. Besides the complexity,
there is trade-off between cpu and i/o resources.
Also,
On Wed, 2006-06-14 at 16:56 -0400, Bruce Momjian wrote:
> The code churn to do this is going to be quite significant
Why do you say that? Although the original patch posted to implement
this was incomplete, it certainly wasn't very large.
-Neil
---(end of broadcast)
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
>>> One thing we tried in February was padding out the statically defined
>>> locks with dummy lock definitions in the enum.
> Has this been done? See the LWLOCK_PADDED_SIZE macro in code.
Not really --- that patch was intended to ensure that LWLocks do
Qingqing Zhou wrote:
>
> "Bruce Momjian" wrote
> >
> > Added to TODO list.
> >
> > > One thing we tried in February was padding out the statically defined
> > > locks with dummy lock definitions in the enum. This has the effect of
> > > ensuring that the most contested locks are very definitely i
"Bruce Momjian" wrote
>
> Added to TODO list.
>
> > One thing we tried in February was padding out the statically defined
> > locks with dummy lock definitions in the enum. This has the effect of
> > ensuring that the most contested locks are very definitely in their own
> > cache line and not sh
Josh Berkus wrote:
Never mind, Neil C. just pointed out that we shouldn't be using
preload_libraries for libumem anyway -- it's sloppy. However, I do think
that we should brace ourselves for a slew of bug reports; if the Sun
testing guys are misusing preload_libraries this way, they won'
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I just thought of a more radical idea: do we need a limit on catcache
> >> size at all? On "normal size" databases I believe that we never hit
> >> 5000 entries at all (at least, last time I ran the CATCACHE_STATS code
> >> on the r
All,
> FATAL: incompatible library "/usr/lib/libumem.so": missing magic block
> HINT: Extension libraries are now required to use the
> PG_MODULE_MAGIC macro.
>
> Should we really be requiring PG_MODULE_MAGIC for stuff that wasn't
> built with PG? This seems like a way to break a lot of peop
Josh Berkus writes:
> I just noticed (the hard way) that in 8.2CVS, the PG_MODULE_MAGIC header is
> now *required* for all loadable modules. This includes non-pg modules,
> such as Solaris' libumem (performance improvement for malloc).
What is libumem and why are you trying to load it as a dy
Bruce Momjian writes:
> Tom Lane wrote:
>> I just thought of a more radical idea: do we need a limit on catcache
>> size at all? On "normal size" databases I believe that we never hit
>> 5000 entries at all (at least, last time I ran the CATCACHE_STATS code
>> on the regression tests, we didn't g
Hey,
I just noticed (the hard way) that in 8.2CVS, the PG_MODULE_MAGIC header is
now *required* for all loadable modules. This includes non-pg modules,
such as Solaris' libumem (performance improvement for malloc).
FATAL: incompatible library "/usr/lib/libumem.so": missing magic block
HINT:
Tom Lane wrote:
> Bruce Momjian writes:
> > I am thinking we should scale it based on max_fsm_relations.
>
> Hmm ... tables are not the only factor in the required catcache size,
> and max_fsm_relations tells more about the total installation size
> than the number of tables in your particular da
Bruce Momjian writes:
> I am thinking we should scale it based on max_fsm_relations.
Hmm ... tables are not the only factor in the required catcache size,
and max_fsm_relations tells more about the total installation size
than the number of tables in your particular database. But it's one
possib
I am thinking we should scale it based on max_fsm_relations.
---
Tom Lane wrote:
> Awhile back, there was a discussion about psql \d display being really
> slow in a database with 4000 tables:
> http://archives.postgresql.or
Awhile back, there was a discussion about psql \d display being really
slow in a database with 4000 tables:
http://archives.postgresql.org/pgsql-hackers/2005-09/msg01085.php
I looked into this some, and it seems that part of the problem is that
the catalog caches are limited to hold no more than 5
I assume no more progress has been made on this?
---
Tom Lane wrote:
> I wrote:
> > Michael Paesold <[EMAIL PROTECTED]> writes:
> >> I am definatly not going to use -march=pentium4 in any production
> >> system. Should I op
kleptog@svana.org (Martijn van Oosterhout) writes:
> On Tue, Jun 13, 2006 at 05:23:56PM -0400, Christopher Browne wrote:
>> > [3]
>> > http://www.intelligententerprise.com/010327/celko_online.jhtml;jsessionid=NDIHEWXGL4TNKQSNDBNSKHSCJUMEKJVN
>>
>> The sample problem in [3] is one that shows pret
Added to TODO:
* Consider increasing internal areas when shared buffers is increased
http://archives.postgresql.org/pgsql-hackers/2005-10/msg01419.php
---
Alvaro Herrera wrote:
> Jim C. Nasby wro
On Wed, Jun 14, 2006 at 06:23:36PM -0400, Bruce Momjian wrote:
> > is making the build step that strips not-officially-exported symbols
> > work on more platforms.
>
> Uh, well, I had some patches in the patch queue to go in that direction,
> but I thought the conclusion in that thread was that it
Bruce Momjian writes:
> Tom Lane wrote:
>> What would make sense to work on
>> is making the build step that strips not-officially-exported symbols
>> work on more platforms.
> Uh, well, I had some patches in the patch queue to go in that direction,
> but I thought the conclusion in that thread w
Tom,
> Speaking of which, is a list of those registered posted anywhere? I
> looked for one the other day because I wanted to double-check that
> I was registered, but couldn't find anything on the website.
No, I think there would be some privacy issues with that. You're
registered. You sho
I wrote:
The main use case seems to me to be where you are exporting a whole
database or most of it with a very large number of tables, and it is
convenient to have all the CSVs created for you rather than have to
make them manually one at a time. You could get these out of, say, a
tar for
Tom Lane wrote:
> Bruce Momjian writes:
> > Thread added to TODO:
> > o Properly mark all libpq-exported functions with "PQ"
>
> Is that still relevant? I thought we'd done as much as we intended
> to do in that specific direction. What would make sense to work on
Oh, OK.
> is making
This patch is too general. It targets all platforms, not just those
that might be affected, and it tries to fix an operating system bug.
Also, we removed the readling linking into the backend in 8.2, so that
is a non-issue now.
---
Josh Berkus writes:
> You and Bruce might want to think about *registering* for the conference.
Speaking of which, is a list of those registered posted anywhere? I
looked for one the other day because I wanted to double-check that
I was registered, but couldn't find anything on the website.
On Wed, Jun 14, 2006 at 05:54:56PM -0400, Bruce Momjian wrote:
>
> Thread added to TODO:
>
> o Properly mark all libpq-exported functions with "PQ"
I thought this was done already. At least, with a recent CVS I get
this:
$ nm -D libpq.so --defined-only |grep -v 'PQ\|pq\|lo_\|pg_'
000171
Bruce Momjian writes:
> Thread added to TODO:
> o Properly mark all libpq-exported functions with "PQ"
Is that still relevant? I thought we'd done as much as we intended
to do in that specific direction. What would make sense to work on
is making the build step that strips not-officiall
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Even if what's being written is a single byte/word and we're taking
> intentional steps to make sure that reading a pointer that's off by 1
> isn't an issue? Is the issue that if CPU A writes a pointer and CPU B
> immediately tries to read it that it c
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Ch
Josh Berkus wrote:
> Luke,
>
> > Ayush and I (along with Brian Hagenbuch) also plan to be in Toronto, so
> > we can help as needed.
>
> You and Bruce might want to think about *registering* for the conference.
I thought I did already. I filled something out a few months ago.
Anyway, it now say
Luke,
> Ayush and I (along with Brian Hagenbuch) also plan to be in Toronto, so
> we can help as needed.
You and Bruce might want to think about *registering* for the conference.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)
Thread added to TODO:
o Properly mark all libpq-exported functions with "PQ"
---
Tom Lane wrote:
> I find that libpq.so exports the following symbols that have neither
> PQ, pq, pg, nor lo_ as a prefix:
>
> Encryp
Added to TODO list.
---
Simon Riggs wrote:
> On Wed, 2005-09-14 at 13:32 -0400, Tom Lane wrote:
> > I wrote:
> > > Another thought came to mind: maybe the current data layout for LWLocks
> > > is bad. Right now, the spinloc
Bruce, Tom, Andrew,
On 6/14/06 11:06 AM, "Andrew Dunstan" <[EMAIL PROTECTED]> wrote:
> The running of extra tests outside our standard regression set will be
> one of the topics discussed during my session in Toronto. I don't mind
> having them stored elsewhere, although it will make things a bit
Joachim Wieland <[EMAIL PROTECTED]> writes:
> Getting a list of active timezones could be easily done
> with a system view but you might not want to promise its existence when you
> think about moving the whole thing to a system catalog later...
A read-only view wouldn't be a bad idea, actually, f
Greg Stark <[EMAIL PROTECTED]> writes:
> Well if all we want to do is reproduce the current functionality of EXPLAIN
> ANALYZE, all you need is a single sig_atomic_t int that you store the address
> of the current node in.
Do I need to point out that sig_atomic_t can't portably be assumed to be
wi
I have update the patch at:
ftp://candle.pha.pa.us/pub/postgresql/mypatches/strict
I re-did it to use STRICT for Oracle PL/SQL syntax. I don't think we
are going to be able to do any better than that, even in future
versions. I added documentation that should help too.
---
On Tue, Jun 13, 2006 at 11:11:26PM +0200, Martijn van Oosterhout wrote:
> I think my actual point was something else. We currently get calls from
> people trying to administer machines that it's annoying that various
> configuration information is stored in files, beyond the easy reach of
> SQL.
W
The code churn to do this is going to be quite significant, as well a
performance-wise hit perhaps, so it has to be a big win.
---
Jim C. Nasby wrote:
> On Wed, Jun 14, 2006 at 04:21:34PM -0400, Bruce Momjian wrote:
> > Jim
On Wed, Jun 14, 2006 at 10:37:59PM +0200, Martijn van Oosterhout wrote:
> On Wed, Jun 14, 2006 at 03:21:55PM -0500, Jim C. Nasby wrote:
> > One idea would be to keep something akin to a FIFO, where the backend
> > would write records instead of updating/over-writing them, and the
> > reader process
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > The numbers I've been looking at lately say that heavy lock traffic is
> > expensive, particularly on SMP machines, even with zero contention.
> > Seems the cache coherency protocol costs a lot even when it's not doing
> > anything...
>
> Are there
On Wed, Jun 14, 2006 at 04:21:34PM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Wed, Jun 14, 2006 at 02:53:10PM -0400, Bruce Momjian wrote:
> > >
> > > I assume the conclusion from this email thread is that though the idea
> > > is interesting, the complexity added would not be worth t
On Wed, Jun 14, 2006 at 03:21:55PM -0500, Jim C. Nasby wrote:
> One idea would be to keep something akin to a FIFO, where the backend
> would write records instead of updating/over-writing them, and the
> reader process would only read records where there was no risk that they
> were still being wr
On Wed, Jun 14, 2006 at 03:51:28PM -0400, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> This sounds good until you think about locking. It'd be quite
> >> impractical to implement anything as fine-grained as EXPLAIN ANALYZE
> >> this way, be
Jim C. Nasby wrote:
> On Wed, Jun 14, 2006 at 02:53:10PM -0400, Bruce Momjian wrote:
> >
> > I assume the conclusion from this email thread is that though the idea
> > is interesting, the complexity added would not be worth the saving of a
> > few bytes.
>
> Anyone do any testing?
>
> I'm also
On Wed, Jun 14, 2006 at 02:53:10PM -0400, Bruce Momjian wrote:
>
> I assume the conclusion from this email thread is that though the idea
> is interesting, the complexity added would not be worth the saving of a
> few bytes.
Anyone do any testing?
I'm also wondering if this would be useful to a
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> This sounds good until you think about locking. It'd be quite
>> impractical to implement anything as fine-grained as EXPLAIN ANALYZE
>> this way, because of the overhead involved in taking and releasing
>> spinlocks.
Thread added to TODO. As far as I can see, this thread never produced
an patch that could be applied.
---
Tom Lane wrote:
> Jeremy Drake <[EMAIL PROTECTED]> writes:
> > On Fri, 23 Sep 2005, Tom Lane wrote:
> >> postgresql-f
I assume the conclusion from this email thread is that though the idea
is interesting, the complexity added would not be worth the saving of a
few bytes.
---
ITAGAKI Takahiro wrote:
> Hi Hackers,
>
> PostgreSQL can treat va
Thead added to TODO.detail.
---
Tatsuo Ishii wrote:
> > 3. Compiled locale files are large. One UTF-8 locale datafile can
> > exceed a megabyte. Do we want the option of disabling it for small
> > systems?
>
> To avoid the
Thread added to TODO.detail.
---
Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Greg Stark <[EMAIL PROTECTED]> writes:
> > > I still doesn't get where the hostility towards this functionality comes
> > > fr
Added to TODO:
o Fix problem when cascading referential triggers make changes on
cascaded tables, seeing the tables in an intermediate state
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00174.php
http://archives.postgresql.org/pgsql-hackers/2005-09/
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > If backends store their current status in shared memory then a separate
> > process entirely can receive the interrupts, scan through the shared memory
> > process states and do the accounting.
>
> This sounds good
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian writes:
Where are we on this? Should we just add a URL to the full 1MB test files?
Adding an MB to the distribution for tests that hardly anyone needs to
run is surely not a good idea. What about putting them on pgfoundry
Thread added to TODO.
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> Hi,
>
> As part of previous discussions about typmod for user type, Tom
> mentioned that you would need to make type and function nam
Tom Lane wrote:
> Bruce Momjian writes:
> > Where are we on this? Should we just add a URL to the full 1MB test files?
>
> Adding an MB to the distribution for tests that hardly anyone needs to
> run is surely not a good idea. What about putting them on pgfoundry and
> then putting a link to th
Bruce Momjian writes:
> Where are we on this? Should we just add a URL to the full 1MB test files?
Adding an MB to the distribution for tests that hardly anyone needs to
run is surely not a good idea. What about putting them on pgfoundry and
then putting a link to that somewhere in the docs?
Where are we on this? Should we just add a URL to the full 1MB test files?
---
Ayush Parashar wrote:
> Hi there,
>
> I am new to this list.
>
> I have made some additions to multi-byte regression tests ( ./src/test/mb),
>
Greg Stark <[EMAIL PROTECTED]> writes:
> If backends store their current status in shared memory then a separate
> process entirely can receive the interrupts, scan through the shared memory
> process states and do the accounting.
This sounds good until you think about locking. It'd be quite
impr
Modified version of this patch applied by Tom.
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Sun, Oct 16, 2005 at 04:06:04PM -0400, Andrew Dunstan wrote:
> > Martin,
> >
> > Let's see the patch. I a
Greg Stark wrote:
And before you ask, yes, virtually every version of Excel has changed its csv
file format.
I'd be interested to hear of Excel variants we haven't catered for - our
CSV parsing is some of the most flexible and complete around, IMNSHO.
BTW, I suspect we won't see too
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>
> >
> >As was stated before, the use-case for this is by people we don't
> >normally have contact with.
> >
> >
> >
>
> I do think we need a use case for what we do.
>
> The main use case seems to me to be where you are exporting a whole
>
Bruce Momjian wrote:
As was stated before, the use-case for this is by people we don't
normally have contact with.
I do think we need a use case for what we do.
The main use case seems to me to be where you are exporting a whole
database or most of it with a very large number of table
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> The CSV definition and its lack of formality is a complete red herring in
> this, as are references to Microsoft.
I think then you've missed the real issue.
> The real issue in what you say here is your suggestion that we might not be
> able to rep
On Wed, Jun 14, 2006 at 10:55:04AM -0400, Bruce Momjian wrote:
> > Once again: give me a plausible use-case for pulling this data out of a
> > pg_dump output file. You'd need data-massaging code anyway just to
> > extract the data, so why not expect that code to convert to CSV or
> > whatever othe
On Tue, Jun 13, 2006 at 09:14:48AM -0700, Joshua D. Drake wrote:
> >I don't get it. If you can use psql then you already have csv support.
> >
> >psql -c 'COPY pg_class TO STDOUT WITH CSV' postgres > pg_class.csv
>
> If you data looks like this:
>
> foo barbaz bing
>
> You are o.k. You have t
Martijn van Oosterhout writes:
> With one big exception: sometimes I/O is non-interruptable (the good
> old D state). In this case the interrupts will happen but will simply
> be queued and in fact will all be dropped except the last one
> (non-realtime signals are never stacked). The handler wi
Tom Lane wrote:
> Bruce Momjian writes:
> > As was stated before, the use-case for this is by people we don't
> > normally have contact with.
>
> Or who don't exist.
>
> Once again: give me a plausible use-case for pulling this data out of a
> pg_dump output file. You'd need data-massaging code
Bruce Momjian writes:
> As was stated before, the use-case for this is by people we don't
> normally have contact with.
Or who don't exist.
Once again: give me a plausible use-case for pulling this data out of a
pg_dump output file. You'd need data-massaging code anyway just to
extract the data
Tom Lane wrote:
> Bruce Momjian writes:
> > I agree with Andrew. If there are bugs in CSV, then we should fix them,
> > not avoid give users this usability improvement.
>
> The case for it being a usability improvement seems very weak to me;
> no one has yet demonstrated an actual use-case where
Bruce Momjian writes:
> I agree with Andrew. If there are bugs in CSV, then we should fix them,
> not avoid give users this usability improvement.
The case for it being a usability improvement seems very weak to me;
no one has yet demonstrated an actual use-case where someone would pull
CSV data
I did some work on your patch:
ftp://candle.pha.pa.us/pub/postgresql/mypatches/first
I switched the name of the option flag to FIRST (already a reserved
word), making the default behavior PL/SQL-compatible. I also added the
proper execptions to match PL/SQL. My Oracle 9 PL/SQL manual h
I agree with Andrew. If there are bugs in CSV, then we should fix them,
not avoid give users this usability improvement. I know I have analyzed
the code and fixed a few problems with it in the past.
As far as pg_dump, I am thinking the most flexible solution would be to
allow an arbitrary WITH
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> This is just nonsense. There is not the slightest reason that CSV data
>> cannot be embedded in a text dump nor exist as the data members of a
>> custom or tar dump with the corresponding COPY statements modified
>> accordingly.
>
> We
On Tue, Jun 13, 2006 at 10:36:27PM -0400, Tom Lane wrote:
> * not clear whether the interrupt happens when waiting for I/O. I
> already mentioned that this would be a problem for EXPLAIN ANALYZE,
> but it might be no big deal for the other uses.
If we're going y UNIX signal semantics, in theory a
83 matches
Mail list logo
