Re: [HACKERS] Approved
See the attached file for details ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] SQL99 hierarchical queries stalled
David-- My boss has given me approval to put up to 8 hours per week of SourceLabs' time in on the SQL99 hierarchical query implementation. (I'm free, of course, to supplement this with whatever of my own time I can spare.) I'm willing to take on the work. What's the next step? --Jason ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Development with Eclipse - Wrong error messages in IDE
> On Feb 3, 2016, at 2:38 AM, Peter Moser wrote: > > Does anyone had similar problems? Do I have to configure Eclipse to > understand the PG_RMGR macro or is there another possibility to teach Eclipse > these macros? I just built 9.6 under Eclipse CDT to try this out and was able to open e.g. heapam.c without any error markers. I added PostgreSQL as a “Makefile Project with Existing Code” after running ./configure from the command-line. After that, I built the project from within Eclipse by adding the ‘all’ make target and running it. One setting I usually change: right-click the project, pick Properties, then drill down through C/C++ General -> Preprocessor Include Paths. In the Provider pane, there is an entry for “CDT GCC Build Output Parser”. I’m not sure if this is strictly necessary, but I set my “Container to keep discovered entries” setting to “File”. Basically, Eclipse scans the make output for -I flags, then notes all the includes used to build each file, so the static analyzer, etc. can have more accurate information (it is crucial that the “Compiler command pattern” in this window be a regex that will match the compiler binary you use, so if you have /usr/local/bin/gcc, and “gcc” is the pattern, you are in for trouble). After running the build, Eclipse should now know what includes are used for each file and stop whining. If it ever seems to have problems, you can kick it by running a clean target, then all, then picking “Project -> C/C++ Index -> Rebuild” (I think). -- Jason Petersen Software Engineer | Citus Data 303.736.9255 ja...@citusdata.com signature.asc Description: Message signed with OpenPGP using GPGMail
[HACKERS] Clarification of FDW API Documentation
I've been deep in the FDW APIs lately and have come up with a couple of questions about the [user-facing documentation][1]. # Requirement that DELETE use junk columns The bit I'm confused by is the parenthetical in this bit at the end of the section on `AddForeignUpdateTargets`: > If the AddForeignUpdateTargets pointer is set to NULL, no extra target > expressions are added. (This will make it impossible to implement DELETE > operations, though UPDATE may still be feasible if the FDW relies on an > unchanging primary key to identify rows.) Later on, the section on `ExecForeignDelete` says (emphasis mine): > The junk column(s) **must** be used to identify the tuple to be deleted. Why is this a requirement? At the moment, `postgres_fdw` asks remote machines for the `ctid` of tuples during a scan so it can use that `ctid` to create a targeted `DELETE` during `ExecForeignDelete`, but I think an alternative could avoid the use of the `ctid` junk column altogether... Imagine if `BeginForeignScan` set up a remote cursor and `IterateForeignScan` just fetched _one tuple at a time_ (unlike the current behavior where they are fetched in batches). The tuple would be passed to `ExecForeignDelete` (as is required), but the remote cursor would remain pointing at that tuple. Couldn't `ExecForeignDelete` just call `DELETE FROM table WHERE CURRENT OF cursor` to then delete that tuple? Even if there is no guarantee that `IterateForeignScan` is called exactly once before each `ExecForeignDelete` call (which would remove the ability to have them cooperate using this single cursor), one could easily devise other storage backends that don't need "junk" columns to perform `DELETE` operations. So why the strong language around this functionality? # Examples of `NULL` return after modification Each of the `ExecForeign`- functions needs to return a tuple representing the row inserted, deleted, or modified. But each function's documentation contains an aside similar to this: > The return value is either a slot containing the data that was actually > inserted (this might differ from the data supplied, for example as a result > of trigger actions), or NULL if no row was actually inserted (again, > typically as a result of triggers). Is this even accurate in PostgreSQL 9.3? Can triggers fire against foreign tables? If so, can someone provide an example where the foreign scan has found a tuple, passed it to `ExecForeignDelete`, and then no delete takes place (i.e. `ExecForeignDelete` returns `NULL`)? As far as I can reason, if the foreign scan has found a tuple, the update and delete actions need to do _something_ with it. Maybe I'm missing something. --Jason [1]: http://www.postgresql.org/docs/9.3/static/fdw-callbacks.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Suspicion of a compiler bug in clang: using ternary operator in ereport()
I realize Postgres’ codebase is probably intractably large to begin using a
tool like splint (http://www.splint.org ), but this is exactly the sort of
thing it’ll catch. I’m pretty sure it would have warned in this case that the
code relies on an ordering of side effects that is left undefined by C
standards (and as seen here implemented differently by two different compilers).
The workaround is to make separate assignments on separate lines, which act as
sequence points to impose a total order on the side-effects in question.
—Jason
On Jan 28, 2014, at 2:12 PM, Christian Kruse wrote:
> Hi,
>
> On 28/01/14 16:43, Christian Kruse wrote:
>> ereport(FATAL,
>> (errmsg("could not map anonymous shared memory:
>> %m"),
>> (errno == ENOMEM) ?
>> errhint("This error usually means that
>> PostgreSQL's request "
>> "for a shared memory segment
>> exceeded available memory "
>> "or swap space. To reduce the
>> request size (currently "
>> "%zu bytes), reduce
>> PostgreSQL's shared memory usage, "
>> "perhaps by reducing
>> shared_buffers or "
>> "max_connections.",
>> *size) : 0));
>>
>> did not emit a errhint when using clang, although errno == ENOMEM was
>> true. The same code works with gcc.
>
> According to http://llvm.org/bugs/show_bug.cgi?id=18644#c5 this is not
> a compiler bug but a difference between gcc and clang. Clang seems to
> use a left-to-right order of evaluation while gcc uses a right-to-left
> order of evaluation. So if errmsg changes errno this would lead to
> errno == ENOMEM evaluated to false. I added a watch point on errno and
> it turns out that exactly this happens: in src/common/psprintf.c line
> 114
>
> nprinted = vsnprintf(buf, len, fmt, args);
>
> errno gets set to 0. This means that we will miss errhint/errdetail if
> we use errno in a ternary operator and clang.
>
> Should we work on this issue?
>
> Best regards,
>
> --
> Christian Kruse http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Move unused buffers to freelist
Bump. I’m interested in many of the issues that were discussed in this thread. Was this patch ever wrapped up (I can’t find it in any CF), or did this thread die off? —Jason On Aug 6, 2013, at 12:18 AM, Amit Kapila wrote: > On Friday, June 28, 2013 6:20 PM Robert Haas wrote: >> On Fri, Jun 28, 2013 at 12:52 AM, Amit Kapila >> wrote: >>> Currently it wakes up based on bgwriterdelay config parameter which >> is by >>> default 200ms, so you means we should >>> think of waking up bgwriter based on allocations and number of >> elements left >>> in freelist? >> >> I think that's what Andres and I are proposing, yes. >> >>> As per my understanding Summarization of points raised by you and >> Andres >>> which this patch should address to have a bigger win: >>> >>> 1. Bgwriter needs to be improved so that it can help in reducing >> usage count >>> and finding next victim buffer >>> (run the clock sweep and add buffers to the free list). >> >> Check. > I think one way to handle it is that while moving buffers to freelist, > if we find > that there are not enough buffers (>= high watermark) which have zero > usage count, > then move through buffer list and reduce usage count. Now here I think > it is important > how do we find that how many times we should circulate the buffer list > to reduce usage count. > Currently I have kept it proportional to number of times it failed to > move enough buffers to freelist. > >>> 2. SetLatch for bgwriter (wakeup bgwriter) when elements in freelist >> are >>> less. >> >> Check. The way to do this is to keep a variable in shared memory in >> the same cache line as the spinlock protecting the freelist, and >> update it when you update the free list. > > > Added a new variable freelistLatch in BufferStrategyControl > >>> 3. Split the workdone globallock (Buffreelist) in StrategyGetBuffer >>> (a spinlock for the freelist, and an lwlock for the clock sweep). >> >> Check. > > Added a new variable freelist_lck in BufferStrategyControl which will be > used to protect freelist. > Still Buffreelist will be used to protect clock sweep part of > StrategyGetBuffer. > > > >>> 4. Separate processes for writing dirty buffers and moving buffers to >>> freelist >> >> I think this part might be best pushed to a separate patch, although I >> agree we probably need it. >> >>> 5. Bgwriter needs to be more aggressive, logic based on which it >> calculates >>> how many buffers it needs to process needs to be improved. >> >> This is basically overlapping with points already made. I suspect we >> could just get rid of bgwriter_delay, bgwriter_lru_maxpages, and >> bgwriter_lru_multiplier altogether. The background writer would just >> have a high and a low watermark. When the number of buffers on the >> freelist drops below the low watermark, the allocating backend sets >> the latch and bgwriter wakes up and begins adding buffers to the >> freelist. When the number of buffers on the free list reaches the >> high watermark, the background writer goes back to sleep. Some >> experimentation might be needed to figure out what values are >> appropriate for those watermarks. In theory this could be a >> configuration knob, but I suspect it's better to just make the system >> tune it right automatically. > > Currently in Patch I have used low watermark as 1/6 and high watermark as > 1/3 of NBuffers. > Values are hardcoded for now, but I will change to guc's or hash defines. > As far as I can think there is no way to find number of buffers on freelist, > so I had added one more variable to maintain it. > Initially I thought that I could use existing variables firstfreebuffer and > lastfreebuffer to calculate it, but it may not be accurate as > once the buffers are moved to freelist, these don't give exact count. > > The main doubt here is what if after traversing all buffers, it didn't find > enough buffers to meet > high watermark? > > Currently I just move out of loop to move buffers and just try to reduce > usage count as explained in point-1 > >>> 6. There can be contention around buffer mapping locks, but we can >> focus on >>> it later >>> 7. cacheline bouncing around the buffer header spinlocks, is there >> anything >>> we can do to reduce this? >> >> I think these are points that we should leave for the future. > > This is just a WIP patch. I have kept
[HACKERS] BuildTupleFromCStrings Memory Documentation?
Within the core codebase, BuildTupleFromCStrings is often called within a temporary memory context cleared after the call. In dblink.c, this is justified as being needed to “[clean up] not only the data we have direct access to, but any cruft the I/O functions might leak”.I wrote a pretty minimal case to call BuildTupleFromCStrings in a loop (attached) and found that I was using 40GB of RAM in a few minutes, though I was not allocating any memory myself and immediately freed the tuple it returned.Is the need to wrap this call in a protective context documented anywhere? Portions of the documentation use BuildTupleFromCStrings in examples without mentioning this precaution. Is it just well-known, or did I miss a README or comment somewhere? --Jason PetersenSoftware Engineer | Citus Data303.736.9255ja...@citusdata.com tup_memleak.c Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
[HACKERS] Query Deparsing Support
The DDL deparse support that just landed looks impressive, but I’ve needed query deparsing for some time now. Within pg_shard <https://github.com/citusdata/pg_shard> we took the fast-and-dirty approach of merging in a modified ruleutils.c, though I’d (obviously) like to get away from that. Many of ruleutils.c’s functions already have a public interface; would there be any objection to exposing get_query_def to provide a way to turn a Query back into an SQL string? A more structured approach analogous to the new DDL stuff would make my life easier, but simply having the Query-to-SQL function would be a huge improvement for now. I trawled through the archives but couldn’t find any discussion of why this function was kept static. -- Jason Petersen Software Engineer | Citus Data 303.736.9255 ja...@citusdata.com signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [HACKERS] Debian readline/libedit breakage
On Wed, Feb 16 2011, Tom Lane wrote: > Stephen Frost writes: >> * Tom Lane (t...@sss.pgh.pa.us) wrote: >>> In particular, getting rid of use of OpenSSL would not be sufficient >>> to satisfy the most rabid GPL partisans that we were in compliance. > >> I've never heard anyone argue that position, don't believe anyone would, >> and certainly don't agree with it. > > [ shrug ... ] Check the Postgres archives, from back around 2000 if > memory serves. > > regards, tom lane Or he could just read this essay from the FSF website: http://www.gnu.org/philosophy/why-not-lgpl.html It basically tries to persuade developers to create GPLed libraries in cases where the library provides services that are not available in proprietary libraries. The idea is to *force* developers to use the GPL if they want to use the library. Here's a relevant quote that actually uses readline as an example: However, when a library provides a significant unique capability, like GNU Readline, that's a horse of a different color. The Readline library implements input editing and history for interactive programs, and that's a facility not generally available elsewhere. Releasing it under the GPL and limiting its use to free programs gives our community a real boost. At least one application program is free software today specifically because that was necessary for using Readline. If we amass a collection of powerful GPL-covered libraries that have no parallel available to proprietary software, they will provide a range of useful modules to serve as building blocks in new free programs. This will be a significant advantage for further free software development, and some projects will decide to make software free in order to use these libraries. University projects can easily be influenced; nowadays, as companies begin to consider making software free, even some commercial projects can be influenced in this way. IANAL, but it is hard to recommend relying on a reading of the GPL that is inconsistent with the folks that wrote the license. Jason -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: new set of psql patches for loading (saving) data from (to) text, binary files
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, failed Pavel, gstore/gbstore: The functionality worked as expected - one row, one column results of queries can be sent to a file or shell. It would be nice if a test case was included that proves results more than one row, one column wide will fail. The documentation included is awkward to read. How about: "Sends the current query input buffer to the server and stores the result to an output file specified in the query or pipes the output to a shell command. The file or command are written to only if the query successfully returns exactly one, non-null row and column. If the query fails or does not return data, an error is raised. " Parameterized Queries: The functionality proposed works as expected. Throughout the documentation, code and test cases the word "Parameterized" is spelled incorrectly: "PARAMETRIZED_QUERIES" set_from_file/set_from_bfile: The functionality proposed worked fine, I was able to set variables in sql from files. Minor typo in the documentation: "The content is escapeaed as bytea value." Hope this helps! Jason O'Donnell Crunchy Data The new status of this patch is: Waiting on Author -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PROPOSAL] timestamp informations to pg_stat_statements
Hi guys, Thank you for feedbacks. > I think that this is the job of a tool that aggregates things from > pg_stat_statements. It's unfortunate that there isn't a good > third-party tool that does that, but there is nothing that prevents > it. Right. We can do this if we aggregate it frequently enough. However, third-parties can do it better if we have more informations. I think these are fundamental informations to strong third-parties could be. > The concern I've got about this proposal is that the results get very > questionable as soon as we start dropping statement entries for lack > of space. last_executed would be okay, perhaps, but first_executed > not so much. If we set pg_stat_statements.max to large enough, there could be long lived entries and short lived ones simultaneously. In this case, per call statistics could be accurate but per seconds stats can not. The idea of I named it as created and last_updated (not first_executed and last_executed) was this. It represents timestamp of stats are created and updated, so we can calculate per second stats with simple math. > Also, for what it's worth, I should point out to Jun that > GetCurrentTimestamp() should definitely not be called when a spinlock > is held like that. I moved it outside of spinlock. @@ -1204,6 +1209,11 @@ pgss_store(const char *query, uint32 queryId, */ volatile pgssEntry *e = (volatile pgssEntry *) entry; + /* +* Read a timestamp before grab the spinlock +*/ + TimestampTz last_updated = GetCurrentTimestamp(); + SpinLockAcquire(&e->mutex); /* "Unstick" entry if it was previously sticky */ @@ -1251,6 +1261,7 @@ pgss_store(const char *query, uint32 queryId, e->counters.blk_read_time += INSTR_TIME_GET_MILLISEC(bufusage->blk_read_time); e->counters.blk_write_time += INSTR_TIME_GET_MILLISEC(bufusage->blk_write_time); e->counters.usage += USAGE_EXEC(total_time); + e->counters.last_updated = last_updated; SpinLockRelease(&e->mutex); } pg_stat_statements_with_timestamp_v2.patch <http://postgresql.nabble.com/file/n5912461/pg_stat_statements_with_timestamp_v2.patch> Regards, Jason Kim. -- View this message in context: http://postgresql.nabble.com/PROPOSAL-timestamp-informations-to-pg-stat-statements-tp5912306p5912461.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 2D partitioning of VLDB - sane or not?
I am building up a schema for storing a bunch of data about proteins, which
on a certain level can be modelled with quite simple tables. The problem is
that the database I am building needs to house lots of it >10TB and growing,
with one table in particular threatening to top 1TB. In the case of the
table and in the case of the overall database, the size can be expected to
grow quickly (and most of it can never be deleted).
In the past, with smaller tables, I have had success partitioning on a
64-bit crc hash that takes a more or less uniform distribution of input data
and pumps out a more-or-less uniform distribution of partitioned data with a
very small probability of collision. The hash itself is implemented as a c
add-on library, returns a BIGINT and serves as a candidate key for what for
our purposes we can call a protein record.
Now back to the big table, which relates two of these records (in a
theoretically symmetric way). Assuming I set the the table up as something
like:
CREATE TABLE big_protein_relation_partition_dimA_dimB{
protein_id_a BIGINTEGER NOT NULL CHECK( bin_num(protein_id_a) = dimA ), ---
key (hash) from some table
protein_id_a BIGINTEGER NOT NULL CHECK( bin_num(protein_id_b) = dimB ), ---
key (hash) from some table
...
}
and do a little c bit-twiddling and define some binning mechanism on the
BIGINTEGERs.
As near I can tell, binning out along the A and B dimensions into 256 bins,
I shouldn't be in any danger of running out of OIDs or anything like that
(despite having to deal with 2^16 tables). Theoretically, at least, I should
be able to do UNIONS along each axis (to avoid causing the analyzer too much
overhead) and use range exclusion to make my queries zip along with proper
indexing.
Aside from running into a known bug with "too many triggers" when creating
gratuitous indices on these tables, I feel as it may be possible to do what
I want without breaking everything. But then again, am I taking too many
liberties with technology that maybe didn't have use cases like this one in
mind?
Jason
--
====
Jason Nerothin
Programmer/Analyst IV - Database Administration
UCLA-DOE Institute for Genomics & Proteomics
Howard Hughes Medical Institute
611 C.E. Young Drive East | Tel: (310) 206-3907
105 Boyer Hall, Box 951570 | Fax: (310) 206-3914
Los Angeles, CA 90095. USA | Mail: [EMAIL PROTECTED]
====
http://www.mbi.ucla.edu/~jason
Re: [HACKERS] 2D partitioning of VLDB - sane or not?
Josh, I think what you are suggesting is something like this: -- begin SQL -- core=# CREATE TABLE temp_x( x_id BIGINT PRIMARY KEY, x_info VARCHAR(16) NOT NULL DEFAULT 'x_info'); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "temp_x_pkey" for table "temp_x" CREATE TABLE core=# CREATE TABLE temp_y( y_id BIGINT PRIMARY KEY, y_info VARCHAR(16) NOT NULL DEFAULT 'y_info'); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "temp_y_pkey" for table "temp_y" CREATE TABLE core=# CREATE TABLE temp_xy() INHERITS (temp_x, temp_y); CREATE TABLE core=# \d temp_xy Table "core.temp_xy" Column | Type | Modifiers +---+-- x_id | bigint| not null x_info | character varying(16) | not null default 'x_info'::character varying y_id | bigint| not null y_info | character varying(16) | not null default 'y_info'::character varying Inherits: temp_x, temp_y -- end code -- The problem with this is what I really want to do is something like this: -- begin code -- core=# CREATE TABLE temp_xx() INHERITS (temp_x, temp_x); ERROR: inherited relation "temp_x" duplicated -- end code -- The issue is that the relations are in fact reflexive and, due to the sheer size fo the data I'm trying to warehouse, I'd like not to keep them around more than once. I'm sort of thinking aloud here, but based on what you've told me, I guess I'm left having to choose which direction I want to search in since the domains and ranges are theoretically the same. On the other hand, perhaps I could take the overhead impact and just keep two copies of the parent tables around. The relation table is on the order of about 300-500x as large as the parent tables and that multiplier is expected to stay relatively constant over time...? Which brings us back to the original issue. If I decide to stick with the current implementation and not "improve our existing partitioning mechanisms to scale to 100,000 partitions", I could do something like: Maintain 2 copies of the parent table (partitioned by 256). Inherit from both to a relation table. Does this get me out of the woods with the query analyzer? Doesn't seem like it would, necessarily, at least. On 8/11/07, Josh Berkus <[EMAIL PROTECTED]> wrote: > > Jason, > > > Aside from running into a known bug with "too many triggers" when > creating > > gratuitous indices on these tables, I feel as it may be possible to do > what > > I want without breaking everything. But then again, am I taking too many > > liberties with technology that maybe didn't have use cases like this one > in > > mind? > > Well, you're pushing PostgreSQL partitioning further than it's currently > able > to go. Right now our range exclusion becomes too costly to be useful > somewhere around 300 to 1000 partitions (depending on CPU and other > issues) > because the constraints are checked linearly. > > To make your scheme work, you'd need to improve our existing partitioning > mechanisms to scale to 100,000 partitions. It would also help you to > implement multiple inheritance so that you could have a partition which > belonged to two masters. I'd be very interested in seeing you do so, of > course, but this may be more hacking than you had in mind. > > -- > Josh Berkus > PostgreSQL @ Sun > San Francisco > -- Jason Nerothin Programmer/Analyst IV - Database Administration UCLA-DOE Institute for Genomics & Proteomics Howard Hughes Medical Institute ==== 611 C.E. Young Drive East | Tel: (310) 206-3907 105 Boyer Hall, Box 951570 | Fax: (310) 206-3914 Los Angeles, CA 90095. USA | Mail: [EMAIL PROTECTED] http://www.mbi.ucla.edu/~jason
Re: [HACKERS] PostgreSQL mission statement?
Scott Marlowe <[EMAIL PROTECTED]> writes: > On Wed, 1 May 2002, David Terrell wrote: > > > On Wed, May 01, 2002 at 02:24:30PM -0400, mlw wrote: > > > Just out of curiosity, does PostgreSQL have a mission statement? > > > > > > If so, where could I find it? > > > > > > If not, does anyone see a need? > > > > "Provide a really good database and have fun doing it" > > Motto: "The best damned database money can't buy" I don't think that any of the PostgreSQL developers would want, in any way shape or form, to suggest that you can't pay money for PostgreSQL. Nor are they likely to limit themselves to competing with free (libre/gratis) databases. Some of them might even object to the use of the word "damn" :). Jason ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL mission statement?
Mark kirkwood <[EMAIL PROTECTED]> writes: > On Fri, 2002-05-03 at 04:25, mlw wrote: > > > > > IMHO, if we can come up with a strong, positive statement, it > > would help MBA trained CIOs and CTOs choose PostgreSQL. To them, > > it will show a professional minded development group, it will be > > recognizable to them. > > I am not so sure about that - > > In my experience the things that those guys use to decide on > products are : > > 1) reference sites > 2) official support > > (and they like to pay for a product 'cause they are used to doing > it...but lets not go there...) > > Personally I find the lack of "business-speak" things (like mission > statements) refeshing, and I see it as part of the "values" that > differentiate open source / community based products from commercial > ones. > > just my NZ4c (=US2c) > > Mark As a developer and systems administrator my favorite thing about PostgreSQL is the fact that I can get the straight dope on what works and what doesn't. The PostgreSQL developers are quite candid, and are more than willing to tell you which bits of PostgreSQL are dicey. That's a huge bonus to someone creating and maintaining an application. However, it's not exactly the sort of salesmanship that my boss is looking for. Jason ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] FW: Cygwin PostgreSQL Information and Suggestions
Joel, On Fri, May 10, 2002 at 12:43:16PM -0400, Joel Burton wrote: > > > Sorry, but since I install all Cygwin packages plus about 30 > > > additional ones I haven't desire to determine what are the > > > minimal requirements. > > If no one else has done this, I'll be happy to dig in and answer this. Saravanan Bellan has provided a file list, but not a package list. Would you be willing to do the conversion? See the following: http://archives.postgresql.org/pgsql-cygwin/2002-05/msg00030.php > > http://www.tishler.net/jason/software/postgresql/postgresql-7.2.1.README > This is a great document. I had missed this before. I'm glad that you found the above useful. > Thanks for the info, and thanks for your work on the PG + cygwin stuff! You are very welcome. BTW, I'm on pgsql-hackers now -- YAML, sigh... If you want to get my attention, just make sure "cygwin" is in the subject and procmail will do its magic. :,) Jason ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Native Win32, How about this?
mlw, On Fri, May 10, 2002 at 05:25:02PM -0400, mlw wrote: > A binary version of PostgreSQL for Windows should not use the cygwin > dll. I know and understand there is some disagreement with this position, > but in this I'm sure about this. Sorry, but I'm not going to touch the above -- even with a ten foot pole. Or, at least try not to... :,) > I believe we can use the cygwin development environment, and direct gcc > not to link with the cygwin dll. Last time I looked it was a command line > option. This will produce a native windows application. No emulation, > just a standard C runtime. Yes, the above mentioned option is "-mno-cygwin". > Some of the hits will be file path manipulation, '/' vs '\', the notion of > drive letters, and case insensitivity in file names. Case insensitivity is typically "enabled" regardless. Unless you are referring to CYGWIN=check_case:strict, but almost no one uses this setting. Just to be explicit, another hit will be the loss of Posix. > [snip] > > I think a huge time savings can be had by avoiding rewriting everything > for the Microsoft build environment. Yes, you should use Cygwin and gcc -mno-cygwin or MSYS and Mingw. > As far as I know, and please correct me if I'm wrong, code produced by > the cygwin gcc is freely distributable and need not be GPL. The above is true only with gcc -mno-cygwin or Mingw code. Any code produced by the normal Cygwin gcc (and hence, linked against cygwin1.dll) is effectively GPL'd or at least required to be open source. > [snip] Jason ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
Bruce, On Sun, Jun 02, 2002 at 08:49:21PM -0400, Bruce Momjian wrote: > mlw wrote: > > Like I told Marc, I don't care. You spec out what you want and I'll write it > > for Windows. > > > > That being said, a SysV IPC interface for native Windows would be kind of > > cool to have. > > I am wondering why we don't just use the Cygwin shm/sem code in our > project, or maybe the Apache stuff; why bother reinventing the wheel. Are you referring to cygipc above? If so, they even one of the original cygipc authors would discourage this: http://sources.redhat.com/ml/cygwin-apps/2001-09/msg00017.html Specifically, Ludovic Lange states the following: > I really think the solution would be to start again from scratch > another implementation, as was suggested. The way we did it was > quick and dirty, the goals weren't to have production systems > running on it but only to run prototypes. So the internal design > (if there is any) may not be adequate for the cygwin project. However, Rob Collins has contributed a MinGW daemon to Cygwin to support switching users, System V IPC, etc. So, this code base may be a more suitable starting point to satisfy PostgreSQL's native Win32 System V IPC needs. Jason ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
On Sun, Jun 02, 2002 at 09:33:57PM -0400, mlw wrote: > Bruce Momjian wrote: > > mlw wrote: > > > Like I told Marc, I don't care. You spec out what you want and I'll write > > > it for Windows. > > > > > > That being said, a SysV IPC interface for native Windows would be kind of > > > cool to have. > > > > I am wondering why we don't just use the Cygwin shm/sem code in our > > project, or maybe the Apache stuff; why bother reinventing the wheel. > > but! in the course of testing some code, I managed to gain some experience > with cygwin. I have seen fork() problems with a large number of processes. Since Cygwin's fork() is implemented with WaitForMultipleObjects(), it has a limitation of only 63 children per parent. Also, there can be DLL base address conflicts (causing Cygwin fork() to fail) that are avoidable by rebasing the appropriate DLLs. AFAICT, Cygwin PostgreSQL is currently *not* affected by this issue where as other Cygwin applications such as Python and Apache are. Jason ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
On Mon, Jun 03, 2002 at 09:36:51AM -0400, mlw wrote: > Jason Tishler wrote: > > > > On Sun, Jun 02, 2002 at 09:33:57PM -0400, mlw wrote: > > > Bruce Momjian wrote: > > > > mlw wrote: > > > > > Like I told Marc, I don't care. You spec out what you want and I'll > > > > > write it for Windows. > > > > > > > > > > That being said, a SysV IPC interface for native Windows would be > > > > > kind of cool to have. > > > > > > > > I am wondering why we don't just use the Cygwin shm/sem code in our > > > > project, or maybe the Apache stuff; why bother reinventing the wheel. > > > > > > but! in the course of testing some code, I managed to gain some experience > > > with cygwin. I have seen fork() problems with a large number of processes. > > > > Since Cygwin's fork() is implemented with WaitForMultipleObjects(), > > it has a limitation of only 63 children per parent. Also, there can > > be DLL base address conflicts (causing Cygwin fork() to fail) that are > > avoidable by rebasing the appropriate DLLs. AFAICT, Cygwin PostgreSQL is > > currently *not* affected by this issue where as other Cygwin applications > > such as Python and Apache are. > > Why would not PostgreSQL be affected by this? Sorry, if I was unclear -- I should have used two paragraphs above and maybe a few more words... :,) Cygwin PostgreSQL *is* affected by the Cygwin 63 children per parent fork limitation. PostgreSQL *can* be affected by the Cygwin DLL base address conflict fork issue, but in my experience (both personal and by monitoring the Cygwin and pgsql-cygwin lists), no one has been affected yet. The DLL base address conflict is a "probability" thing. The more DLLs loaded the greater the chance of a conflict (and fork() failing). Since, Cygwin PostgreSQL loads only a few DLLs, this has not become an issue (yet). Jason ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Roadmap for a Win32 port
Dan, The following is to help keep the archives accurate and should not be construed as an argument against the native Win32 port. On Tue, Jun 04, 2002 at 10:02:14PM -0700, Dann Corbit wrote: > And Cygwin requires a license for commercial use. > http://cygwin.com/licensing.html The above is not necessarily true: Red Hat sells a special Cygwin License for customers who are unable to provide their application in open source code form. Note that the above only comes into play if your application links with the Cygwin DLL. This is easily avoidable by using JDBC, ODBC, Win32 libpq, etc. Hence, most people will not be required to purchase this license from Red Hat. Jason ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [CYGWIN] 7.3 Beta 1 Build Error on Cygwin
Dave, On Thu, Sep 05, 2002 at 12:54:50PM +0100, Dave Page wrote: > I get the following error when building beta 1 on CYGWIN_NT-5.1 PC9 > 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown: > > make[3]: Entering directory >`/usr/local/src/postgresql-7.3b1/src/backend/utils/mb/conversion_procs/cyrillic_and_mic' > gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations >-I../../../../../../src/include -I/usr/local/include -DBUILDING_DLL=1 -c -o >cyrillic_and_mic.o cyrillic_and_mic.c > [snip] > dllwrap -o cyrillic_and_mic.dll --dllname cyrillic_and_mic.dll --def >cyrillic_and_mic.def cyrillic_and_mic.o ../../../../../../src/utils/dllinit.o >-lcygipc -lcrypt -L/usr/local/lib -L../../../../../../src/backend -lpostgres > Warning: resolving _CurrentMemoryContext by linking to __imp__CurrentMemoryContext >(auto-import) > [snip] > nmth00.o(.idata$4+0x0): undefined reference to `_nm__CurrentMemoryContext' I just submitted a patch to pgsql-patches to fix the above and to add a couple of missing DLLIMPORTs to src/include/miscadmin.h. FYI, plperl no longer builds cleanly against Cygwin Perl 5.6.1 because PostgreSQL no longer uses the Perl extension infrastructure. However, upgrading Cygwin Perl to 5.8.0 solves the problem because this version uses the conventional name for libperl.a instead of one that has the version embedded in it. Thanks again for the heads up. Jason ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.3 Beta 1 Build Error on Cygwin
Peter, On Thu, Sep 05, 2002 at 08:33:20PM +0200, Peter Eisentraut wrote: > Dave Page writes: > > > I get the following error when building beta 1 on CYGWIN_NT-5.1 PC9 > > 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown: > > Should all be fixed now. Huh? I don't see any recent CVS commits to indicate this. Jason ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3 Beta 1 Build Error on Cygwin
Peter, On Thu, Sep 05, 2002 at 02:51:31PM -0400, Bruce Momjian wrote: > Jason Tishler wrote: > > On Thu, Sep 05, 2002 at 08:33:20PM +0200, Peter Eisentraut wrote: > > > Should all be fixed now. > > > > Huh? I don't see any recent CVS commits to indicate this. > > I see as a commit: > > [snip] > > I assume it was in there. Sorry for the noise, but at the time: cvs status include/miscadmin.h makefiles/Makefile.win did *not* indicate any recent commits. Maybe you sent the above email before you committed your changes? Anyway, I just tried a: make distclean rm include/miscadmin.h makefiles/Makefile.win # remove my patch cvs update make and got the following error: [snip] make[3]: Leaving directory `/home/jt/src/pgsql/src/backend/utils' dlltool --dllname postgres.exe --output-exp postgres.exp --def postgres.def gcc -L/usr/local/lib -o postgres.exe -Wl,--base-file,postgres.base postgres.exp access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o libpq/SUBSYS.o(.text+0x1c84):crypt.c: undefined reference to `crypt' port/SUBSYS.o(.text+0x262):pg_sema.c: undefined reference to `semget' [snip] I can get postgres.exe to successfully link by manually appending "-lcrypt -lcygipc" to the end of the above gcc command line. Since you are already working on this, would you be willing to fix this problem? Thanks, Jason ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 7.3 Beta 1 Build Error on Cygwin
Peter, On Fri, Sep 06, 2002 at 12:54:13PM +0100, Dave Page wrote: > Seems to build cleanly here now. And here (and now) too. > Perhaps anoncvs just hadn't sync'd up when you tried Jason? I guess so -- very strange... Anyway, sorry (again) for the noise and thanks for fixing the Cygwin build. Jason ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Postgres Windows Native Port
Michael, Please post instead of sending private email. On Fri, Oct 18, 2002 at 12:08:02PM +0200, Michael Steiner wrote: > FAQ says: "A native port to MS Win NT/2000/XP is currently being worked > on." > > => When is it expected to be available as a stable release? I don't know. > Will it be based on cygwin dll's? No. > Will the reliability and performance be comparable to the unix-version? I don't know. > Will it be free for commercial use? I presume so. Maybe others on the CC'd lists can answer your questions better. Jason ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Request for supported platforms
Dave,
Thanks for the heads up...
On Mon, Oct 28, 2002 at 10:31:00AM -, Dave Page wrote:
> > -Original Message-
> > From: Bruce Momjian [mailto:pgman@;candle.pha.pa.us]
> > Sent: 26 October 2002 03:17
> > Subject: [HACKERS] Request for supported platforms
> >
> > Folks. start sending in those plaform reports, OS name and
> > version number please.
>
> CYGWIN_NT-5.1 PC9 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown
^^
Please try with Cygwin 1.3.14-1 while I attempt to deal with at least
the following Cygwin build issues with PostgreSQL CVS as of today at
about 7:00 AM EST:
1. pg_config.h.in HAVE_FSEEKO ifdef:
make[4]: Entering directory `/home/jt/src/pgsql/src/backend/access/common'
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include
-DBUILDING_DLL -c -o heaptuple.o heaptuple.c
In file included from ../../../../src/include/c.h:56,
from ../../../../src/include/postgres.h:48,
from heaptuple.c:21:
/usr/include/stdio.h:207: parse error before `('
2. Cygwin bison limit exceeded:
make[4]: Entering directory `/home/jt/src/pgsql/src/interfaces/ecpg/preproc'
[snip]
bison -y -d preproc.y
preproc.y:5560: fatal error: maximum table size (32767) exceeded
> Make check failed with the normal spurious errors.
I would stick with make installcheck due to the Cygwin (i.e., Windows)
backlog issue.
> Make installcheck also failed on horology, copy2 and domain - see
> attached output.
>
> The clocks changed here on Saturday night, so I guess that shouldn't
> have caused the first error (or should the docs be updated?).
>
> The second 2 errors are both with copys - related to the problem with
> the listen() backlog queue in the parallel test perhaps?
I haven't looked into the above yet due to the build problems. Any help
regarding these issues is gratefully appreciated.
Thanks,
Jason
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Request for supported platforms
Dave, On Mon, Oct 28, 2002 at 02:56:01PM -, Dave Page wrote: > > -Original Message- > > From: Jason Tishler [mailto:jason@;tishler.net] > > Sent: 28 October 2002 13:33 > > Subject: Re: [HACKERS] Request for supported platforms > > > > Please try with Cygwin 1.3.14-1 while I attempt to deal with at > > least the following Cygwin build issues with PostgreSQL CVS as of > > today at about 7:00 AM EST: > > Ok, but this is going to take a while as few of the mirrors seem to > have this release yet. I also need to download a new set of everything > for reasons I won't go into. My WAG is that you will be able to upgrade your Cygwin installation before I fix the Cygwin build issues. :,) > Is there actually a reason for this though or are you just trying to > keep me busy? :-) It can't be a good thing for us to require that > people upgrade to the latest release of their OS. Agreed, but sometimes a new Cygwin release fixes some problems and breaks others... > > 2. Cygwin bison limit exceeded: > > > > make[4]: Entering directory > > `/home/jt/src/pgsql/src/interfaces/ecpg/preproc' > > [snip] > > bison -y -d preproc.y > > preproc.y:5560: fatal error: maximum table size (32767) exceeded > > I believe a new bison is required now. Don't know much about it other > than ecpg hit some limit or other and much discussion followed. Iirc, > it's only an issue when compiling from CVS, not a tarball. The above should help save me some time. Thanks, Jason ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Request for supported platforms
Dave, On Mon, Oct 28, 2002 at 11:20:16AM -0500, Jason Tishler wrote: > On Mon, Oct 28, 2002 at 02:56:01PM -, Dave Page wrote: > > Ok, but this is going to take a while as few of the mirrors seem to > > have this release yet. I also need to download a new set of everything > > for reasons I won't go into. > > My WAG is that you will be able to upgrade your Cygwin installation > before I fix the Cygwin build issues. :,) I guess my WAG was wrong... :,) Under the following platform: $ uname -a CYGWIN_NT-5.0 TISHLERJASON 1.3.14(0.62/3/2) 2002-10-23 14:47 i686 unknown all make installcheck tests pass except for horology. However, the horology failure is to be expected due to the recent time change. Unfortunately, there are some Cygwin build issues that I need to address: 1. Cygwin bison needs to be upgraded from 1.35 to 1.75 (i.e., 1.50+) to process src/interfaces/ecpg/preproc/preproc.y successfully. I will post to the Cygwin mailing list asking the maintainer for this upgrade. 2. The following fseeko/ftello ifdef in src/include/pg_config.h.in: #ifndef HAVE_FSEEKO #define fseeko(a, b, c) fseek((a), (b), (c)) #define ftello(a) ftell((a)) #endif conflicts with the following Cygwin /usr/include/stdio.h entries: int _EXFUN(fseeko, (FILE *, off_t, int)); off_t _EXFUN(ftello, ( FILE *)); Unfortunately, I'm not sure what is the best way to solve this one yet. Any suggestions would be appreciated. Thanks, Jason ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Request for supported platforms
Dave, On Mon, Oct 28, 2002 at 08:58:12PM -, Dave Page wrote: > > -Original Message- > > From: Jason Tishler [mailto:jason@;tishler.net] > > Sent: 28 October 2002 20:42 > > Subject: Re: [HACKERS] Request for supported platforms > > > > On Mon, Oct 28, 2002 at 11:20:16AM -0500, Jason Tishler wrote: > > > My WAG is that you will be able to upgrade your Cygwin > > > installation before I fix the Cygwin build issues. :,) > > > > I guess my WAG was wrong... :,) > > I've been meaning to ask this for a while - what exactly is a WAG? :-) Larry was kind enough to answer this one for me. :,) > > 1. Cygwin bison needs to be upgraded from 1.35 to 1.75 (i.e., > > 1.50+) to process src/interfaces/ecpg/preproc/preproc.y > > successfully. I will post to the Cygwin mailing list asking > > the maintainer for this upgrade. > > OK. This shouldn't stop a release though I assume, only a build from > CVS. Yes. Nevertheless, I have posted my request: http://cygwin.com/ml/cygwin/2002-10/msg01740.html > > 2. The following fseeko/ftello ifdef in src/include/pg_config.h.in: > > > > #ifndef HAVE_FSEEKO > > #define fseeko(a, b, c) fseek((a), (b), (c)) > > #define ftello(a) ftell((a)) > > #endif > > > > conflicts with the following Cygwin /usr/include/stdio.h entries: > > > > int _EXFUN(fseeko, (FILE *, off_t, int)); > > off_t _EXFUN(ftello, ( FILE *)); > > > > Unfortunately, I'm not sure what is the best way to solve > > this one yet. Any suggestions would be appreciated. I found a solution to the above which will hopefully find its way into the next Cygwin release: http://cygwin.com/ml/cygwin-patches/2002-q4/msg00042.html > Yes, I'm seeing errors with this on my updated Cygwin very early in > the build. I did think it was my hacked about installation, but I > guess not! A quick and *dirty* fix for this problem is to temporarily delete the above two entries from your stdio.h file. Jason ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Request for supported platforms
Matthew, On Mon, Oct 28, 2002 at 10:50:40PM -0500, Matthew T. O'Connor wrote: > Are you compiling from CVS or from a released tarball? CVS. > The bison requirement was recently raised to bison 1.5 or above (1.75 > was recently released also.) This is an issue only when compiling > from CVS, since the bison stuff is preprocessed for released tarballs. > So you might want to try the just release beta3. Thanks for the above, but see my recent, related posts (if interested). Jason ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Request for supported platforms
Dave, On Tue, Oct 29, 2002 at 04:57:58PM -, Dave Page wrote: > All regression tests pass with the above hack on: > > CYGWIN_NT-5.1 PC9 1.3.14(0.62/3/2) 2002-10-24 10:48 i686 unknown Thanks for the above. > Hackers: As the Cygwin release that is actively supported is the > binary distribution that Jason builds, I would think this is OK to be > listed as supported if no-one disagrees... Umm... Should I disagree? :,) Jason ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Request for supported platforms
Dave, On Tue, Oct 29, 2002 at 09:00:20PM -, Dave Page wrote: > > -Original Message- > > From: Jason Tishler [mailto:jason@;tishler.net] > > Sent: 29 October 2002 18:58 > > > > > Hackers: As the Cygwin release that is actively supported is the > > > binary distribution that Jason builds, I would think this is OK to > > > be listed as supported if no-one disagrees... ^ * > > Umm... Should I disagree? :,) > > Entirely up to you - you do the build :-). I was meekly trying to voice my concern about who supplies the "support" mentioned above. > I'm just pointing out that the line wrt to Cygwin is generally "use > the standard package", so if we stick to that, as long as you build it > OK, most people needn't worry 'bout hacking stdio.h. If my patch gets accepted, then the stdio.h hack won't be necessary for anyone (after the next Cygwin release). Jason ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [CYGWIN] ipc-daemon
Tom, Peter, On Mon, Nov 04, 2002 at 02:43:01PM -0500, Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > To me, this is a bug in PostgreSQL. > > I disagree: just because cygipc returns error codes chosen at random > doesn't mean that we should neglect the clear meaning of an error > code. If a normal Unix system were to return EACCES here, the clear > implication would be that there is an existing segment that we do not > have permission to access. I don't see how "cygipc isn't running" can > reasonably be translated into "permission denied". > > [snip] > > > My first thought was ENOSYS (system call not implemented -- what BSD > > kernels tend to return if you didn't compile them with SysV IPC > > support), but that isn't a clearly superior choice either. > > If you can detect that cygipc is not running, then ENOSYS seems the > best choice for reporting that. (ENOSPC would be misleading too.) > > If it's impractical to fix cygipc then I'd grudgingly go along with > > if (errno == EEXIST > #ifndef __CYWGIN__ /* cygipc is broken */ > || errno == EACCES > #endif > #ifdef EIDRM > || errno == EIDRM > #endif > ) > return NULL; Thanks for your feedback. I will take this to the Cygwin list and see what happens. Unfortunately, the cygipc maintainer is "AWOL" right now because of Ph.D. thesis commitments. Hence, even if I can get the Cygwin community to agree to this change, there may not be an official cygipc release for a while. Thanks, Jason -- GPG key available on key servers or http://www.tishler.net/jason/gpg.txt msg24667/pgp0.pgp Description: PGP signature
Re: [CYGWIN] [HACKERS] Request for supported platforms
Peter, On Wed, Oct 30, 2002 at 07:36:40PM +0100, Peter Eisentraut wrote: > Dave Page writes: > > Hackers: As the Cygwin release that is actively supported is the > > binary distribution that Jason builds, I would think this is OK to > > be listed as supported if no-one disagrees... > > I disagree. We document as supported those platforms that build out > of the box, not those that build somehow, somewhere, by someone. > > Rather than advocating methods to manually edit your system headers we > should try to find out what the problem really is, such as by > analyzing config.log. Did you miss the following? http://archives.postgresql.org/pgsql-hackers/2002-10/msg01303.php As you can see, I have already performed root cause analysis of theses problems *and* have taken the proper steps to ensure that PostgreSQL builds OOTB under Cygwin (after the next Cygwin release). Jason ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [CYGWIN] [HACKERS] Request for supported platforms
This post is just for closure -- both of the issues below have been resolved: On Tue, Oct 29, 2002 at 09:47:35AM -0500, Jason Tishler wrote: > > > 1. Cygwin bison needs to be upgraded from 1.35 to 1.75 (i.e., > > > 1.50+) to process src/interfaces/ecpg/preproc/preproc.y > > > successfully. I will post to the Cygwin mailing list asking the > > > maintainer for this upgrade. > > > > OK. This shouldn't stop a release though I assume, only a build from > > CVS. > > Yes. Nevertheless, I have posted my request: > > http://cygwin.com/ml/cygwin/2002-10/msg01740.html http://cygwin.com/ml/cygwin-announce/2002-10/msg00016.html > > > 2. The following fseeko/ftello ifdef in src/include/pg_config.h.in: > > > > > > #ifndef HAVE_FSEEKO > > > #define fseeko(a, b, c) fseek((a), (b), (c)) > > > #define ftello(a) ftell((a)) > > > #endif > > > > > > conflicts with the following Cygwin /usr/include/stdio.h entries: > > > > > > int _EXFUN(fseeko, (FILE *, off_t, int)); > > > off_t _EXFUN(ftello, ( FILE *)); > > > > > > Unfortunately, I'm not sure what is the best way to solve this one > > > yet. Any suggestions would be appreciated. > > I found a solution to the above which will hopefully find its way into > the next Cygwin release: > > http://cygwin.com/ml/cygwin-patches/2002-q4/msg00042.html http://cygwin.com/ml/cygwin-patches/2002-q4/msg00089.html Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [CYGWIN] ipc-daemon
Tom,
Peter,
On Mon, Nov 04, 2002 at 03:05:25PM -0500, Jason Tishler wrote:
> On Mon, Nov 04, 2002 at 02:43:01PM -0500, Tom Lane wrote:
> > If you can detect that cygipc is not running, then ENOSYS seems the
> > best choice for reporting that. (ENOSPC would be misleading too.)
>
> Thanks for your feedback. I will take this to the Cygwin list and see
> what happens.
I happy to report that the above has been accomplished:
http://cygwin.com/ml/cygwin-announce/2002-11/msg00025.html
Hopefully, the Cygwin initdb and postmaster hang posts will be a thing
of the past. Unfortunately, they probably will be replaced by questions
like:
Why does initdb fail with "IpcMemoryCreate: shmget(...) failed:
Function not implemented?"
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [CYGWIN] ipc-daemon
Richard, On Sat, Nov 16, 2002 at 02:27:22PM -0800, Richard Pais wrote: > Just an explanation in the FAQ that the ipc-daemon is not running > won't suffice. Because in my case I had ipc-daemon (version 1.11) > running and it still hung (Jason's patch reported the IpcMemoryCreate > error). Only when I downgraded to version 1.09 (office) and upgraded > to 1.13 (home) did initdb succeed. So I'd suggest also covering this > scenario. If you feel strongly about the above, then submit a patch to pgsql-patches@ for consideration. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [CYGWIN] ipc-daemon
Bruce, On Mon, Nov 18, 2002 at 10:42:30AM -0500, Bruce Momjian wrote: > To get into the FAQ, it should be something that happens _frequently_, > hence FAQ. Understood. That is why is said "for consideration." > Fact is, cygwin may not even be needed in 7.4 because we are > working on a native port. A Win32 native port in the 7.4 time frame is great news! However, I hope that the Cygwin port will not be deprecated. There are compelling reasons to still have a Cygwin PostgreSQL port just like there is with Python, Perl, Vim, Emacs, etc. On the other hand, I wouldn't mind being put out of the Cygwin PostgreSQL support business... :,) Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Robert Treat writes: > > > I think we've already shown why it doesn't hurt to market to the > > converted. I'll add that if you compare the 7.2 press release with the > > 7.3 press release, you'll see none of the technical content was removed. > > Compare the 7.3 release notes, written for the most part by Bruce > Momjian and revised by a couple of other developers, to the "press > release", written by people who were obviously ill-informed. So does this mean that you are volunteering to proofread the next marketing announcement? I would wager that only a PostgreSQL developer (such as yourself) could have picked out the inconsistencies that you were able to find. The press release might have seemed "obviously ill-informed" to you, but it seemed just fine to me, and I can guarantee you that I am at least an order of magnitude more informed about PostgreSQL than the average manager. The difference between the press release and the Release Notes is the intended audience. The folks that the press release is aimed at probably don't have any idea that SQL 92 is obsolete, or that internationalization has been supported for years. Chances are good that they will skim over the new features entirely. What *is* important to these people, however, are the customer testimonials at the beginning of the press release and the list of happy customers at the end. Once management has read the press release they can ask their developers to read the Release Notes. Press releases don't supercede Release Notes, they complement them. The difference between the 7.3 Release Notes and the press release is that I could give the press release to my boss. PostgreSQL desperately needs marketing help. In fact, at this point I would say that PostgreSQL needs more marketing help than it needs development work. Technically PostgreSQL is clearly a winner, but despite its myriad features and impressive performance PostgreSQL is still not being deployed nearly as much as it *should* be. The team that has been assembled to market PostgreSQL has some fairly impressive credentials. They are certainly *much* better than what you would expect considering how much they are getting paid :). In short, if you want to help the folks writing the press releases, then that's fine and dandy. But if all you want to do is throw rocks at the people doing the marketing, then that's another story altogether. Jason Earl ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Changing the default configuration (was Re: [pgsql-advocacy]
>Nutshell: > "Easy to install but is horribly slow." > > or > > "Took a couple of minutes to configure and it rocks!" Since when is it easy to install on win32? The easiest way I know of is through Cygwin, then you have to worry about installing the IPC service (an getting the right version too!) I've installed versions 6.1 to 7.1, but I almost gave up on the windows install. At least in 6.x you had very comprehensive installation guide with a TOC. Versus the competition which are you going to choose if you're a wanna-be DBA? The one with all he hoops to jump through, or the one that comes with a setup.exe? Now I actually am in support of making it more aggressive, but it should wait until we too have a setup.exe for the native windows port. (Changing it on *n*x platforms is of little benefit because most benchmarks seem to run it on w32 anyway :-( ) Just my $.02. I reserve the right to be wrong. -J ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Toast, Text, blob bytea Huh?
I'm trying my best to convert from MySQL to PgSQL but I cant get a good
clear answer about
certian issures.Mainly TEXT, TOAST,BLOB , BYTEA etc.
It was an easy task in mysql but everything in the archives about , text ,
toast and bytea is just
confusing me with postgresql. I have Bruces's book and I've searched the
archives years back with all the right keywords with not luck.Here is my
situation-->
WHAT I WAS DOING IN MYSQL
Via the web my clients are uploading basic text/data files, sometimes >
than 30MB. In the past ,via CGI I have been parsing the file
into one STL string, using mysql_escape_string to escape it and then using
an INSERT to place the
,\'+"stlstring+"\' ,into a BLOB column.
"dont want to use a temp. file or files in general anywhere. The data will
always be passed via the database and buffers for certian reasons."Thus no
OID's
THIS IS WHAT I CANT SEEM TO FIGURE OUT IN POSTGRESQL
1. I cant get a clear answer on what kind of data type to use for my large
text string? TEXT, ???, ??? or something about TOAST
I have seen in the e-mail archive but cant find any documentaion?
2. I've written my own escape method ,("cant find one for Pgsql") , BUT i
don't know what
to escape and not to escape. So it keeps failing. I cand find any docs. on
what to escape either?
SUMMARY
What is the best datatype to use, for large raw text and/or binary if i
choose?
Once I know this,how Im a supposed to escape my string and get it through
the parser correctly so i can retrieve it correctly?
Thanks for your time.
PS: Using RedHat.
Jason H. Ory
Medprint+
Software Developer
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Toast,bytea, Text -blob all confusing
I'm trying my best to convert from MySQL to PgSQL but I cant get a good
answer about
certian questions. It was an easy task in mysql but all this talk about
, text , toast and bytea is just confusing me.
I cant get a clear picture of any of this,from the book from Bruce, the
e-mail archives. Ive looked all i can,
with every keyword i can think of from years past. Here is my situation.
WHAT I WAS DOING IN MYSQL
Via the web my clients are uploading basic text/data files, sometimes >
than 30MB. In the past ,via CGI I have been parsing the file
into one STL string, using mysql_escape_string to escape it and then using
an INSERT to place the
,\'+"stlstring+"\' ,into a BLOB column.
I dont want to use a temp. file anywhere. The data will always be passed via
the database and buffers for certian reasons.
THIS IS WHAT I CANT SEEM TO FIGURE OUT IN POSTGRESQL
1. I cant get a clear answer on what kind of data type to use for my large
text string? TEXT, ???, ??? or something about TOAST
I have seen in the e-mail archive but cant find any documentaion?
2. I've written my own escape method ,("cant find one for Pgsql") , BUT i
don't know what
to escape and not to escape. So it keeps failing. I cand find any docs. on
what to escape either?
SUMMARY
What datatype do I use? How Im a supposed to escape it and get it though the
parser correctly so i can
retrieve it correctly?
Thnks for your time.
PS: Using RedHat.
Jason H. Ory
Medprint+
Software Developer
(205) 989-4617
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] storing binary data
Reply-To: sender Hi. I was surprised to discover today that postgres's character types don't support zero bytes. That is, Postgres isn't 8-bit clean. Why is that? More to the point, I need to store about 1k bytes per row of varying-length 8-bit binary data. I have a few options: + BLOBs. PostgreSQL BLOBs make me nervous. I worry about the BLOB not being deleted when the corresponding row in the table is deleted. The documentation is vague. + What I really need is a binary *short* object type. I have heard rumors of a legendary "bytea" type that might help me, but it doesn't appear to be documented anywhere, so I hesitate to use it. + I can base64-encode the data and store it in a "text" field. But postgres is a great big data-storage system; surely it can store binary data without resorting to this kind of hack. What should I do? Please help. Thanks! -- Jason Orendorff P.S. I would love to help improve PostgreSQL's documentation. Whom should I contact? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Changing the default configuration
Pardon my ignorance, but there's no way to auto-tune? Ship it with a thread that gathers statistics and periodically re-tunes the database parameters. Of course, be able to turn it off. People that actually take the time to run tune manually will turn it off as to not have the overhead or interruption. Those that don't care about pg_tune shouldn't care about having a thread around retuning. Those that will care will tune manually. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian Sent: Thursday, February 13, 2003 2:22 PM To: Daniel Kalchev Cc: PostgresSQL Hackers Mailing List; [EMAIL PROTECTED] Subject: Re: [pgsql-advocacy] [HACKERS] Changing the default configuration I imagined they could run pgtune anytime after install to update those performance parameters. It gives them a one-stop location to at least do minimal tuning, and as their load changes, they can run it again. --- Daniel Kalchev wrote: > >>>Bruce Momjian said: > [...] > > For example, we can ask them how many rows and tables they will be > > changing, on average, between VACUUM runs. That will allow us set the > > FSM params. We can ask them about using 25% of their RAM for shared > > buffers. If they have other major apps running on the server or have > > small tables, we can make no changes. We can basically ask them > > questions and use that info to set values. > > Bruce, this is an very good idea and such tool would simplify setup for the > me-too type of DBA - we should definitely try to attract them. > > However, how could one possibly answer the above question, if they setup their > database for the first time? > > What is more, these settings are on a per-installation, not per-database - > which means, that if you have several small, but active databases and one > large database the requirements will be very different. > > Nobody likes answering such questions when installing new software. You might > enjoy it the first few times, but then learn the 'answers' and don't even > think what the question is. (we all know the answer :) > > Perhaps indeed a better idea is to have PostgreSQL itself collect usage > statistics, and from time to time print 'suggestions' to the log file (best in > my opinion), or have these available via some query. These suggestions should > best reflect the of course require minimal intervention to the database > system, such as restart etc. > > > Daniel > > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] SQL99 ARRAY support proposal
"scott.marlowe" <[EMAIL PROTECTED]> writes: > On Fri, 14 Mar 2003, Þórhallur Hálfdánarson wrote: > > > -*- Greg Stark <[EMAIL PROTECTED]> [ 2003-03-14 17:43 ]: > > > Do you really think someone looking for a function to break up a string into a > > > list of strings would ever think of looking up "explode" in an index if he > > > hadn't already used PHP or (shudder) VBScript? > > > > If one had gotten used to Lotus Notes, sure. ;> > > To try and get back on track... > > Let me ask you, if you were looking through a list of array functions > and you saw explode and implode, and you had no other experience with a > language that used those keywords, would you, upon seeing them, have some > idea what they did? It's all good Scott. Anyone wanting to use PostgreSQL arrays would undoubtedly open up the corresponding part of the manual that covers array functions. Since there is likely to be less than a page full of function definitions you could probably call the functions foo() and bar() and get away with it (please don't). While I personally think that join_str and split_str are somewhat more descriptive, implode and explode are fine. More importantly, since *you* are the one doing the actual legwork it's your call. IMHO that's one of the benefits of actually submitting code. You write the code, you get to pick the function names. Now, you might have some issues from the rest of the PostgreSQL hackers if you named the functions "marlowe-ify" and "un-marlowe-ify", but anything not completely ridiculous should be fine (and even marlowe-ify would have the advantage of not being a reserved word in any software I can think of off hand). As for the rest of the discussion, poking fun at development languages and tools is an age-old part of computers. PHP has the disadvantage of being both very popular, very new, and primarily a web technology (and of not being Lisp like :) so it draws more than its share of flames. It's all good fun. Jason ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] SQL99 ARRAY support proposal
"scott.marlowe" <[EMAIL PROTECTED]> writes: > On 14 Mar 2003, Jason Earl wrote: > > > It's all good Scott. Anyone wanting to use PostgreSQL arrays > > would undoubtedly open up the corresponding part of the manual > > that covers array functions. Since there is likely to be less > > than a page full of function definitions you could probably call > > the functions foo() and bar() and get away with it (please don't). > > While I personally think that join_str and split_str are somewhat > > more descriptive, implode and explode are fine. > > > > More importantly, since *you* are the one doing the actual legwork > > it's your call. IMHO that's one of the benefits of actually > > submitting code. You write the code, you get to pick the function > > names. Now, you might have some issues from the rest of the > > PostgreSQL hackers if you named the functions "marlowe-ify" and > > "un-marlowe-ify", but anything not completely ridiculous should be > > fine (and even marlowe-ify would have the advantage of not being a > > reserved word in any software I can think of off hand). > > > > As for the rest of the discussion, poking fun at development > > languages and tools is an age-old part of computers. PHP has the > > disadvantage of being both very popular, very new, and primarily a > > web technology (and of not being Lisp like :) so it draws more > > than its share of flames. It's all good fun. > > Actually, I think it was someone else (Joe???) that is doing the leg > work, and he was the one choosing explode / implode and getting > gruff for it, so I was just stepping in and defending his decision. Oops, my bad. My brain must already think that it is the weekend. My reasoning still stands, though. Whoever writes the code gets to pick the names (assuming, of course, that they can get them past the rest of the PostgreSQL hackers). There's parts of PostgreSQL so cool that I would continue to use them even if the function were called jason_earl_is_a_stupid_head(). Heck, the reason that I don't like terms like explode and implode probably stems from the fact that I tend to have error functions with those sorts of dramatic names :). You know "lp0 is on fire" type of stuff. > I do think using a function name with the word join in it meaning > anything other than a SQL join is a recipe for confusion though. Perhaps. We'll have to see what gets submitted. Jason ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Detecting corrupted pages earlier
Andrew Sullivan <[EMAIL PROTECTED]> writes: > On Wed, Apr 02, 2003 at 03:25:58PM -0500, Tom Lane wrote: > > > the current session. This is kind of an ugly wart on the GUC mechanism, > > but I think not difficult to do with an assign_hook (it just has to > > refuse non-interactive settings). > > It may be an ugly wart, but I think it's only prudent. I'd be > willing to bet a fair amount that there is a significant overlap > between the population which uses Bob's Discount Hardware for 10 > million row, ultra-critical databases and the population which likes > to twiddle postgresql.conf settings without reading the fine > manual. Those folks are going to get burned by this setting unless > it is very hard to turn on. (I think the setting is an excellent > idea, though, for emergency cases.) > > I don't usually like making servers totally idiot-proof, but I can > just imagine the Slashdot conversations after 7.4 comes out (and for > at least 60 or 70 years thereafter): "PostgreSQL just randomly zeroes > a page of data! It sucks! Use MySQL instead. It can recover from > bad pages on your disk by randomly making up data for you, instead of > just writing zeros." Perhaps the real answer is to use a more *descriptive* name for the variable than ZERO_DAMAGED_PAGES. Something along the lines of CLUELESS_DBA_ESCHEWS_BACKUPS, or ONLY_AN_IDIOT_SETS_THIS_VARIABLE. You don't have to read the manual to see that these variables are not to be trifled with. There are some cases where this particular feature would be useful. What needs to be done is to make the feature less dangerous to the newbie without making it less useful to the person who actually needs the functionality. Jason ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] sa_family_t in cygwin compile of cvs + regression failure
On Sun, Jun 15, 2003 at 04:54:21PM +0100, deststar wrote: > On cygwin sa_family_t was undeclared, adding the following line: > typedef unsigned short sa_family_t; > to both: > src/port/getaddrinfo.c > src/include/libpq/pqcomm.h Isn't the attached or fixing Cygwin itself a better approach? > seemed to compile ok but with make check there was one regression > failure in test privileges (doesn't look realted, but I'm not sure). I have also observed similar problems when I (used to) use make check myself. This test passes under make installcheck. BTW, because of the above and the following (from the Cygwin PostgreSQL README): 1. make check can generate spurious regression test failures due to overflowing the the listen() backlog queue which generates connection refused errors. Note that make installcheck does not have this problem since it runs all tests sequentially instead of in large concurrent groups. I no longer use make check even though make installcheck is much less convenient. > Also included for ease of testing is a patch sepratly sent to patches > for ecpg. Thanks for the patch! Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 Index: src/include/port/cygwin.h === RCS file: /projects/cvsroot/pgsql-server/src/include/port/cygwin.h,v retrieving revision 1.3 diff -u -p -r1.3 cygwin.h --- src/include/port/cygwin.h 22 May 2003 17:20:28 - 1.3 +++ src/include/port/cygwin.h 16 Jun 2003 17:20:19 - @@ -21,3 +21,5 @@ typedef unsigned char slock_t; #else #define DLLIMPORT __declspec (dllimport) #endif + +typedef unsigned short sa_family_t; ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Two weeks to feature freeze
The Hermit Hacker <[EMAIL PROTECTED]> writes: > On Thu, 19 Jun 2003, Robert Treat wrote: > >> Well, I suppose that history has shown that waiting on specific features >> causes trouble with postgresql development, but I don't see why a >> release can't be based around waiting for feature x as long as feature x >> is being actively worked on by trusted developers who have an endgame in >> sight. > > Everyone has an 'endgame in sight', at least when they ask for a > release to be postponed ... but then their date keeps slipping, etc > ... > > The thing is, if win32 is 'that close to being finished', then as > soon as v7.4 is out, that code should be ready to throw in ... and > the same for every other features that could 'postpone a release' > ... > > I'd rather see the dev cycle shortened by a month, then extended ... Why couldn't you just release the win32 version of 7.4 when it was finished. If it takes an extra month then that just gives you guys the chance to circulate *two* press releases. The Native Win32 port is likely to make a big enough splash all by itself. Jason ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Two weeks to feature freeze
"Dann Corbit" <[EMAIL PROTECTED]> writes: >> >> Why couldn't you just release the win32 version of 7.4 when >> it was finished. If it takes an extra month then that just >> gives you guys the chance to circulate *two* press releases. >> The Native Win32 port is likely to make a big enough splash >> all by itself. > > A formal release needs a big testing effort. Two separate releases > will double the work of validation. There are several problems with that statement. The first is that PostgreSQL's "testing effort" happens right here on this mailing list. The various PostgreSQL hackers code stuff up, and we try and break it. There's very little /effort/ involved. People that want the new features go out on a limb and start using them. If they don't work, then they bring it up on the list. If they do work then very little gets said. As it now stands Tom Lane is on the record as stating that the new Win32 version isn't going to be ready for production anyhow. If anything the Win32 version *should* get released separately simply because we don't want people mistaking the Win32 version as being up to the PostgreSQL teams high standards. Those people that want the Win32 version to become production ready are going to have to risk their precious data. Otherwise, the Win32 version will likely remain a second class citizen forever. The fact of the matter is that the Win32 specific bits are the parts that are likely to break in the new port. If anything the Windows version will *benefit* from an earlier *nix release because the *nix users will chase down the bugs in the new PostgreSQL features. Once the *nix version is up to 7.4.2 (or so) then a Windows release of 7.4.2 should allow the PostgreSQL hackers to simply chase down Windows specific problems. Adding a new platform--especially a platform as diverse from the rest of PostgreSQL's supported platforms as Windows--is what adds the work. Testing the new platform is relatively easy. All you need to do is to start using the Win32 version with real live data. Jason ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
"Dann Corbit" <[EMAIL PROTECTED]> writes: >> -Original Message- >> From: Jason Earl [mailto:[EMAIL PROTECTED] >> Sent: Friday, June 20, 2003 3:32 PM >> To: Dann Corbit >> Cc: Jason Earl; The Hermit Hacker; PostgreSQL-development >> Subject: Re: [HACKERS] Two weeks to feature freeze >> >> >> "Dann Corbit" <[EMAIL PROTECTED]> writes: >> >> >> >> Why couldn't you just release the win32 version of 7.4 when >> >> it was finished. If it takes an extra month then that just >> >> gives you guys the chance to circulate *two* press releases. >> >> The Native Win32 port is likely to make a big enough splash >> >> all by itself. >> > >> > A formal release needs a big testing effort. Two separate releases >> > will double the work of validation. >> >> There are several problems with that statement. The first is >> that PostgreSQL's "testing effort" happens right here on this >> mailing list. > > That's not exactly reassuring. There is no regression test that > gets formal acceptance?! Yes, there are regression tests, and new tests get invented all of the time whenever the real world finds new bugs. Regression tests are excellent for making sure that you don't make the same mistake twice, but they aren't a substitute for handing the code over to actual end users. >> The various PostgreSQL hackers code stuff up, >> and we try and break it. There's very little /effort/ >> involved. People that want the new features go out on a limb >> and start using them. If they don't work, then they bring it >> up on the list. If they do work then very little gets said. >> >> As it now stands Tom Lane is on the record as stating that >> the new Win32 version isn't going to be ready for production >> anyhow. If anything the Win32 version *should* get released >> separately simply because we don't want people mistaking the >> Win32 version as being up to the PostgreSQL teams high >> standards. Those people that want the Win32 version to >> become production ready are going to have to risk their >> precious data. Otherwise, the Win32 version will likely >> remain a second class citizen forever. >> >> The fact of the matter is that the Win32 specific bits are >> the parts that are likely to break in the new port. If >> anything the Windows version will *benefit* from an earlier >> *nix release because the *nix users will chase down the bugs >> in the new PostgreSQL features. Once the *nix version is up >> to 7.4.2 (or so) then a Windows release of 7.4.2 should allow >> the PostgreSQL hackers to simply chase down Windows specific problems. > > Then using the same logic, the new Windows version should wait > indefinitely, since the *nix version will always be shaking out > bugs. That's not true at all. Despite the excellent work by the PostgreSQL team, and despite the beta testing that will be done by volunteers, if history repeats itself, there will be problems with version 7.4.0, even on platforms that have been well supported by PostgreSQL forever. I am not saying that we should hold off indefinitely on the Win32 port, I am simply saying that it probably wouldn't hurt to shake out the normal .0 release bugs before throwing the unique Win32 bugs into the mix. My guess is that reported Win32 bugs are going blamed on the Win32 specific bits at first no matter what happens. Unless the bug can be demonstrated on a *nix version it will be assumed that the problem is a shortcoming of the Win32 specific code. That's just common sense. >> Adding a new platform--especially a platform as diverse from >> the rest of PostgreSQL's supported platforms as Windows--is >> what adds the work. Testing the new platform is relatively >> easy. All you need to do is to start using the Win32 version >> with real live data. > > That is not testing. Using the world as your beta team seems to be > a business model used by a few software giants that is largely > frowned upon. I would think that there is an opportunity to do > things differently. [Read 'properly']. Hmm... I must have missed the huge corporation paying for in house testing of PostgreSQL. In the Free Software world the "beta team" is all of those people that need the new features so badly that they are willing to risk their own data and hardware testing it. You might not like the way that this sounds, but in practice it works astoundingly well. Chances are you can't name 25 pieces of commercial software that run on the wide
Re: [HACKERS] sa_family_t in cygwin compile of cvs + regression failure
Bruce, On Mon, Jun 23, 2003 at 09:50:49PM -0400, Bruce Momjian wrote: > OK, patch applied to typedef sa_family_t for cygwin. If other > platforms need it, I will have to do something more generic. I'm happy to report that the above patch solves one of Cygwin's current build problems. However, Cygwin still needs the following patch: http://archives.postgresql.org/pgsql-patches/2003-06/msg00186.php Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [CYGWIN] [HACKERS] ss_family in hba.c
Bruce, On Mon, Jun 23, 2003 at 07:49:11PM -0400, Bruce Momjian wrote: > This should fix most platforms. I am not sure how cygwin is going to > handle this --- we might have to add a specific sa_family_t typedef > for that platform --- MinGW does have sa_family_t, but probably > doesn't need it anyway. Testing for the size of sa_family_t is > possible via configure, but if only cygwin needs it, we can just > hard-code that platform in the template files. Cygwin folks, would > you test CVS and let me know. The above seems to be OK for Cygwin too. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ss_family in hba.c
Bruce, On Tue, Jun 24, 2003 at 03:04:05PM -0400, Bruce Momjian wrote: > Kurt Roeckx wrote: > > All that probably needed to change for cygwin was to no longer > > use sa_family_t in the getaddrinfo.c. > > But Jason reported he needed that typedef for sa_family_t. Jason, is > that accurate. Yes. > If you remove the Cygwin typedef in pqcomm.h, does the compile fail? Yes: gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -DBUILDING_DLL -c -o printtup.o printtup.c In file included from ../../../../src/include/libpq/libpq-be.h:22, from ../../../../src/include/libpq/libpq.h:21, from printtup.c:20: ../../../../src/include/libpq/pqcomm.h:54: parse error before "sa_family_t" [snip] Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PostgreSQL 7.4 Beta 1 + SSL + Cygwin
Carlos, On Fri, Aug 08, 2003 at 09:20:01AM +0200, Carlos Guzman Alvarez wrote: > >I want to know if postgresql 7.4 beta 1 can be configured under > >Cygwin with SSL support ?? > > > >If the answer is positive how can i do it ?? or where can i found > >documentation about this ( under linux or cygwin :) ) ?? > > I have found this on PostgreSQL docs :) i have it configured yet. Is this just the "--with-openssl" option? Does it build cleanly under Cygwin? If so, would you like me to include this in the next Cygwin PostgreSQL release? Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL 7.4 Beta 1 + SSL + Cygwin
Thomas, [I would have responded sooner, but I have been on vacation.] On Thu, Aug 21, 2003 at 11:10:05AM -0500, Thomas Swan wrote: > On 8/8/2003 5:49 AM, Jason Tishler wrote: > >Is this just the "--with-openssl" option? Does it build cleanly > >under Cygwin? If so, would you like me to include this in the next > >Cygwin PostgreSQL release? > > > 7.4beta1 would not compile under Cygwin with or without SSL. However, > the CVS tip for 2003/08/20 did compile and run under Cygwin both with > and without SSL. I had to adjust some path variables to include > cygwin/usr/lib and cygwin/usr/lib/postgresql. postgresql was > configured with > > ./configure --prefix=/usr --with-openssl > make > make install > > I used ipc-daemon2, and I had to use cygwin.dll v1.5.x. I will give CVS tip a ride and try to supply a patch. Thanks for the heads up. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL 7.4 Beta 1 + SSL + Cygwin
Thomas, On Sun, Aug 24, 2003 at 04:55:42PM -0400, Jason Tishler wrote: > On Thu, Aug 21, 2003 at 11:10:05AM -0500, Thomas Swan wrote: > > On 8/8/2003 5:49 AM, Jason Tishler wrote: > > >Is this just the "--with-openssl" option? Does it build cleanly > > >under Cygwin? If so, would you like me to include this in the next > > >Cygwin PostgreSQL release? > > > > > 7.4beta1 would not compile under Cygwin with or without SSL. > > However, the CVS tip for 2003/08/20 did compile and run under Cygwin > > both with and without SSL. I had to adjust some path variables to > > include cygwin/usr/lib and cygwin/usr/lib/postgresql. postgresql > > was configured with > > > > ./configure --prefix=/usr --with-openssl > > make > > make install > > > > I used ipc-daemon2, and I had to use cygwin.dll v1.5.x. > > I will give CVS tip a ride and try to supply a patch. AFAICT, CVS updated on 2003/08/25 at approximately 2:00 PM ET, configured as: configure --enable-multibyte --with-python --with-perl --with-java --with-CXX --with-openssl ... builds cleanly under Cygwin 1.5.2-1 and cygipc 2.01-2. The above without SSL builds cleanly too. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Win32 native port
On Fri, Sep 12, 2003 at 08:57:16AM -0400, Merlin Moncure wrote: > Here: http://unxutils.sourceforge.net/ are ports of several unix > utility programs (including bison and flex) for win32. From my > experiences compiling the Peer Direct port, this is the easiest way to > get started. OK, I'll throw my hat in the ring... :,) I recommend using Cygwin in -mno-cygwin (aka Mingw) mode for the following reasons: 1. Using Cygwin gcc -mno-cygwin mode produces native Win32 applications (i.e., do not depending on the Cygwin DLL) that are not affected by the Cygwin license. 2. Using Cygwin as the Win32 build environment will facilitate keeping the Unix and Win32 build environments as similar as possible. For example: a. Posix path can be used for both environments b. symlinks can be used for both environments 3. Cygwin provides all the necessary tools (e.g., bison and flex). Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] populating a table via the COPY command using C code.
hi, I'm writing an application in C that basically converts binary data into something meaningful. My first attempt was to parse the binary and insert directly to the database in one step. But this proved to be very slow. So I decided to go with a two step process. The first step is to parse the data and create a flat file with tab delimited fields. The second step is to load this data using the COPY command. I don't quite understand how this is done within C. Can someone provide me with some examples. I've already done some searches on the internet. the examples that I found don't match with I'm trying to do. Please help! thanks, jason. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Cygwin - make check broken
On Sun, Aug 07, 2005 at 02:51:12PM -0400, Tom Lane wrote: > I back-patched 7.4 as well, which is the oldest branch that has this > code. The Cygwin people still need to fix their bug, since it's > entirely possible to run the system out of FDs after we're up and > running ... but it's surely a waste of cycles to do it deliberately > during postmaster startup. AFAICT, this should be fixed in Cygwin CVS: http://cygwin.com/ml/cygwin/2005-08/msg00249.html Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] compile warnings on cygwin - make check fails
Andrew, On Fri, Oct 10, 2003 at 12:25:01AM -0400, Andrew Dunstan wrote: > WinXP/cygwin/gcc version 3.3.1 (cygming special) XP Home or Pro? What version of Cygwin? > gives these > > tablecmds.c:3528: warning: dereferencing type-punned pointer will break > strict-aliasing rules > [snip] FWIW, I saw warnings I never saw before when compiling Python under Cygwin gcc 3.3.1 yesterday. I presume gcc 3.3.1 is pickier or more "chatty" than it was before. Anyway, Python still passed its full regression test. > make check fails (hangs) consistently on parallel tests Are you getting hangs or connection refused errors. The Cygwin PostgreSQL README documents the following issue: 1. make check can generate spurious regression test failures due to overflowing the the listen() backlog queue which generates connection refused errors. Note that make installcheck does not have this problem since it runs all tests sequentially instead of in large concurrent groups. > max_connections set to 100, shared_buffers set to 1000 by initdb (CVS > version, not mine). The above will not have any affects under Cygwin. IIRC, the listen() backlog is 200 under server versions of Windows (e.g., 2000 Advanced Server) and 5 on all other versions (e.g., XP Pro). Can you try make installcheck instead? Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] compile warnings on cygwin - make check fails
Andrew, On Fri, Oct 10, 2003 at 08:56:51AM -0400, Andrew Dunstan wrote: > Jason Tishler wrote: > >Are you getting hangs or connection refused errors. The Cygwin > >PostgreSQL README documents the following issue: > >[snip] > > hangs - I have to kill the psql process to continue. This could mean it will hang on NT and 2000 too. Sigh... Can you attach to the hung psql to determine where it's hanging? > >Can you try make installcheck instead? > > will do tonight after work. Thanks! Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] \xDD in COPY Statement
Hi all, On advice from Gavin I'm finally having a look at a few bits and pieces I can do around the pg source and Gavin suggested the hex in copy statement. Researching the lists someone has provided a rudimentary patch for this late last year (http://archives.postgresql.org/pgsql-hackers/2002-10/msg00767.php). Is the functionality still required (I know it's not in cvs yet) failing that are there any other similar sized tasks requiring attention? Rgds, Jason ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] \xDD patch for 7.5devel
Hi all,
This is my first patch for PostgreSQL against the 7.5devel cvs (please advise if this
is the wrong place to post patches). This patch simply enables the \xDD (or \XDD)
hexadecimal import in the copy command (im starting with the simple stuff first). I
did notice that there may be a need to issue an error if an invalid octal or hex
character is found following a \ or \x. No errors are currently flagged by the octal
(or this hex) import.
Rgds,
Jason
cvs server: Diffing .
Index: copy.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/commands/copy.c,v
retrieving revision 1.213
diff -u -r1.213 copy.c
--- copy.c 6 Oct 2003 02:38:53 - 1.213
+++ copy.c 5 Nov 2003 11:19:33 -
@@ -48,9 +48,10 @@
#include "utils/lsyscache.h"
#include "utils/syscache.h"
-
#define ISOCTAL(c) (((c) >= '0') && ((c) <= '7'))
#define OCTVALUE(c) ((c) - '0')
+#define ISHEX(c) c)>='0') && ((c)<='9')) || (((c)>='A') && ((c)<='F')) ||
(((c)>='a') && ((c)<='f')))
+#define HEXVALUE(c) (((c)>='a') ? ((c)-87) : (((c)>='A') ? ((c)-55) : ((c)-'0')))
/*
* Represents the different source/dest cases we need to worry about at
@@ -1947,6 +1948,33 @@
c = line_buf.data[line_buf.cursor++];
switch (c)
{
+ case 'x':
+ case 'X':
+ {
+ if (line_buf.cursor < line_buf.len)
+ {
+ int hexval = 0;
+
+ c =
line_buf.data[line_buf.cursor];
+ if (ISHEX(c))
+ {
+ line_buf.cursor++;
+ hexval = HEXVALUE(c);
+ if (line_buf.cursor <
line_buf.len)
+ {
+ c =
line_buf.data[line_buf.cursor];
+
line_buf.cursor++;
+ if (ISHEX(c))
+ {
+
line_buf.cursor++;
+ hexval
= (hexval << 4) + HEXVALUE(c);
+ }
+ }
+ }
+ c = hexval;
+ }
+ }
+ break;
case '0':
case '1':
case '2':
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] \xDD patch for 7.5devel
On Thu, 6 Nov 2003 06:25 am, Markus Bertheau wrote: > Ð ÐÑÐ, 05.11.2003, Ð 16:25, Tom Lane ÐÐÑÐÑ: > > > +#define HEXVALUE(c) (((c)>='a') ? ((c)-87) : (((c)>='A') ? ((c)-55) : > > > ((c)-'0'))) > > > > This seems excessively dependent on the assumption that the character > > set is ASCII. Why have you hard-coded numeric equivalents into this > > macro? > > What not ASCII compatible character sets are out there in use still > today? Ah, yes - didn't even think about the character sets. If thats the case then octal needs attention as well because it makes a similar assumption. Peter Eisentraut commented that this should be in the string literal parser. Should this be the case? and if so should i migrate both octal and hex to this parser? Rgds, Jason ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] \xDD patch for 7.5devel
> #define HEXVALUE(c) \ > (((c) >= '0' && (c) <= '9') ? ((c) - '0') : \ >(((c) >= 'A' && (c) <= 'F') ? ((c) - 'A' + 10) : \ > ((c) - 'a' + 10))) > > 3. The third level would be to get rid of the assumption that letters > are contiguous, which would probably require making a lookup table to > map from char code to hex value. > > I'm not sure level 3 is really worth doing, since AFAIK no one tries to > run Postgres on any EBCDIC platform. (It's likely that there are other > places that depend on the letters-are-contiguous assumption anyway.) > I do think level 1 and probably level 2 are appropriate changes. > > regards, tom lane Hi Guys, Thanks for the feedback. Tom I'll make the changes proposed here to the macro and repost the patch to pgsql-patches (and do some reading on Unicode!). I guess at this stage I would like to offer any of my time to any janitorial work that might be needed as until im more knowledgeable about the pg source I think any large scale stuff is off the cards. Rgds, Jason ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] postgres panic error
Yurgis, On Tue, Dec 09, 2003 at 04:18:06PM -0800, Yurgis Baykshtis wrote: > I tried to raise the question on pg-hackers forum and cygwin forum > (regarding readdir() misbehavior) but could not get any help so far :( If you can produce a minimal test case that reproduces the problem, then one of the core Cygwin developers might be more willing to attempt to fix it. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Cannot read block error.
I am running PostgreSQL 7.3.3 on OS X Server 10.2 The database has been running just fine for quite some time now, but this morning it began pitching the error: ERROR: cannot read block 176 of tfxtrade_details: Numerical result out of range any time the table tfxtrade_details is accessed. A description of the table is at the end of this email I have a backup from last night, so I haven't lost much data (if any), but I am curious if there is a way to recover from this (beyond restoring from backup) and how I would go about figuring out what caused it to prevent it from happening again. I will keep a copy of the data directory if anyone wants me to do any analysis on it (I will need instructions). Any insights would be appreciated. Thanks Jason Essington [EMAIL PROTECTED] hedgehog=# \d tfxtrade_details Table "public.tfxtrade_details" Column | Type | Modifiers ---+--+--- rid | integer | not null clientid | integer | tradeid | integer | rollid| integer | rollpct | numeric(10,8)| expdetailid | integer | expid | integer | contractpct | numeric(10,8)| contractamt | numeric(18,2)| origpct | numeric(10,8)| origamt | numeric(18,2)| acctgperiod | integer | acctgperiodid | integer | editdate | timestamp with time zone | edituserid| character varying(48)| parentid | integer | entityid | integer | tradedate | date | maturitydate | date | strategyid| integer | currencyid| integer | Indexes: tfxtrade_details_pkey primary key btree (rid), tfxlinks_entityid_index btree (entityid), tfxlinks_expdetailid_index btree (expdetailid), tfxlinks_expid_index btree (expid), tfxlinks_mdate_index btree (maturitydate), tfxlinks_parentid_index btree (parentid), tfxlinks_strategy_index btree (strategyid), tfxlinks_tradeid_index btree (tradeid) Triggers: RI_ConstraintTrigger_30891, RI_ConstraintTrigger_30894, tfxdetail_delete_trigger ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Cannot read block error.
Both vacuum [full] and reindex fail with that same error. vacuum is run regularly via a cron job. -jason On Feb 14, 2004, at 2:29 PM, Joshua D. Drake wrote: Hello, When was the last time you ran a reindex? Or a vacuum / vacuum full? Sincerely, Joshua D. Drake On Sat, 14 Feb 2004, Jason Essington wrote: I am running PostgreSQL 7.3.3 on OS X Server 10.2 The database has been running just fine for quite some time now, but this morning it began pitching the error: ERROR: cannot read block 176 of tfxtrade_details: Numerical result out of range any time the table tfxtrade_details is accessed. A description of the table is at the end of this email I have a backup from last night, so I haven't lost much data (if any), but I am curious if there is a way to recover from this (beyond restoring from backup) and how I would go about figuring out what caused it to prevent it from happening again. I will keep a copy of the data directory if anyone wants me to do any analysis on it (I will need instructions). Any insights would be appreciated. Thanks Jason Essington [EMAIL PROTECTED] hedgehog=# \d tfxtrade_details Table "public.tfxtrade_details" Column | Type | Modifiers ---+--+--- rid | integer | not null clientid | integer | tradeid | integer | rollid| integer | rollpct | numeric(10,8)| expdetailid | integer | expid | integer | contractpct | numeric(10,8)| contractamt | numeric(18,2)| origpct | numeric(10,8)| origamt | numeric(18,2)| acctgperiod | integer | acctgperiodid | integer | editdate | timestamp with time zone | edituserid| character varying(48)| parentid | integer | entityid | integer | tradedate | date | maturitydate | date | strategyid| integer | currencyid| integer | Indexes: tfxtrade_details_pkey primary key btree (rid), tfxlinks_entityid_index btree (entityid), tfxlinks_expdetailid_index btree (expdetailid), tfxlinks_expid_index btree (expid), tfxlinks_mdate_index btree (maturitydate), tfxlinks_parentid_index btree (parentid), tfxlinks_strategy_index btree (strategyid), tfxlinks_tradeid_index btree (tradeid) Triggers: RI_ConstraintTrigger_30891, RI_ConstraintTrigger_30894, tfxdetail_delete_trigger ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Co-Founder Command Prompt, Inc. The wheel's spinning but the hamster's dead ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Cannot read block error.
Starting in single user mode and reindexing the database didn't fix the error, although it seemed to run just fine. Vacuum verbose ran until it hit the tfxtrade_details table and then it died with that same error. it didn't whine about any other problems prior to dying. INFO: --Relation public.tfxtrade_details-- ERROR: cannot read block 176 of tfxtrade_details: Numerical result out of range Guess there is just something really munged in this one. I'll just try to restore it from the backup. Interesting, when I went to copy my data directory out of the way, I received this from cp: cp: data/base/16976/17840: Result too large might be a clue -jason On Feb 14, 2004, at 5:01 PM, Joshua D. Drake wrote: Hello, There are a couple of things it could be. I would suggest that you take down the database, start it up with -P? (I think it is -o '-P' it might be -p '-O' I don't recall) and try and reindex the database itself. You can also do a vacuuum verbose and see if you get some more errors you may have a corrupt system index that needs to be reindexed. Sincerely, Johsua D. Drake On Sat, 14 Feb 2004, Jason Essington wrote: Both vacuum [full] and reindex fail with that same error. vacuum is run regularly via a cron job. -jason On Feb 14, 2004, at 2:29 PM, Joshua D. Drake wrote: Hello, When was the last time you ran a reindex? Or a vacuum / vacuum full? Sincerely, Joshua D. Drake On Sat, 14 Feb 2004, Jason Essington wrote: I am running PostgreSQL 7.3.3 on OS X Server 10.2 The database has been running just fine for quite some time now, but this morning it began pitching the error: ERROR: cannot read block 176 of tfxtrade_details: Numerical result out of range any time the table tfxtrade_details is accessed. A description of the table is at the end of this email I have a backup from last night, so I haven't lost much data (if any), but I am curious if there is a way to recover from this (beyond restoring from backup) and how I would go about figuring out what caused it to prevent it from happening again. I will keep a copy of the data directory if anyone wants me to do any analysis on it (I will need instructions). Any insights would be appreciated. Thanks Jason Essington [EMAIL PROTECTED] hedgehog=# \d tfxtrade_details Table "public.tfxtrade_details" Column | Type | Modifiers ---+--+--- rid | integer | not null clientid | integer | tradeid | integer | rollid| integer | rollpct | numeric(10,8)| expdetailid | integer | expid | integer | contractpct | numeric(10,8)| contractamt | numeric(18,2)| origpct | numeric(10,8)| origamt | numeric(18,2)| acctgperiod | integer | acctgperiodid | integer | editdate | timestamp with time zone | edituserid| character varying(48)| parentid | integer | entityid | integer | tradedate | date | maturitydate | date | strategyid| integer | currencyid| integer | Indexes: tfxtrade_details_pkey primary key btree (rid), tfxlinks_entityid_index btree (entityid), tfxlinks_expdetailid_index btree (expdetailid), tfxlinks_expid_index btree (expid), tfxlinks_mdate_index btree (maturitydate), tfxlinks_parentid_index btree (parentid), tfxlinks_strategy_index btree (strategyid), tfxlinks_tradeid_index btree (tradeid) Triggers: RI_ConstraintTrigger_30891, RI_ConstraintTrigger_30894, tfxdetail_delete_trigger ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Co-Founder Command Prompt, Inc. The wheel's spinning but the hamster's dead ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Co-Founder Command Prompt, Inc. The wheel's spinning but the hamster's dead ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Segfault Exiting psql
Has there been any movement on this? as of 8.1.2 psql still whines on
OS X tiger when you exit.
I realize it is not significant, but I'd still rather not see it.
In the interim, I've done:
errno = 0;
write_history(fname); /* return value is not standardized */
if (errno)
psql_error("could not save history to file \"%s\": %s\n", fname,
strerror(errno));
else
return true;
and it seems to have cured the problem for me. Is this even
reasonable? I'm not a C programmer
-jason
On Aug 28, 2005, at 12:04 PM, Tom Lane wrote:
What I'm kind of inclined to do is change our saveHistory() function
to not look at the return value of write_history() at all, but instead
do
errno = 0;
write_history(fname); /* return value is not standardized */
if (errno)
print message;
Anyone have a better idea?
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [CYGWIN] [HACKERS] Need for DLLINIT in Makefile.shlib
On Tue, Oct 12, 2004 at 01:37:48AM +0200, Reini Urban wrote: > Bruce Momjian schrieb: > >I am curious why Cygwin needs DLLINIT in Makefile.shlib, and Win32 > >doesn't: > > > > [snip] > > > >The only difference I see is that Cygwin uses $(DLLINIT) while Win32 > >does not. Is that correct? Why? > > > >Both set DLLINIT in their makefiles: > > > > DLLINIT = $(top_builddir)/src/utils/dllinit.o > > > >Could they be merged into a single snipped of code? > > Good point! Out of my head: I don't think that we (cygwin) don't need > that anymore. With newer binutils it should get autogenerated. But > I'll have to test before you can remove that dir. I concur with Reini. The DLLINIT stuff is a vestige from b20.1. FWIW, I attempted to remove it 3 - 4 years ago, but was unsuccessful... Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [CYGWIN] cygwin test package available
Reini, On Mon, Oct 04, 2004 at 11:16:49PM +0200, Reini Urban wrote: > This time contrib is added to the cygwin package. It was not in 7.4.x. Actually, contrib was included: $ tar -tjf postgresql-7.4.5-1.tar.bz2 | fgrep contrib usr/share/doc/postgresql-7.4.5/contrib/ usr/share/doc/postgresql-7.4.5/contrib/autoinc.example ... Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [INTERFACES] Re: [HACKERS] Announcing PgSQL - a Python DB-API 2.0 compliant interface to PostgreSQL
Actually with version 3.0 of PyGreSQL there is a DB-API v2.0 compliant wrapper pgdb.py. --- Peter Eisentraut <[EMAIL PROTECTED]> wrote: > Bruce Momjian writes: > > > I need to know how this is different than our > current python interface, > > PyGreSQL. > > > > PgSQL is a package of two (2) modules that > provide a Python DB-API 2.0 > > > compliant interface to PostgreSQL databases. > > DB-API is the standard database interface for > Python. Kind of like > DBD/DBI for Perl. > > The existing one is hand-crafted, kind of like the > Pg Perl module. > > -- > Peter Eisentraut [EMAIL PROTECTED] > http://yi.org/peter-e/ > __ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/
[HACKERS] Buffer Allocation Concurrency Limits
In December, Metin (a coworker of mine) discussed an inability to scale a simple task (parallel scans of many independent tables) to many cores (it’s here). As a ramp-up task at Citus I was tasked to figure out what the heck was going on here. I have a pretty extensive writeup here (whose length is more a result of my inexperience with the workings of PostgreSQL than anything else) and was looking for some feedback. In short, my conclusion is that a working set larger than memory results in backends piling up on BufFreelistLock. As much as possible I removed anything that could be blamed for this: Hyper-Threading is disabled zone reclaim mode is disabled numactl was used to ensure interleaved allocation kernel.sched_migration_cost was set to highly disable migration kernel.sched_autogroup_enabled was disabled transparent hugepage support was disabled For a way forward, I was thinking the buffer allocation sections could use some of the atomics Andres added here. Rather than workers grabbing BufFreelistLock to iterate the clock hand until they find a victim, the algorithm could be rewritten in a lock-free style, allowing workers to move the clock hand in tandem. Alternatively, the clock iteration could be moved off to a background process, similar to what Amit Kapila proposed here. Is this assessment accurate? I know 9.4 changes a lot about lock organization, but last I looked I didn’t see anything that could alleviate this contention: are there any plans to address this? —Jason
Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?
On Apr 18, 2014, at 1:51 PM, Atri Sharma wrote: > Counting clock sweeps is an intersting idea. I think one concern was > tracking hot buffers in cases where there is no memory pressure, and > hence the clock sweep isn't running --- I am not sure how this would > help in that case. > Yes, we obviously want a virtual clock. Focusing on the use of gettimeofday seems silly to me: it was something quick for the prototype. The problem with the clocksweeps is they don’t actually track the progression of “time” within the PostgreSQL system. What’s wrong with using a transaction number or some similar sequence? It would accurately track “age” in the sense we care about: how long ago in “units of real work being done by the DB” something was added. —Jason
Re: [HACKERS] [INTERFACES] Interface update for 7.3
"Bruce Momjian" <[EMAIL PROTECTED]> writes: > I am working with David Wheeler on DBD:pg and hope to have a release > packaged up tomorrow. Bruce, David, I'm updating all the test scripts to properly use the standard DBI testing env vars, e.g. DBI_DSN, DBI_USER, DBI_PASS, and to use Test::More. I've finished and committed half of them, I'll let you know when I'm done. Cheers, jas. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [INTERFACES] Interface update for 7.3
"Jason E. Stewart" <[EMAIL PROTECTED]> writes: > "Bruce Momjian" <[EMAIL PROTECTED]> writes: > > > I am working with David Wheeler on DBD:pg and hope to have a release > > packaged up tomorrow. > > Bruce, David, > > I'm updating all the test scripts to properly use the standard DBI > testing env vars, e.g. DBI_DSN, DBI_USER, DBI_PASS, and to use > Test::More. > > I've finished and committed half of them, I'll let you know when I'm > done. Ok, all done. All tests now use standard DBI vars and Test::More. All tests pass. David, could you take a look at 11quoting.t? I'm pretty sure you wrote this test (didn't you?). I converted the array of tests to a hash table so that I could give them names. However, I could only give the tests names like 'one', 'two', etc. Perhaps you can think of something more descriptive. The names are a really nice feature of Test::More. When you run the test files individually it prints out: 1..8 ok 1 - connect with transaction ok 2 - three: \ -> expected '\134' got '\134' ok 3 - five: \'?: -> expected '\134\047?:' got '\134\047?:' ok 4 - one: ' -> expected '\047' got '\047' ok 5 - two: '' -> expected '\047\047' got '\047\047' ok 6 - four: \' -> expected '\134\047' got '\134\047' ok 7 - SQL_BINARY ok 8 - disconnect So that you can find a test by name when it fails. Cheers, jas. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Query planner/stored procedure cost
Hello... I haven't been subscribed in a while, but I've got an issue and am trying to determine if the Right Way(tm) is the quickest way to fix it. Basically, I have some very expensive stored procedures that determine whether a user should have access to particular rows in a query (not a postgresql user, we only use one postgresql user... the user is passed as a parameter to the function). The logic--per row--contains about a dozen queries and probably averages eight queries per run, with short-circuiting and all. So it is _very_ expensive. Given that I use this function in lots of queries with hairy joins and all, I'd much like for the optimizer to know what to do with the function. Empirically, I deduce that the optimizer treats all procedures as inexpensive (it seems to always just tack it on to the `Filter' slot when scanning the related table). Currently I'm using stored procedures returning multiple rows to get around the planner on these and defer the expensive procedure until the last possible moment (so that joins and other table criteria have a chance to filter out a lot of records). This typically shaves 75% of the time off of these queries. So, the question is: What am I looking at in doing the following: 1) Adding a mechanism to tell PostgreSQL how expensive a procedure is (a system table which can be updated manually, or an existing system table if there is a logical place for it). 2) Updating the planner to consider the procedure's cost in estimates. 3) Changing the query planner to consider "bubbling up" the function to an outer filter slot. Possibly, also: 4) Changing the planner to order expressions in a `Filter' slot by cost. although I don't mind doing this manually and I know the order can determine which indices PostgreSQL uses. I'm still mulling it over, and I'm guessing the real problem here is if it is a wise generalization that we can "bubble-up" the function. What if the function has side effects? Does this break? We can at least do procedures with `iscachable' flag. Disclaimer: I haven't every really hacked the planner code, but I have a good feel for how it works from lots and _lots_ of experience with it -Jay 'Eraserhead' Felice ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] SQL99 ARRAY support proposal
On Mon, Mar 10, 2003 at 09:49:47AM -0500, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Joe Conway kirjutas E, 10.03.2003 kell 05:35:
> >> CREATE OR REPLACE FUNCTION array_push (anyarray, anyscalar)
> >> RETURNS anyarray
>
> > could you make it
> > RETURNS typeof($1)
>
> Not directly --- we have to fit the return-type info into an OID field.
> We could fake it by inventing one or more pseudotypes, "SAMEASPARAMn".
>
> But I think I like better the notion of extending my bound-together-
> ANYARRAY-and-ANYELEMENT proposal,
> http://archives.postgresql.org/pgsql-hackers/2003-03/msg00319.php
>
> Suppose that we do that, and then further say that ANYARRAY or
> ANYELEMENT appearing as the return type implies that the return type
> is actually the common element or array type. Then we have such
> useful behaviors as:
>
> array_push(anyarray, anyelement) returns anyarray
> array_pop(anyarray) returns anyelement
> array_subscript(anyarray, int) yields anyelement
> singleton_array(anyelement) yields anyarray
>
> The last three cases cannot be handled by a SAMEASPARAM construct.
... typeof($1)[], or a ARRAYELEMSAMEASPARAM construct?
I'm really liking this discussion. I know this is sort of "out there", but
I have found in languages like StandardML and Objective CAML that templatized-
type functions are _extremely_ useful. These languages type systems are
amazingly powerful (the language syntax is another matter *sigh*).
I'm not necessarily suggesting implementing this, but I just want to feed the
debate a bit. I view the type system of these guys as "the ideal", and would
be in ecstacy if PostgreSQL had it, but I realize implementing the thing would
prolly be far from practical.
First, there are templatized types. Arrays in PostgreSQL are sort of a
kludge of templatized types, but they would be defined like so:
type a' array =
which means that you are describing an array of some type a' (the apostrophe
indicates a type variable).
You can also create other neat templatized types as an aside:
type a' Nullable = Null | Value of a'
Which means the expressions:
Value 47 --> of type int Nullable
Null --> of type a' Nullable (determined from context)
But then, you could also say:
int array array
Or even:
int Nullable array
Which is somthing you can't in PostgreSQL but would be very nice. But then
you could say:
let invert_matrix m : a' array array -> a' array array =
let multiply x : a', y : a' -> a' =
You could have more than one type variable in a templatized type or function,
true, but I've never really needed more than one. I can imagine cases where
it would be useful, but just haven't needed one.
Plus:
* get rid of horrible 'int4_' type hacks for array.
Minus:
* can't use oid to represent exact type, rather a string of oids.
* need second table to hold function type constraints when function
is templatized. (or could make it params "oid array array", aka
oid[][]!) Reserve eight or ten oids for template parameter slots
(in other words, for a' through j' or something).
Warning: I have been called the "type nazi"
One other thing from StandardML that I have always wanted in PostgreSQL
(or anywhere else I program, for that matter)- record types. (Warning, this is
also very wishful thinking and "out there").
In ML/CAML, a record type is defined like so:
type myrecord = {
x : int,
y : int,
s : string
};
"myrecord" is actually just type alias, the canonical record definition is:
{s:string, x:int, y:int}
... with the attributes in alphabetical order, because unless you are mucking
with pointers in C, it really doesn't matter what order they are in. The
first advantage become very apparent: Any two records with the same named
attributes of the same types are always of the same type. In PostgreSQL,
this would mean that functions that operate on RECORD{x:int,y:int,s:string}
could operate on a record from any relation with those attributes.
Further, to make inheritance pretty much unnecesary, you could allow a
record with more attributes to satisfy a parameter or return value constraint.
In other words, you could call function foo(RECORD{x:int,y:int}) on a
RECORD{s:string,x:int,y:int}.
I've thought about this trick a lot. In theory there is a possibility of
not getting what you want, but in practice it would almost never happen. The
demostrative case would be calling distance_from_origin(RECORD{x:int,y:int})
on RECORD{x:int,y:int,z:int}, but in this case you need to make a
distance_from_origin(RECORD{x:int,y:int,z:int}).
This way, you could make a function which operates on RECORD{oid:oid} which
could be called on any record from a table. I've wanted to do this sort of
thing on several occasions- one application has notes which can be attached
to any row, sort of like PostgreSQL comments. Another to keep track
Re: [HACKERS] PostgreSQL and SOAP, version 7.4/8.0
First, a SOAP query should be posted in SOAP message format, not using the
query string as you do. Second, I like the idea of calling external SOAP
services, but consider creating a language 'soap' you could do with a CREATE
FUNCTION type thing. e.g.
CREATE FUNCTION "foo" (TEXT) RETURNS INTEGER AS
'http://somewhere.com/path/to/.wsdl', 'foo'
LANGUAGE 'soap';
(hmm, it is unclear if this is what you are suggesting or not...)
Second, I hate SOAP because it is too bloated (have you read the spec(s)?).
If you can support xmlrpc instead, you'll save yourself a lot of headaches.
If you got SOAP working, though, I'd use it. It's more an implementation
thing.
On Fri, Mar 28, 2003 at 09:01:08AM -0500, mlw wrote:
> I have been working on moving some of my software to a more SOAP
> compatible interface. As I was doing it, it occured to me that a generic
> function could be written, in PostgreSQL's new function manager that
> allows multiple columns to be returned, that is a generic SOAP interface.
>
> All one would need do is define what is expected from the SOAP call in
> the "CREATE FUNCTION" statement. Then the generic SOAP function could
> then read what is expected and return the XML/SOAP data as a set of
> results as if it were a subquery.
>
> What is needed is an efficient way to find the data types and names from
> the functions definition. Does anyone know how to do that?
>
> A small program could also parse a WSDL file and write a "CREATE
> FUNCTION" script for the XML as well.
>
> On the flip side, I am also working on a PostgreSQL SOAP interface,
> where one does this:
>
> http://somehost/postgresql?query="select * from table"
>
> And a SOAP compatible resultset is returned.
>
> On a more advanced horizon, one should be able to do this:
>
> select * from localtable,
> mysoap('http://remotehost/postgresql?query=select * from foo') as soap
> where soap.field = localtable.field;
>
> If we can do that, PostgreSQL could fit into almost ANY service
> environment. What do you guys think? Anyone want to help out?
>
I have no time to volunteer for projects, but what the hell...! It's too
cool. I can't spend much time on it but bounce things off me and I'll
do whatever hacking I can squeeze in. What soap implementation would you
use for the PostgreSQL plugin? libsoap, last I checked, is a wee bit
out of date. And not documented.
-Jason
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL and SOAP, version 7.4/8.0
On Fri, Mar 28, 2003 at 01:36:43PM -0500, [EMAIL PROTECTED] wrote: > Of course, CORBA has actually been quite formally standardized, suffers > from many fairly interoperable implementations, and is rather a lot less > bloated than any of the XML-based schemes. It might be worth trying, > too... The ability to use the HTTP transport has it's advantages with web services-- You can throw something together with a few lines of PHP, you don't have to worry about how to activate objects, I've never been able to figure out how to handle transport-layer security and authentication with CORBA (of course, this was all fairly new stuff when I was working with it), all this stuff comes for free with the HTTP transport. I like CORBA, though, and I'd probably find a CORBA module useful, but it doesn't solve all the same problems. Hrm, I wonder if the overhead of XML-RPC wouldn't be too bad for the new PostgreSQL protocol... it probably would, but it would be entirely useful. You can make XML-RPC calls from mozilla javascript, so you could do some pretty sweet tweaking to keep your addresses in a pgsql database. As an "additional" protocol which postmaster can listen to it would rule. I'm making a habit of putting all the business logic into stored procedures, and this would basically publish the business logic in a very useful way. -Jason ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] EXPLAIN ANALYZE in comparable units
I'm curious if anyone's considered adding logic to count actual disk/cache hits to report for EXPLAIN ANALYZE so that we get a more apples-to-apples comparison? The other question is whether anyone has got scripts or tools or what not for testing and getting accurate numbers for the following tuning variables: random_page_cost cpu_tuple_cost cpu_index_tuple_cost cpu_operator_cost I've seen the code and the last one is pretty gross, but the first three could definitely swing the optimizer, especially with the hardware I might be getting ;-) If noone has scripts, can anyone suggest how to implement. -Jason ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL and SOAP, suggestions?
On Thu, Apr 03, 2003 at 07:54:13AM -0500, [EMAIL PROTECTED] wrote: > > I have been planning to "test" the whole thing with a few .NET > > applications. I am currently using expat to parse the output to ensure > > that it all works correcty. > > That, unfortunately, probably implies that your implementation is almost > totally non-interoperable. > > You should put out of your mind the notion of being "correct." Being > "correct" is pretty irrelevant if 80% of the requests that come from a VB.NET > client fail because Microsoft implemented part of their request differently > than what you interpreted as "correct." > > The point is that "correctness" isn't the thing you need to aim for; what you > should aim for is interoperability with the important client implementations. > > SOAP::Lite, .NET, probably some Java ones, C++ ones, and such. > > Nobody does "correctness" testing; they do interoperability tests where they > try to submit requests to Apache AXIS, .NET, WebSphere, and the lot of other > important implementations. If you're testing a server (as is the case here), > then the point is to run tests with a bunch of clients. > > Head to the SOAP::Lite and Axis projects; you'll see matrices describing this > sort of thing... Hmmm. Can I reiterate my support of XML-RPC here? -Jay 'Eraserhead' Felice > -- > (reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa")) > http://www.ntlug.org/~cbbrowne/advocacy.html > "Fear leads to anger. Anger leads to hate. Hate leads to using Windows > NT for mission-critical applications." --- What Yoda *meant* to say > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
