Thread: Open items
Here are the open items. They all have to be addressed before final,
but not all before beta starts.
---------------------------------------------------------------------------
P O S T G R E S Q L
7 . 5 O P E N I T E M S
Current at ftp://momjian.postgresql.org/pub/postgresql/open_items.
Changes
-------
win32 binary version stamps
server logging process (?)
pg_autovacuum integration (in queue)
pg_dump fixes (in queue)
win32 signal safe socket handler
win32 query cancel in psql (?)
fix dbsize and oid2name for tablespaces
allow libpq to check parameterized data types
fix Win32 pg_dumpall version check
make pgxs install the default
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Here are the open items. They all have to be addressed before final,
> but not all before beta starts.
> P O S T G R E S Q L
> 7 . 5 O P E N I T E M S
Well, we could start with s/7.5/8.0/ ...
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Here are the open items. They all have to be addressed before final, > > but not all before beta starts. > > > P O S T G R E S Q L > > 7 . 5 O P E N I T E M S > > Well, we could start with s/7.5/8.0/ ... Done. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
>>> Does anyone have any more? > >> win32 signal safe socket handler > >I thought that was solved long ago? If this is what I think it is (Merlin - please confirm), this relates to the SSL code only. And the issue is that there are (I think - haven't 100% verified it yet) paths in the SSL code that will block withou it being possible to deliver signals. The end result would be a query you can't cancel/backend you can't kill. The non-SSL codepaths emulate blocking sockets using non-blocking ones that also listen on signals. This has not been done for SSL sockets yet. //Magnus
Magnus Hagander wrote:
> >>> Does anyone have any more?
> >
> >> win32 signal safe socket handler
> >
> >I thought that was solved long ago?
>
> If this is what I think it is (Merlin - please confirm), this relates to
> the SSL code only. And the issue is that there are (I think - haven't
> 100% verified it yet) paths in the SSL code that will block withou it
> being possible to deliver signals. The end result would be a query you
> can't cancel/backend you can't kill.
OK, I added an SSL mention:
o fix signal safe socket handler for SSL
>
> The non-SSL codepaths emulate blocking sockets using non-blocking ones
> that also listen on signals. This has not been done for SSL sockets yet.
OK.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
Sorry for the late reply, missed your initial response. > "Merlin Moncure" <merlin.moncure@rcsonline.com> writes: > >> Does anyone have any more? > > > win32 signal safe socket handler > > I thought that was solved long ago? As magnus wrote, we need to confirm that ssl sockets don't block singals while waiting or they will not execute signals until a query runs. > > win32 query cancel in psql (?) > > What's the issue here? Win32 ctrl-c handler runs in a separate thread which ultimately calls TerminateProcess(). Problem is does an immediate kill which does not send the cancel signal to the backend. The solution is to install a custom ctrl-c handler (in fact a patch was submitted to do this) which fires the appropriate signal. However, this code runs a separate thread...the original patch (by Luf) was rejected because it did not address thread safety issues. Merlin
Magnus Hagander wrote: > >> win32 binary version stamps > > > >Magnus has just gone on holiday for a couple of weeks but > >before he left > >he did tell me he'd submitted what was hopefully the final patch for > >this. I haven't seen it yet though - is it stuck in the queue? > > I did, and I thought I saw it come through, but that could be me just > accidentallyi CCing myself. Here it is again. > > IIRC there was discussion about the location of the files (Peter I think > it was suggesting creating a new directory - I'll happily leave that > part up to an eventual committer). > > Another discussion was about binary files in the tree (not being source > files - the source is a binary .AI file (AFAIK that's Adobe > Illustrator)). The question was raised wether ImageMagick could do this > conversion - it can't. Doesn't support AI. Also, it would introduce yet > another build dependency in order to create a single file. I don't see > much other way than stuffing the icon in there (possibly along with the > .AI file if you'd need to change it manually). It is, after all, just a > resource and not code. These binary files are almost never going to be changed so I see no problem with adding them to CVS, and putting whatever source we can into CVS. If we can't we just document how we created the binary. Can you export the image to tiff format or something so we can modify it laster if we need to, or perhaps gimp format? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Wed, Aug 18, 2004 at 10:12:53PM -0400, Bruce Momjian wrote: > These binary files are almost never going to be changed so I see no > problem with adding them to CVS, and putting whatever source we can into > CVS. If we can't we just document how we created the binary. Can you > export the image to tiff format or something so we can modify it laster > if we need to, or perhaps gimp format? It would be even better if some vector format could be produced that some open source tool could process to generate a bitmap. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "In Europe they call me Niklaus Wirth; in the US they call me Nickel's worth. That's because in Europe they call me by name, and in the US by value!"
On Wed, Aug 18, 2004 at 10:12:53PM -0400, Bruce Momjian wrote: > Magnus Hagander wrote: > > > > Another discussion was about binary files in the tree (not being source > > files - the source is a binary .AI file (AFAIK that's Adobe > > Illustrator)). The question was raised wether ImageMagick could do this > > conversion - it can't. Doesn't support AI. Also, it would introduce yet > > another build dependency in order to create a single file. I don't see > > much other way than stuffing the icon in there (possibly along with the > > .AI file if you'd need to change it manually). It is, after all, just a > > resource and not code. > > These binary files are almost never going to be changed so I see no > problem with adding them to CVS, and putting whatever source we can into > CVS. If we can't we just document how we created the binary. Can you > export the image to tiff format or something so we can modify it laster > if we need to, or perhaps gimp format? Actually, you'll find that Adobe Illustrator AI files are not a 'binary' file at all: they're a particular flavor of PostScript. In fact, I just used the pstoedit tool to convert this particular one (the PostgreSQL elephant head logo) into an xfig file, then from there back to postscript. It's not ideal: apparently, Illustrator and Xfig have slightly different spline curve implementations, so the lines get a bit bumpy after the pass through xfig. So, it's not really a set of tools I'd recommend to attempt to automate the 'build some icons' step: that still takes an artist. However, the AI file _is_ an editable source doc. I've hand hacked Postscript in the past. I'd recommend keeping it in CVS, along side the hand-build icons. If someone wants to hack on icons at some later date, the AI/postscript file is a useful starting point (preferred, actually: it's vector). Eventually, an SVG doc will probably be the way to go. Further investigation show that pstoedit can use GNU libplot to generate _lots_ of different formats, including SVG and fig, via a different path. From _that_ fig file, xfig can generate a postscript file that renders _identically_ to the AI file. So, the AI is a useful source. Ross -- Ross Reedstrom, Ph.D. reedstrm@rice.edu Research Scientist phone: 713-348-6166 The Connexions Project http://cnx.rice.edu fax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE
>> IIRC there was discussion about the location of the files >(Peter I think >> it was suggesting creating a new directory - I'll happily leave that >> part up to an eventual committer). >> >> Another discussion was about binary files in the tree (not >being source >> files - the source is a binary .AI file (AFAIK that's Adobe >> Illustrator)). The question was raised wether ImageMagick >could do this >> conversion - it can't. Doesn't support AI. Also, it would >introduce yet >> another build dependency in order to create a single file. I >don't see >> much other way than stuffing the icon in there (possibly >along with the >> .AI file if you'd need to change it manually). It is, after >all, just a >> resource and not code. > >These binary files are almost never going to be changed so I see no >problem with adding them to CVS, and putting whatever source >we can into >CVS. If we can't we just document how we created the binary. Can you >export the image to tiff format or something so we can modify it laster >if we need to, or perhaps gimp format? The AI format *is* a source, and pretty much any professional vector-graph-capable program will deal with it. You definitly don't want to go TIFF, because TIFF is not vector based. AI is the source, ICO is the derived binary. As for documentation on how to generate it, I'm not a graphics guy, but this is what Gavin said: >I took the ai file, reduced it to the right sizes in photoshop and >used an icon editor to make it at various resolutions. If that's not enough, I'm sure he can add something more on how it was done. (The AI file is available for download from http://pgsql.gavinroy.com/art/, where I got the ICO) //Magnus