Thanks to everyone for the feedback that I've received so far. It's
clear that there's interest in this.
On Jun 12, 2006, at 3:22 , Josh Berkus wrote:
I do think Jim is right, though, in that we may want to look for
portions of
the functionality which are achievable in the context of one
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 any
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.
Well, the
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
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
Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Martijn van Oosterhout kleptog@svana.org 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).
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 three
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 other
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 reproduce
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
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
database or most of
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
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 assume
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
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),
to
Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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 names
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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 until you
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
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
from.
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
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
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-fe.h
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.
I'm not
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
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 wondering if
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, because of the
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
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 the saving
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 any ways we
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 would
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 C.
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.
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
wider
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, for
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 more
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 spinlock that
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:
EncryptMD5
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
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 says
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.
---
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 could
Bruce Momjian pgman@candle.pha.pa.us 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
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_'
000171e0 D
Josh Berkus josh@agliodbs.com 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
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.
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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.
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
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
Bruce Momjian pgman@candle.pha.pa.us 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
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
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
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 pretty nicely
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 open a bug
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
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:
Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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:
Bruce Momjian pgman@candle.pha.pa.us 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,
Josh Berkus josh@agliodbs.com 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
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 people's
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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
Bruce Momjian pgman@candle.pha.pa.us 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
Qingqing Zhou wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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 don't
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
Bruce Momjian pgman@candle.pha.pa.us 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
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 size for
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
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
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
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
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 not
81 matches
Mail list logo
