← Back to branch summary

~ubuntu-branches/ubuntu/oneiric/postgresql-9.1/oneiric-security

« back to all changes in this revision

Viewing changes to doc/src/sgml/html/bug-reporting.html

  • Committer: Bazaar Package Importer
  • Author(s): Martin Pitt
  • Date: 2011-05-11 10:41:53 UTC
  • Revision ID: james.westby@ubuntu.com-20110511104153-psbh2o58553fv1m0
Tags: upstream-9.1~beta1
Import upstream version 9.1~beta1

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/src/sgml/html/bug-reporting.html
 
1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
 
2
<HTML
 
3
><HEAD
 
4
><TITLE
 
5
>Bug Reporting Guidelines</TITLE
 
6
><META
 
7
NAME="GENERATOR"
 
8
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
 
9
REV="MADE"
 
10
HREF="mailto:pgsql-docs@postgresql.org"><LINK
 
11
REL="HOME"
 
12
TITLE="PostgreSQL 9.1beta1 Documentation"
 
13
HREF="index.html"><LINK
 
14
REL="UP"
 
15
TITLE="Preface"
 
16
HREF="preface.html"><LINK
 
17
REL="PREVIOUS"
 
18
TITLE="Further Information"
 
19
HREF="resources.html"><LINK
 
20
REL="NEXT"
 
21
TITLE="Tutorial"
 
22
HREF="tutorial.html"><LINK
 
23
REL="STYLESHEET"
 
24
TYPE="text/css"
 
25
HREF="stylesheet.css"><META
 
26
HTTP-EQUIV="Content-Type"
 
27
CONTENT="text/html; charset=ISO-8859-1"><META
 
28
NAME="creation"
 
29
CONTENT="2011-04-27T21:20:33"></HEAD
 
30
><BODY
 
31
CLASS="SECT1"
 
32
><DIV
 
33
CLASS="NAVHEADER"
 
34
><TABLE
 
35
SUMMARY="Header navigation table"
 
36
WIDTH="100%"
 
37
BORDER="0"
 
38
CELLPADDING="0"
 
39
CELLSPACING="0"
 
40
><TR
 
41
><TH
 
42
COLSPAN="5"
 
43
ALIGN="center"
 
44
VALIGN="bottom"
 
45
><A
 
46
HREF="index.html"
 
47
>PostgreSQL 9.1beta1 Documentation</A
 
48
></TH
 
49
></TR
 
50
><TR
 
51
><TD
 
52
WIDTH="10%"
 
53
ALIGN="left"
 
54
VALIGN="top"
 
55
><A
 
56
TITLE="Further Information"
 
57
HREF="resources.html"
 
58
ACCESSKEY="P"
 
59
>Prev</A
 
60
></TD
 
61
><TD
 
62
WIDTH="10%"
 
63
ALIGN="left"
 
64
VALIGN="top"
 
65
><A
 
66
TITLE="Preface"
 
67
HREF="preface.html"
 
68
>Fast Backward</A
 
69
></TD
 
70
><TD
 
71
WIDTH="60%"
 
72
ALIGN="center"
 
73
VALIGN="bottom"
 
74
>Preface</TD
 
75
><TD
 
76
WIDTH="10%"
 
77
ALIGN="right"
 
78
VALIGN="top"
 
79
><A
 
80
TITLE="Preface"
 
81
HREF="preface.html"
 
82
>Fast Forward</A
 
83
></TD
 
84
><TD
 
85
WIDTH="10%"
 
86
ALIGN="right"
 
87
VALIGN="top"
 
88
><A
 
89
TITLE="Tutorial"
 
90
HREF="tutorial.html"
 
91
ACCESSKEY="N"
 
92
>Next</A
 
93
></TD
 
94
></TR
 
95
></TABLE
 
96
><HR
 
97
ALIGN="LEFT"
 
98
WIDTH="100%"></DIV
 
99
><DIV
 
100
CLASS="SECT1"
 
101
><H1
 
102
CLASS="SECT1"
 
103
><A
 
104
NAME="BUG-REPORTING"
 
105
>Bug Reporting Guidelines</A
 
106
></H1
 
107
><P
 
108
>  When you find a bug in <SPAN
 
109
CLASS="PRODUCTNAME"
 
110
>PostgreSQL</SPAN
 
111
> we want to
 
112
  hear about it. Your bug reports play an important part in making
 
113
  <SPAN
 
114
CLASS="PRODUCTNAME"
 
115
>PostgreSQL</SPAN
 
116
> more reliable because even the utmost
 
117
  care cannot guarantee that every part of
 
118
  <SPAN
 
119
CLASS="PRODUCTNAME"
 
120
>PostgreSQL</SPAN
 
121
>
 
122
  will work on every platform under every circumstance.
 
123
 </P
 
124
><P
 
125
>  The following suggestions are intended to assist you in forming bug reports
 
126
  that can be handled in an effective fashion. No one is required to follow
 
127
  them but doing so tends to be to everyone's advantage.
 
128
 </P
 
129
><P
 
130
>  We cannot promise to fix every bug right away. If the bug is obvious, critical,
 
131
  or affects a lot of users, chances are good that someone will look into it. It
 
132
  could also happen that we tell you to update to a newer version to see if the
 
133
  bug happens there. Or we might decide that the bug
 
134
  cannot be fixed before some major rewrite we might be planning is done. Or
 
135
  perhaps it is simply too hard and there are more important things on the agenda.
 
136
  If you need help immediately, consider obtaining a commercial support contract.
 
137
 </P
 
138
><DIV
 
139
CLASS="SECT2"
 
140
><H2
 
141
CLASS="SECT2"
 
142
><A
 
143
NAME="AEN267"
 
144
>Identifying Bugs</A
 
145
></H2
 
146
><P
 
147
>   Before you report a bug, please read and re-read the
 
148
   documentation to verify that you can really do whatever it is you are
 
149
   trying. If it is not clear from the documentation whether you can do
 
150
   something or not, please report that too; it is a bug in the documentation.
 
151
   If it turns out that a program does something different from what the
 
152
   documentation says, that is a bug. That might include, but is not limited to,
 
153
   the following circumstances:
 
154
 
 
155
   <P
 
156
></P
 
157
></P><UL
 
158
><LI
 
159
><P
 
160
>      A program terminates with a fatal signal or an operating system
 
161
      error message that would point to a problem in the program. (A
 
162
      counterexample might be a <SPAN
 
163
CLASS="QUOTE"
 
164
>"disk full"</SPAN
 
165
> message,
 
166
      since you have to fix that yourself.)
 
167
     </P
 
168
></LI
 
169
><LI
 
170
><P
 
171
>      A program produces the wrong output for any given input.
 
172
     </P
 
173
></LI
 
174
><LI
 
175
><P
 
176
>      A program refuses to accept valid input (as defined in the documentation).
 
177
     </P
 
178
></LI
 
179
><LI
 
180
><P
 
181
>      A program accepts invalid input without a notice or error message.
 
182
      But keep in mind that your idea of invalid input might be our idea of
 
183
      an extension or compatibility with traditional practice.
 
184
     </P
 
185
></LI
 
186
><LI
 
187
><P
 
188
>      <SPAN
 
189
CLASS="PRODUCTNAME"
 
190
>PostgreSQL</SPAN
 
191
> fails to compile, build, or
 
192
      install according to the instructions on supported platforms.
 
193
     </P
 
194
></LI
 
195
></UL
 
196
><P>
 
197
 
 
198
   Here <SPAN
 
199
CLASS="QUOTE"
 
200
>"program"</SPAN
 
201
> refers to any executable, not only the backend process.
 
202
  </P
 
203
><P
 
204
>   Being slow or resource-hogging is not necessarily a bug. Read the
 
205
   documentation or ask on one of the mailing lists for help in tuning your
 
206
   applications. Failing to comply to the <ACRONYM
 
207
CLASS="ACRONYM"
 
208
>SQL</ACRONYM
 
209
> standard is
 
210
   not necessarily a bug either, unless compliance for the
 
211
   specific feature is explicitly claimed.
 
212
  </P
 
213
><P
 
214
>   Before you continue, check on the TODO list and in the FAQ to see if your bug is
 
215
   already known. If you cannot decode the information on the TODO list, report your
 
216
   problem. The least we can do is make the TODO list clearer.
 
217
  </P
 
218
></DIV
 
219
><DIV
 
220
CLASS="SECT2"
 
221
><H2
 
222
CLASS="SECT2"
 
223
><A
 
224
NAME="AEN287"
 
225
>What to Report</A
 
226
></H2
 
227
><P
 
228
>   The most important thing to remember about bug reporting is to state all
 
229
   the facts and only facts. Do not speculate what you think went wrong, what
 
230
   <SPAN
 
231
CLASS="QUOTE"
 
232
>"it seemed to do"</SPAN
 
233
>, or which part of the program has a fault.
 
234
   If you are not familiar with the implementation you would probably guess
 
235
   wrong and not help us a bit. And even if you are, educated explanations are
 
236
   a great supplement to but no substitute for facts. If we are going to fix
 
237
   the bug we still have to see it happen for ourselves first.
 
238
   Reporting the bare facts
 
239
   is relatively straightforward (you can probably copy and paste them from the
 
240
   screen) but all too often important details are left out because someone
 
241
   thought it does not matter or the report would be understood
 
242
   anyway.
 
243
  </P
 
244
><P
 
245
>   The following items should be contained in every bug report:
 
246
 
 
247
   <P
 
248
></P
 
249
></P><UL
 
250
><LI
 
251
><P
 
252
>      The exact sequence of steps <SPAN
 
253
CLASS="emphasis"
 
254
><I
 
255
CLASS="EMPHASIS"
 
256
>from program
 
257
      start-up</I
 
258
></SPAN
 
259
> necessary to reproduce the problem. This
 
260
      should be self-contained; it is not enough to send in a bare
 
261
      <TT
 
262
CLASS="COMMAND"
 
263
>SELECT</TT
 
264
> statement without the preceding
 
265
      <TT
 
266
CLASS="COMMAND"
 
267
>CREATE TABLE</TT
 
268
> and <TT
 
269
CLASS="COMMAND"
 
270
>INSERT</TT
 
271
>
 
272
      statements, if the output should depend on the data in the
 
273
      tables. We do not have the time to reverse-engineer your
 
274
      database schema, and if we are supposed to make up our own data
 
275
      we would probably miss the problem.
 
276
     </P
 
277
><P
 
278
>      The best format for a test case for SQL-related problems is a
 
279
      file that can be run through the <SPAN
 
280
CLASS="APPLICATION"
 
281
>psql</SPAN
 
282
>
 
283
      frontend that shows the problem. (Be sure to not have anything
 
284
      in your <TT
 
285
CLASS="FILENAME"
 
286
>~/.psqlrc</TT
 
287
> start-up file.)  An easy
 
288
      way to create this file is to use <SPAN
 
289
CLASS="APPLICATION"
 
290
>pg_dump</SPAN
 
291
>
 
292
      to dump out the table declarations and data needed to set the
 
293
      scene, then add the problem query.  You are encouraged to
 
294
      minimize the size of your example, but this is not absolutely
 
295
      necessary.  If the bug is reproducible, we will find it either
 
296
      way.
 
297
     </P
 
298
><P
 
299
>      If your application uses some other client interface, such as <SPAN
 
300
CLASS="APPLICATION"
 
301
>PHP</SPAN
 
302
>, then
 
303
      please try to isolate the offending queries. We will probably not set up a
 
304
      web server to reproduce your problem. In any case remember to provide
 
305
      the exact input files; do not guess that the problem happens for
 
306
      <SPAN
 
307
CLASS="QUOTE"
 
308
>"large files"</SPAN
 
309
> or <SPAN
 
310
CLASS="QUOTE"
 
311
>"midsize databases"</SPAN
 
312
>, etc. since this
 
313
      information is too inexact to be of use.
 
314
     </P
 
315
></LI
 
316
><LI
 
317
><P
 
318
>      The output you got. Please do not say that it <SPAN
 
319
CLASS="QUOTE"
 
320
>"didn't work"</SPAN
 
321
> or
 
322
      <SPAN
 
323
CLASS="QUOTE"
 
324
>"crashed"</SPAN
 
325
>. If there is an error message,
 
326
      show it, even if you do not understand it. If the program terminates with
 
327
      an operating system error, say which. If nothing at all happens, say so.
 
328
      Even if the result of your test case is a program crash or otherwise obvious
 
329
      it might not happen on our platform. The easiest thing is to copy the output
 
330
      from the terminal, if possible.
 
331
     </P
 
332
><DIV
 
333
CLASS="NOTE"
 
334
><BLOCKQUOTE
 
335
CLASS="NOTE"
 
336
><P
 
337
><B
 
338
>Note: </B
 
339
>       If you are reporting an error message, please obtain the most verbose
 
340
       form of the message.  In <SPAN
 
341
CLASS="APPLICATION"
 
342
>psql</SPAN
 
343
>, say <TT
 
344
CLASS="LITERAL"
 
345
>\set
 
346
       VERBOSITY verbose</TT
 
347
> beforehand.  If you are extracting the message
 
348
       from the server log, set the run-time parameter
 
349
       <A
 
350
HREF="runtime-config-logging.html#GUC-LOG-ERROR-VERBOSITY"
 
351
>log_error_verbosity</A
 
352
> to <TT
 
353
CLASS="LITERAL"
 
354
>verbose</TT
 
355
> so that all
 
356
       details are logged.
 
357
      </P
 
358
></BLOCKQUOTE
 
359
></DIV
 
360
><DIV
 
361
CLASS="NOTE"
 
362
><BLOCKQUOTE
 
363
CLASS="NOTE"
 
364
><P
 
365
><B
 
366
>Note: </B
 
367
>       In case of fatal errors, the error message reported by the client might
 
368
       not contain all the information available. Please also look at the
 
369
       log output of the database server. If you do not keep your server's log
 
370
       output, this would be a good time to start doing so.
 
371
      </P
 
372
></BLOCKQUOTE
 
373
></DIV
 
374
></LI
 
375
><LI
 
376
><P
 
377
>      The output you expected is very important to state. If you just write
 
378
      <SPAN
 
379
CLASS="QUOTE"
 
380
>"This command gives me that output."</SPAN
 
381
> or <SPAN
 
382
CLASS="QUOTE"
 
383
>"This is not
 
384
      what I expected."</SPAN
 
385
>, we might run it ourselves, scan the output, and
 
386
      think it looks OK and is exactly what we expected. We should not have to
 
387
      spend the time to decode the exact semantics behind your commands.
 
388
      Especially refrain from merely saying that <SPAN
 
389
CLASS="QUOTE"
 
390
>"This is not what SQL says/Oracle
 
391
      does."</SPAN
 
392
> Digging out the correct behavior from <ACRONYM
 
393
CLASS="ACRONYM"
 
394
>SQL</ACRONYM
 
395
>
 
396
      is not a fun undertaking, nor do we all know how all the other relational
 
397
      databases out there behave. (If your problem is a program crash, you can
 
398
      obviously omit this item.)
 
399
     </P
 
400
></LI
 
401
><LI
 
402
><P
 
403
>      Any command line options and other start-up options, including
 
404
      any relevant environment variables or configuration files that
 
405
      you changed from the default. Again, please provide exact
 
406
      information. If you are using a prepackaged distribution that
 
407
      starts the database server at boot time, you should try to find
 
408
      out how that is done.
 
409
     </P
 
410
></LI
 
411
><LI
 
412
><P
 
413
>      Anything you did at all differently from the installation
 
414
      instructions.
 
415
     </P
 
416
></LI
 
417
><LI
 
418
><P
 
419
>      The <SPAN
 
420
CLASS="PRODUCTNAME"
 
421
>PostgreSQL</SPAN
 
422
> version. You can run the command
 
423
      <TT
 
424
CLASS="LITERAL"
 
425
>SELECT version();</TT
 
426
> to
 
427
      find out the version of the server you are connected to.  Most executable
 
428
      programs also support a <TT
 
429
CLASS="OPTION"
 
430
>--version</TT
 
431
> option; at least
 
432
      <TT
 
433
CLASS="LITERAL"
 
434
>postgres --version</TT
 
435
> and <TT
 
436
CLASS="LITERAL"
 
437
>psql --version</TT
 
438
>
 
439
      should work.
 
440
      If the function or the options do not exist then your version is
 
441
      more than old enough to warrant an upgrade.
 
442
      If you run a prepackaged version, such as RPMs, say so, including any
 
443
      subversion the package might have. If you are talking about a Git
 
444
      snapshot, mention that, including the commit hash.
 
445
     </P
 
446
><P
 
447
>      If your version is older than 9.1beta1 we will almost certainly
 
448
      tell you to upgrade. There are many bug fixes and improvements
 
449
      in each new release, so it is quite possible that a bug you have
 
450
      encountered in an older release of <SPAN
 
451
CLASS="PRODUCTNAME"
 
452
>PostgreSQL</SPAN
 
453
>
 
454
      has already been fixed. We can only provide limited support for
 
455
      sites using older releases of <SPAN
 
456
CLASS="PRODUCTNAME"
 
457
>PostgreSQL</SPAN
 
458
>; if you
 
459
      require more than we can provide, consider acquiring a
 
460
      commercial support contract.
 
461
     </P
 
462
><P
 
463
>     </P
 
464
></LI
 
465
><LI
 
466
><P
 
467
>      Platform information. This includes the kernel name and version,
 
468
      C library, processor, memory information, and so on. In most
 
469
      cases it is sufficient to report the vendor and version, but do
 
470
      not assume everyone knows what exactly <SPAN
 
471
CLASS="QUOTE"
 
472
>"Debian"</SPAN
 
473
>
 
474
      contains or that everyone runs on i386s. If you have
 
475
      installation problems then information about the toolchain on
 
476
      your machine (compiler, <SPAN
 
477
CLASS="APPLICATION"
 
478
>make</SPAN
 
479
>, and so
 
480
      on) is also necessary.
 
481
     </P
 
482
></LI
 
483
></UL
 
484
><P>
 
485
 
 
486
   Do not be afraid if your bug report becomes rather lengthy. That is a fact of life.
 
487
   It is better to report everything the first time than us having to squeeze the
 
488
   facts out of you. On the other hand, if your input files are huge, it is
 
489
   fair to ask first whether somebody is interested in looking into it.  Here is
 
490
   an <A
 
491
HREF="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html"
 
492
TARGET="_top"
 
493
>article</A
 
494
>
 
495
   that outlines some more tips on reporting bugs.
 
496
  </P
 
497
><P
 
498
>   Do not spend all your time to figure out which changes in the input make
 
499
   the problem go away. This will probably not help solving it. If it turns
 
500
   out that the bug cannot be fixed right away, you will still have time to
 
501
   find and share your work-around. Also, once again, do not waste your time
 
502
   guessing why the bug exists. We will find that out soon enough.
 
503
  </P
 
504
><P
 
505
>   When writing a bug report, please avoid confusing terminology.
 
506
   The software package in total is called <SPAN
 
507
CLASS="QUOTE"
 
508
>"PostgreSQL"</SPAN
 
509
>,
 
510
   sometimes <SPAN
 
511
CLASS="QUOTE"
 
512
>"Postgres"</SPAN
 
513
> for short. If you
 
514
   are specifically talking about the backend process, mention that, do not
 
515
   just say <SPAN
 
516
CLASS="QUOTE"
 
517
>"PostgreSQL crashes"</SPAN
 
518
>.  A crash of a single
 
519
   backend process is quite different from crash of the parent
 
520
   <SPAN
 
521
CLASS="QUOTE"
 
522
>"postgres"</SPAN
 
523
> process; please don't say <SPAN
 
524
CLASS="QUOTE"
 
525
>"the server
 
526
   crashed"</SPAN
 
527
> when you mean a single backend process went down, nor vice versa.
 
528
   Also, client programs such as the interactive frontend <SPAN
 
529
CLASS="QUOTE"
 
530
>"<SPAN
 
531
CLASS="APPLICATION"
 
532
>psql</SPAN
 
533
>"</SPAN
 
534
>
 
535
   are completely separate from the backend.  Please try to be specific
 
536
   about whether the problem is on the client or server side.
 
537
  </P
 
538
></DIV
 
539
><DIV
 
540
CLASS="SECT2"
 
541
><H2
 
542
CLASS="SECT2"
 
543
><A
 
544
NAME="AEN354"
 
545
>Where to Report Bugs</A
 
546
></H2
 
547
><P
 
548
>   In general, send bug reports to the bug report mailing list at
 
549
   <CODE
 
550
CLASS="EMAIL"
 
551
>&#60;<A
 
552
HREF="mailto:pgsql-bugs@postgresql.org"
 
553
>pgsql-bugs@postgresql.org</A
 
554
>&#62;</CODE
 
555
>.
 
556
   You are requested to use a descriptive subject for your email
 
557
   message, perhaps parts of the error message.
 
558
  </P
 
559
><P
 
560
>   Another method is to fill in the bug report web-form available
 
561
   at the project's
 
562
   <A
 
563
HREF="http://www.postgresql.org/"
 
564
TARGET="_top"
 
565
>web site</A
 
566
>.
 
567
   Entering a bug report this way causes it to be mailed to the
 
568
   <CODE
 
569
CLASS="EMAIL"
 
570
>&#60;<A
 
571
HREF="mailto:pgsql-bugs@postgresql.org"
 
572
>pgsql-bugs@postgresql.org</A
 
573
>&#62;</CODE
 
574
> mailing list.
 
575
  </P
 
576
><P
 
577
>   If your bug report has security implications and you'd prefer that it
 
578
   not become immediately visible in public archives, don't send it to
 
579
   <TT
 
580
CLASS="LITERAL"
 
581
>pgsql-bugs</TT
 
582
>.  Security issues can be
 
583
   reported privately to <CODE
 
584
CLASS="EMAIL"
 
585
>&#60;<A
 
586
HREF="mailto:security@postgresql.org"
 
587
>security@postgresql.org</A
 
588
>&#62;</CODE
 
589
>.
 
590
  </P
 
591
><P
 
592
>   Do not send bug reports to any of the user mailing lists, such as
 
593
   <CODE
 
594
CLASS="EMAIL"
 
595
>&#60;<A
 
596
HREF="mailto:pgsql-sql@postgresql.org"
 
597
>pgsql-sql@postgresql.org</A
 
598
>&#62;</CODE
 
599
> or
 
600
   <CODE
 
601
CLASS="EMAIL"
 
602
>&#60;<A
 
603
HREF="mailto:pgsql-general@postgresql.org"
 
604
>pgsql-general@postgresql.org</A
 
605
>&#62;</CODE
 
606
>.
 
607
   These mailing lists are for answering
 
608
   user questions, and their subscribers normally do not wish to receive
 
609
   bug reports. More importantly, they are unlikely to fix them.
 
610
  </P
 
611
><P
 
612
>   Also, please do <SPAN
 
613
CLASS="emphasis"
 
614
><I
 
615
CLASS="EMPHASIS"
 
616
>not</I
 
617
></SPAN
 
618
> send reports to
 
619
   the developers' mailing list <CODE
 
620
CLASS="EMAIL"
 
621
>&#60;<A
 
622
HREF="mailto:pgsql-hackers@postgresql.org"
 
623
>pgsql-hackers@postgresql.org</A
 
624
>&#62;</CODE
 
625
>.
 
626
   This list is for discussing the
 
627
   development of <SPAN
 
628
CLASS="PRODUCTNAME"
 
629
>PostgreSQL</SPAN
 
630
>, and it would be nice
 
631
   if we could keep the bug reports separate. We might choose to take up a
 
632
   discussion about your bug report on <TT
 
633
CLASS="LITERAL"
 
634
>pgsql-hackers</TT
 
635
>,
 
636
   if the problem needs more review.
 
637
  </P
 
638
><P
 
639
>   If you have a problem with the documentation, the best place to report it
 
640
   is the documentation mailing list <CODE
 
641
CLASS="EMAIL"
 
642
>&#60;<A
 
643
HREF="mailto:pgsql-docs@postgresql.org"
 
644
>pgsql-docs@postgresql.org</A
 
645
>&#62;</CODE
 
646
>.
 
647
   Please be specific about what part of the documentation you are unhappy
 
648
   with.
 
649
  </P
 
650
><P
 
651
>   If your bug is a portability problem on a non-supported platform,
 
652
   send mail to <CODE
 
653
CLASS="EMAIL"
 
654
>&#60;<A
 
655
HREF="mailto:pgsql-hackers@postgresql.org"
 
656
>pgsql-hackers@postgresql.org</A
 
657
>&#62;</CODE
 
658
>,
 
659
   so we (and you) can work on
 
660
   porting <SPAN
 
661
CLASS="PRODUCTNAME"
 
662
>PostgreSQL</SPAN
 
663
> to your platform.
 
664
  </P
 
665
><DIV
 
666
CLASS="NOTE"
 
667
><BLOCKQUOTE
 
668
CLASS="NOTE"
 
669
><P
 
670
><B
 
671
>Note: </B
 
672
>    Due to the unfortunate amount of spam going around, all of the above
 
673
    email addresses are closed mailing lists. That is, you need to be
 
674
    subscribed to a list to be allowed to post on it.  (You need not be
 
675
    subscribed to use the bug-report web form, however.)
 
676
    If you would like to send mail but do not want to receive list traffic,
 
677
    you can subscribe and set your subscription option to <TT
 
678
CLASS="LITERAL"
 
679
>nomail</TT
 
680
>.
 
681
    For more information send mail to
 
682
    <CODE
 
683
CLASS="EMAIL"
 
684
>&#60;<A
 
685
HREF="mailto:majordomo@postgresql.org"
 
686
>majordomo@postgresql.org</A
 
687
>&#62;</CODE
 
688
>
 
689
    with the single word <TT
 
690
CLASS="LITERAL"
 
691
>help</TT
 
692
> in the body of the message.
 
693
   </P
 
694
></BLOCKQUOTE
 
695
></DIV
 
696
></DIV
 
697
></DIV
 
698
><DIV
 
699
CLASS="NAVFOOTER"
 
700
><HR
 
701
ALIGN="LEFT"
 
702
WIDTH="100%"><TABLE
 
703
SUMMARY="Footer navigation table"
 
704
WIDTH="100%"
 
705
BORDER="0"
 
706
CELLPADDING="0"
 
707
CELLSPACING="0"
 
708
><TR
 
709
><TD
 
710
WIDTH="33%"
 
711
ALIGN="left"
 
712
VALIGN="top"
 
713
><A
 
714
HREF="resources.html"
 
715
ACCESSKEY="P"
 
716
>Prev</A
 
717
></TD
 
718
><TD
 
719
WIDTH="34%"
 
720
ALIGN="center"
 
721
VALIGN="top"
 
722
><A
 
723
HREF="index.html"
 
724
ACCESSKEY="H"
 
725
>Home</A
 
726
></TD
 
727
><TD
 
728
WIDTH="33%"
 
729
ALIGN="right"
 
730
VALIGN="top"
 
731
><A
 
732
HREF="tutorial.html"
 
733
ACCESSKEY="N"
 
734
>Next</A
 
735
></TD
 
736
></TR
 
737
><TR
 
738
><TD
 
739
WIDTH="33%"
 
740
ALIGN="left"
 
741
VALIGN="top"
 
742
>Further Information</TD
 
743
><TD
 
744
WIDTH="34%"
 
745
ALIGN="center"
 
746
VALIGN="top"
 
747
><A
 
748
HREF="preface.html"
 
749
ACCESSKEY="U"
 
750
>Up</A
 
751
></TD
 
752
><TD
 
753
WIDTH="33%"
 
754
ALIGN="right"
 
755
VALIGN="top"
 
756
>Tutorial</TD
 
757
></TR
 
758
></TABLE
 
759
></DIV
 
760
></BODY
 
761
></HTML
 
762
>
 
 
b'\\ No newline at end of file'