[HACKERS] Ad Hoc Indexes

Question: We have recently moved PostgreSql as we just migrated to OpenMfg. i really like the database and PL/pgSQL its very similar to how FoxPro language layout so learning has been pretty easy. Now for my question It does not appear PostgreSQL does not have an Ad Hoc Indexes ability where

Re: [HACKERS] Ad Hoc Indexes

think creating Ad Hoc indexes on the fly in memory makes sense . I imagine it would be even faster if the index stayed in memory Tom Lane wrote: Justin <[EMAIL PROTECTED]> writes: Is there any plans in the future to add the ability for PostgreSQL to create Ad Hoc indexes if it makes sense

Re: [HACKERS] Ad Hoc Indexes

created from a website or other business analysis tool that someone might create Tom Lane wrote: Justin <[EMAIL PROTECTED]> writes: The idea of ad hoc indexes is speed up loop scans To prove my idea i created a sql file in PGAdmin that creates the indexes on the fly then runs the

Re: [HACKERS] Ad Hoc Indexes

oops dam spell checker really should be rarely sorry Justin wrote: Then why are the estimates so far off??? If estimates where correct would it improve the performance that much. Vaccum is set to run automatically so the stats stay update. Total record count for the tables for all the

Re: [HACKERS] Ad Hoc Indexes

correct number by allot. Stephen Denne wrote: Justin wrote: Then why are the estimates so far off? Perhaps a really high correlation between those records where coitem_status = 'O' and those records in your date range. The planner estimates 1 row when restricting by both re

Re: [HACKERS] Ad Hoc Indexes

there are certainly problems with this idea. Figuring out the cost to either create an index or just do table scan would be pain but not impossible. The hit to index a table in memory i don't think would be that bad compare to do 100's to thousands of loops with table scans. I see more opti

[HACKERS] creating new aggregate function

Need help and direction creating new aggregate functions. We need to add more average functions for both scientific and finical purposes RMS for electrical measurement purposes Mode for both electrical and finical Weighted Average finical purposes Generalized mean for electrical measurement

[HACKERS] transaction support in pl/slql

i have a request ?? Is there any intension of expanding Transaction support into PL/SQL. this would simplify GUI/client code to know the if a function failed it roll back the transaction. right now i have to pass back some kind error message that i look for to see if the transaction fail

Re: [HACKERS] [PERFORM] Memory question on win32 systems

Sabbiolina wrote: On Thu, May 29, 2008 at 2:11 AM, Douglas McNaught <[EMAIL PROTECTED] > wrote: On Wed, May 28, 2008 at 7:05 PM, Sabbiolina <[EMAIL PROTECTED] > wrote: > Hello, in my particular case I need to configure Postgres t

Re: [HACKERS] [PERFORM] Memory question on win32 systems

Merlin Moncure wrote: On Thu, May 29, 2008 at 10:19 AM, Justin <[EMAIL PROTECTED]> wrote: To my understanding Postgresql only caches queries and results in memory for that specific connection. So when that connection is closed those cached results are cleared out.So cached inde

[HACKERS] math error or rounding problem Money type

I believe i have found a math bug/rounding problem with Money type when its used with SUM()... Postgresql 8.3.1 --- Background on the Problem We have gl_trans table with 92,000 rows with one column containing the positive and negative entries. In order to mak

Re: [HACKERS] math error or rounding problem Money type

Tom Lane wrote: Justin <[EMAIL PROTECTED]> writes: I believe i have found a math bug/rounding problem with Money type when its used with SUM()... Postgresql 8.3.1 You do know that money only stores two fractional digits? regards, tom lane yes

Re: [HACKERS] [GENERAL] string_to_array with empty input

Sam Mason wrote: I'd expect 3,2,1 and 1. That's also a disingenuous example; what would you expect back from: select count_elements(string_to_array('butter,,milk',',')) I think the semantics you want is what you'd get from: array_filter_blanks(string_to_array($1,$2)) where I defined "arr

Re: [HACKERS] [GENERAL] string_to_array with empty input

Sam Mason wrote: string_to_array('',',')::INT[] => invalid input syntax for integer: "" Which you don't get at the moment; although you do currently get it in other common cases such as: string_to_array('1,',',')::INT[] If you want backwards compatible behaviour you could always bung a N

Re: [HACKERS] [GENERAL] string_to_array with empty input

Greg Stark wrote: On Tue, Mar 31, 2009 at 5:48 PM, justin wrote: But consider  this fails also select string_to_array('1, , 3', ',' )::int[] => ERROR:  invalid input syntax for integer: " " yet this works select string_to_array('1, 2, 3&

Re: [HACKERS] [GENERAL] string_to_array with empty input

This thread being cross posted has made it a bit confusing Greg Stark wrote: Nobody has ever suggested filtering out empty elements or dealing specially with spaces or anything else like that. If you're talking about that then you've missed the original question. "Does anyone want t

Re: [HACKERS] [GENERAL] string_to_array with empty input

Tom Lane wrote: Robert Haas writes: On Tue, Mar 31, 2009 at 10:44 AM, Greg Stark wrote: On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason wrote: string_to_array('',',')::INT[]  => invalid input syntax for integer: "" Oof. That

Re: [HACKERS] [GENERAL] string_to_array with empty input

If someone can show me a real world example this logic simplifies the code and has more uses I'll bite I just presently can't see how this works better. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpr

Re: [HACKERS] [GENERAL] string_to_array with empty input

Martin Gainty wrote: Split strings into array elements using provided delimiter string_to_array('xx~^~yy~^~zz', '~^~') output: {xx,yy,zz} http://www.postgresql.org/docs/8.3/interactive/functions-array.html Sorry thats not the question i'm asking.  We are debating if it makes

Re: [HACKERS] [GENERAL] string_to_array with empty input

Steve Crawford wrote: Did I miss the exciting conclusion or did this drift silently off radar? it was pretty well split between the options. tabled for another time. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgr

Re: [HACKERS] windows doesn't notice backend death

Tom Lane wrote: Have M$ really been stupid enough to make an external kill look just like an exit() call? regards, tom lane kind of :-( Everything i have read seems to point the Task Manager calls TerminateProcess() in the kernel32.dll and passes a 1 setting the exitcode to 1.  I

Re: [HACKERS] windows doesn't notice backend death

Andrew Dunstan wrote: justin wrote: Would it not be easy to set the normal exitcode to something other than 1 to see the difference ExitProcess() Not really, as Tom showed later this is an example of a more general problem. I think his solution of detecting when backends have cleaned

[HACKERS] SIGSEGV in BRIN autosummarize

ot;heads up" to early adopters until/in case it happens again and I can at least provide a stack trace. Justin -- 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] SIGSEGV in BRIN autosummarize

On Fri, Oct 13, 2017 at 10:57:32PM -0500, Justin Pryzby wrote: > I don't have any reason to believe there's memory issue on the server, So I > suppose this is just a "heads up" to early adopters until/in case it happens > again and I can at least provide a stack trac

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Fri, Oct 13, 2017 at 10:57:32PM -0500, Justin Pryzby wrote: > > Also notice the vacuum process was interrupted, same as yesterday (think > > goodness for full logs). Our INSERT script is using python > > multiprocessing.pool() with "maxtasksperchild=1", which I thin

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Sat, Oct 14, 2017 at 08:56:56PM -0500, Justin Pryzby wrote: > On Fri, Oct 13, 2017 at 10:57:32PM -0500, Justin Pryzby wrote: > > > Also notice the vacuum process was interrupted, same as yesterday (think > > > goodness for full logs). Our INSERT s

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Sun, Oct 15, 2017 at 02:44:58PM +0200, Tomas Vondra wrote: > Thanks, but I'm not sure that'll help, at this point. We already know > what happened (corrupted memory), we don't know "how". And core files > are mostly just "snapshots" so are not very useful in answering that :-( Is there anything

Re: [HACKERS] SIGSEGV in BRIN autosummarize

postgres tarball, apply the patch, and run the compiled postgres binary from the source tree, without running make install or similar ? Otherwise, would it be good enough to copy the postgres binary to /usr/pgsql-10/bin (and reinstall the binary package later) ? Thanks, Justin -- Sent via pgsql

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Tue, Oct 17, 2017 at 12:59:16PM +0200, Alvaro Herrera wrote: > Justin Pryzby wrote: > > > #1 0x006a52e9 in perform_work_item (workitem=0x7f8ad1f94824) at > > autovacuum.c:2676 > > cur_datname = 0x298c740 "no 1 :vartype 1184 :vartypmod -1 &g

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Tue, Oct 17, 2017 at 09:34:24AM -0400, Tom Lane wrote: > Justin Pryzby writes: > > On Tue, Oct 17, 2017 at 12:59:16PM +0200, Alvaro Herrera wrote: > >> Anyway, can give this patch a try? > > > I've only compiled postgres once before and this is a production en

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Tue, Oct 17, 2017 at 09:07:40AM -0500, Justin Pryzby wrote: > On Tue, Oct 17, 2017 at 09:34:24AM -0400, Tom Lane wrote: > > Justin Pryzby writes: > > > On Tue, Oct 17, 2017 at 12:59:16PM +0200, Alvaro Herrera wrote: > > >> Anyway, can give this patch a try? >

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Wed, Oct 18, 2017 at 06:54:09PM +0200, Alvaro Herrera wrote: > Justin Pryzby wrote: > > > No crashes in ~28hr. It occurs to me that it's a weaker test due to not > > preserving most compilation options. > > And the previous code crashes in 45 minutes? That&

Re: [HACKERS] SIGSEGV in BRIN autosummarize

_database; 13456 | template0 16400 | gtt 13457 | postgres 1 | template1 The gtt DB is where the (only) BRIN indicies are (not sure what to conclude from that?) Justin -- 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] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy

cess 6725, UID 26, (postmaster) total-vm:13544792kB, anon-rss:8977764kB, file-rss:8kB So I'm hoping to encourage someone to commit the change contemplated earlier. Thanks in advance. Justin On Tue, Jul 18, 2017 at 07:26:30PM -0400, Tom Lane wrote: > Justin Pryzby writes: > > I've see

[HACKERS] per-sesson errors after interrupting CLUSTER pg_attrdef

This was briefly scary but seems to have been limited to my psql session (no other errors logged). Issue with catcache (?) I realized that the backup job I'd kicked off was precluding the CLUSTER from running, but that CLUSTER was still holding lock and stalling everything else under the sun. ps

[HACKERS] unique index violation after pg_upgrade to PG10

8f84f2ba7c00Tag:0x:01f0 CDBLen: 6 CDB: 0x1201... SN: 0x0 SENT, FAILED Oct 22 21:28:17 midrivers-ubuntu kernel: [1429371.269974] hpsa :05:00.0: scsi 4:0:0:0: FAILED to abort command RAID HP P410i controller SSDSmartPathCap- En- Exp=1

Re: [HACKERS] unique index violation after pg_upgrade to PG10

On Tue, Oct 24, 2017 at 01:27:14PM -0500, Kenneth Marshall wrote: > On Tue, Oct 24, 2017 at 01:14:53PM -0500, Justin Pryzby wrote: > > Note: > > I run a script which does various combinations of ANALYZE/VACUUM > > (FULL/ANALYZE) > > following the upgrade, and a scrip

Re: [HACKERS] unique index violation after pg_upgrade to PG10

early show that our application INSERTed > >> rows > >> which are duplicates. > >> > >> [pryzbyj@database ~]$ rpm -qa pg_repack10 > >> pg_repack10-1.4.2-1.rhel6.x86_64 > >> > >> Justin > > > > Hi Justin, > > > > I jus

Re: [HACKERS] unique index violation after pg_upgrade to PG10

ugh a duplicate row > existed. Then the next pg_repack would fail with the error you got. FTR, I was able to run the repack script several times without issue, hitting that table each time. Justin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to y

Re: [HACKERS] unique index violation after pg_upgrade to PG10

On Tue, Oct 24, 2017 at 02:57:47PM -0700, Peter Geoghegan wrote: > On Tue, Oct 24, 2017 at 1:11 PM, Justin Pryzby wrote: > > ..which I gather just verifies that the index is corrupt, not sure if > > there's > > anything else to do with it? Note, we've already

Re: [HACKERS] unique index violation after pg_upgrade to PG10

On Tue, Oct 24, 2017 at 02:57:47PM -0700, Peter Geoghegan wrote: > On Tue, Oct 24, 2017 at 1:11 PM, Justin Pryzby wrote: > > ..which I gather just verifies that the index is corrupt, not sure if > > there's > > anything else to do with it? Note, we've already

[HACKERS] tupconvert.c API change in v10 release notes

rt.c. (So, | let's remember to mention it in the v10 release notes.) ..but couldn't see that the commit or change is so referenced. Justin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] PG10b2: column-list UPDATE syntax fails with single column

g it), but wondered if it was intentional or otherwise if the release notes should mention that old syntax is no longer accepted. Either way - thanks in advance. Justin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.post

Re: [HACKERS] Possible issue with expanded object infrastructure on Postgres 9.6.1

getting to the bottom of this and for your support. Even if it missed the 9.6.4 release, I'm very grateful for your help. We haven't had much of an issue since disabling parallel workers so nothing is harmed by waiting a little longer. Thanks, Justin

[HACKERS] memory fields from getrusage()

.. is that really (still) the case for supported platforms? I'm hoping that in 2017 one can just call getrusage() if autoconf says it's okay ?? Justin -- 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] memory fields from getrusage()

;!\t%ld max resident, %ld shared, %ld unshared data, %ld unshared stack (kB)\n", r.ru_maxrss, r.ru_ixrss, r.ru_idrss, r.ru_isrss); #elif defined(__darwin__) appendStringInfo(&str, "!\t%ld max resident, %ld shared, %ld unshared data, %ld unshared stack (kB)\n", r.ru_maxrs

Re: [HACKERS] memory fields from getrusage()

On Thu, Jun 15, 2017 at 10:29:21AM -0400, Robert Haas wrote: > On Wed, Jun 14, 2017 at 6:28 PM, Justin Pryzby wrote: > > On Tue, Jun 13, 2017 at 12:16:00PM -0400, Robert Haas wrote: > >> It might be worth adding platform-specific code for common platforms. > > > > A

Re: [HACKERS] memory fields from getrusage()

On Sat, Sep 02, 2017 at 02:00:44PM +1200, Thomas Munro wrote: > On Sat, Sep 2, 2017 at 7:46 AM, Peter Eisentraut > wrote: > > On 6/15/17 10:58, Justin Pryzby wrote: > >> On Thu, Jun 15, 2017 at 10:29:21AM -0400, Robert Haas wrote: > >>> On Wed, Jun 14, 2017 at 6:2

[HACKERS] pg9.4 relpages of child tables

relpages from pg_class where relname='t2'; => 443 Is that a deliberate change, and if so, is there any documentation of it? I'd prefer to avoid analyzing all our child tables, as all queries hit the parents, which include statistics on the children. Thanks, Justin -- Sent

Re: [HACKERS] pg9.4 relpages of child tables

On Wed, Mar 18, 2015 at 12:11:22PM -0400, Tom Lane wrote: > Justin Pryzby writes: > > I believe there's been a behavior change, and not sure if it's deliberate. > > I > > don't think there's a negative consequence for our production use, but it &

[HACKERS] smallint out of range EXECUTEing prepared statement

(32768); (0 rows) Note, we also sometimes get small/int out of range when SELECTing from a view, and we end up as a workaround putting a ::big/int cast into the view or multiplying by 1. Thanks, Justin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Possible issue with expanded object infrastructure on Postgres 9.6.1

irst > step anyway, just to narrow down where the problem lies. > regards, tom lane Hi Tom, My name is Justin, and I am $customer as it were. As Peter explained, we haven't seen the segfaults anymore since disabling parallel queries. This works as a quick fix and is much appreciated! If yo

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

27;ve seen this at least 4 times now, on PG95 and 9.6; 3 of those times are for the above table. Any ideas what I can do to either reproduce it or otherwise avoid it ? On Wed, Oct 12, 2016 at 10:25:05AM -0500, Justin Pryzby wrote: > We've seen this happen at least once on a 9.5 server, and

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

On Wed, Oct 12, 2016 at 10:25:05AM -0500, Justin Pryzby wrote: > > I don't have a clear recollection how I solved this in July; possibly by > > restoring the (historic, partition) table from backup. > > > > Last week again again just now (both under 9.6), a col

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

impossible to get into this state from a fresh initdb from a current version. I considered that perhaps it only affected our oldest tables, and would stop happening once they were dropped, but note this ALTER is only of a parent and its 3 most recent children. So only the empty parent could be describe

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

On Tue, Jan 03, 2017 at 01:40:50PM -0500, Robert Haas wrote: > On Tue, Jan 3, 2017 at 11:59 AM, Justin Pryzby wrote: > > On Tue, Jan 03, 2017 at 11:45:33AM -0500, Robert Haas wrote: > >> > ts=# begin; drop view umts_eric_ch_switch_view, > >>

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

On Tue, Jan 03, 2017 at 02:32:36PM -0500, Tom Lane wrote: > Justin Pryzby writes: > >>>> I can cause the error at will on the existing table, > > That's good news, at least. > > 1. Please trigger it with "\set VERBOSITY verbose" enabled, so we can se

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

| integer | not null | plain| 200 | pmcelldowntimeauto | smallint | | plain| 10 | pmcelldowntimeman | smallint | | plain| 10

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

On Tue, Jan 03, 2017 at 02:50:21PM -0500, Tom Lane wrote: > Justin Pryzby writes: > > On Tue, Jan 03, 2017 at 02:32:36PM -0500, Tom Lane wrote: > >> 2. Even better would be a stack trace for the call to errfinish, > >> https

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

On Tue, Jan 03, 2017 at 03:18:15PM -0500, Tom Lane wrote: > Justin Pryzby writes: > > (gdb) bt > > #3 0x0059d5ce in ATRewriteTable (tab=, > > OIDNewHeap=, lockmode=) at > > tablecmds.c:4152 > > I'm wondering if this represents some sort of out-of-

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

On Tue, Jan 03, 2017 at 03:35:34PM -0500, Tom Lane wrote: > Justin Pryzby writes: > > On Tue, Jan 03, 2017 at 03:18:15PM -0500, Tom Lane wrote: > >> I'm wondering if this represents some sort of out-of-sync condition > >> between the table and its child tabl

[HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

opefully we can get it all done without giving users a reason to consider switching. ;) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 12 Apr 2016, at 14:12, Yury Zhuravlev wrote: > Justin Clift wrote: >> Simon included a short starter list of potentials which might be in >> that category: >> >> * SQL compliant identifiers >> * Remove RULEs >> * Change recovery.conf >>

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 12 Apr 2016, at 17:23, Merlin Moncure wrote: > On Mon, Apr 11, 2016 at 11:39 AM, Justin Clift wrote: >> Moving over a conversation from the pgsql-advocacy mailing list. In it >> Simon (CC'd) raised the issue of potentially creating a >> backwards-compatibility &

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

yers to control/ruin the project. > > And, most importantly, we've been lucky that a lot of competing projects > have self-immolated instead of being successful and brain-draining our > contributors (MySQL, ANTS, MonetDB, etc.) Oracle buying MySQL (via Sun) seems to have helped things

Re: [HACKERS] Odd behavior with domains

: > > So this came across my twitter feed: > > https://pbs.twimg.com/media/ClqIJtmXEAA5IGt.png > > public.text can exist in parallel with pg_catalog.text. > > It just doesn't seem right to me to be able to do: CREATE DOMAIN int AS varchar(50); Justin

[HACKERS] ruby connect

I'm trying to connect ruby to postgres on ubuntu and the only link I found that has the library is down. Does anyone have the postgres library for ruby? Or direct me to it? Justin Darby Carrera Database Programmer/Analyst MED-Department of Medical Social Sciences j-carr...@northwester

Re: [HACKERS] Places to update when a new version is out

Hi Chris, I don't have time at the moment to start making the needed document. :( Does anyone want to throw together the basics of it and put it somewhere useful? :-) Regards and best wishes, Justin Clift Christopher Kings-Lynne wrote: > > I remember someone mentioning on th

Re: [HACKERS] Index Scans become Seq Scans after VACUUM ANALYSE

planning the best query every time. I didn't say it was gunna be soon, nor easy though. + Justin > - Thomas > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.post

Re: [HACKERS] Index Scans become Seq Scans after VACUUM ANALYSE

sm for doing that. Ok. I see what you mean now. That makes more sense. :) + Justin >- Thomas -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was

Re: [HACKERS] new food for the contrib/ directory

Hi Bruce, Haven't looked at the code, but there's no license with it. Andreas, are you cool with having the same License as PostgreSQL for it (BSD license)? :-) Regards and best wishes, Justin Clift Bruce Momjian wrote: > > Can someone comment on this?

Re: [HACKERS] new food for the contrib/ directory

Hi Bruce, Did we reach an opinion as to whether we'll include GPL'd code? My vote is to not include this code, as it just muddies the water with PostgreSQL being BSD based. :-) Regards and best wishes, Justin Clift Andreas Scherbaum wrote: > > Justin Clift wrote:

Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports

generate mingwin code too. :-) Regards and best wishes, Justin Clift "Marc G. Fournier" wrote: > > On Fri, 3 May 2002, mlw wrote: > > > "Marc G. Fournier" wrote: > > > > > > Morning all ... > > > > > > Just a heads

Re: [HACKERS] Native Windows, Apache Portable Runtime

e (i.e. there may already be a way of splitting it off easy, etc), but we'll never know if we don't say hello. (Hey, that rhymes!) :-) Regards and best wishes, Justin Clift > It looks like the APR is pretty analogous to SysV with a few changes, so it > sho

Re: [HACKERS] pgAdmin2 to be included in Dev-C++

just so PostgreSQL could be included in the "Database Foundry" on the Sourceforge site. :) http://www.sf.net/projects/pgsql And then I started a new contract and haven't had time to do anything with it (oh well). Regards and best wishes, Justin Clift > > "R

Re: [HACKERS] Postgres idea list

ussion areas. > Perhaps pgsql-promotion would be a good name that'd avoid the aura of > flamewars. Or maybe that's just my own perception not anyone else's. There is already a pgsql-advocacy list (as was pointed out recently), but it's unused. Borrow a leaf from the Ope

Re: [HACKERS] Nextgres?

Hi everyone, This is Jonah's explanation of what Nextgres is, as his response didn't make it to the list (some kind of software or network problem). :-) Regards and best wishes, Justin Clift Original Message Subject: Re: [HACKERS] Nextgres? Date: Wed, 26 Jun 200

Re: [HACKERS] TPC-* Benchmarks

nd if you have suggestions regarding the publishing of benchmarks, this is probably the place they will be implemented. Hope this helps. :-) Regards and best wishes, Justin Clift Paul Ramsey wrote: > > Have any organizations run TPC benchmarks against PostgreSQL other than > the old and

Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:

Hi Florian, Is it possible to crash a 7.2.1 backend without having an entry in the pg_hba.conf file? i.e. Is every PostgreSQL 7.2.1 installation around vulnerable to a remote DoS (or worse) from any user anywhere, at this moment in time? Regards and best wishes, Justin Clift Florian Weimer

Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:

for weird characters and formatting hacks) on the date given, then use the date as part of a SQL query, and PostgreSQL will die? ? Regards and best wishes, Justin Clift Florian Weimer wrote: > > Justin Clift <[EMAIL PROTECTED]> writes: > > > Is it possible to crash a

Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:

malicious types. Regards and best wishes, Justin Clift Florian Weimer wrote: > > Justin Clift <[EMAIL PROTECTED]> writes: > > > - A PostgreSQL 7.2.1 server can be crashed if it gets passed certain > > date values which would be accepted by standard "front end"

Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:

egards and best wishes, Justin Clift > Chris -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi -

[HACKERS] Interesting message about printf()'s in PostgreSQL

and of PostgreSQL needing an audit. Any idea if the things mentioned in this are true? :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group;

[HACKERS] Finally, a list of *big* companies using PostgreSQL for *serious* projects. Why use PostgreSQL? Here's why.

gabyte, billion-record-plus business information database. I'm pretty sure everyone will appreciate the significance of these companies showing their support. :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who wo

[HACKERS] About to update the PostgreSQL Functions in the official PHP Manual

e included, etc? :-) Regards and best wishes, Justin Clift Original Message Subject: [GENERAL] About to update the PostgreSQL-Functions in the PHP Manual Date: Sun, 18 Aug 2002 13:32:21 +0200 From: "Cornelia Boenigk" <[EMAIL PROTECTED]> Hi everyone, I am in the

Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

Hi Vince, Glad he made the advisory for something there's a fix for. :) Regards and best wishes, Justin Clift Vince Vielhaber wrote: > > Surprised it took this long. > > Vince. > -- > == >

Re: [HACKERS] [SECURITY] DoS attack on backend possible

Hi Florian, You guys *definitely* write scarey code. :-( Regards and best wishes, Justin Clift Florian Weimer wrote: > > Alvar Freude <[EMAIL PROTECTED]> writes: > > >> What about checking the input for backslash, quote, > >> and double quote (\'&q

Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

Vince, Do you reckon it's worth you responding to "Sir Mordred" and pointing out that he overstated the vulnerability? :-) Regards and best wishes, Justin Clift Tom Lane wrote: > > Justin Clift <[EMAIL PROTECTED]> writes: > > Glad he made the advisor

Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

Christopher Kings-Lynne wrote: > > > On Tue, 20 Aug 2002, Justin Clift wrote: > > > > > Vince, > > > > > > Do you reckon it's worth you responding to "Sir Mordred" and pointing > > > out that he overstated the vulnerability?

Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

Tom Lane wrote: > > Justin Clift <[EMAIL PROTECTED]> writes: > > From the info still around, this looks to mean that the cash_words() > > problem was fixed, but the cash_out() problem was harder to fix. > > > Tom/Bruce, is that correct? > > The cash_out

Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

Tom Lane wrote: > > Justin Clift <[EMAIL PROTECTED]> writes: > > Hang on, you seem to be suggesting we release a major new upgrade, with > > major new functionality, knowing it contains a way to trivially crash > > the backend. > > This particular hole has be

Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

example, yet a large number of them probably wouldn't be so comfortable having PostgreSQL available for their clients whilst knowing that these kinds of DOS bugs exists. Mentally, it's not a good thing. Not trying to be a pain here, but instead trying to keep our QA level up. :) Regards

[HACKERS] Multiple vulnerabilities in PostgreSQL

vulnerabilities with some decent amount of time in advance so we can create the necessary patches/fixes, etc? :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be

[HACKERS] [Fwd: Re: Multiple vulnerabilities in PostgreSQL]

Hi guys, Sir Mordred seems okay, and is happy to help us out as long as we give him credit where it's due. Can't see where that would be a problem with anyone here, as it's totally in line with how we work, so am going to say yes to him up front. :-) Regards and best wishes

Re: [HACKERS] Multiple vulnerabilities in PostgreSQL

e people in our community are the decent up-front kind of folk, and we welcome your assistance and expertise in helping us find the vulnerabilities in PostgreSQL. So, yep, it's all cool with us. :-) Regards and best wishes, Justin Clift Sir Mordred The Traitor wrote: > > Hi Justi

Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in

w more backward incompatibility in regards > to functions/opaque, should we open some discussion on 7.3 really being > 8.0? Depending on how far back we push this, we might be able to get Windows Native support added. That'd be cool and probably contribute to an 8.0. :) Regards and

Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in

pe I'm not pushing too strongly for this, as, after all, I can't do the coding needed here. :( Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to t

Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in

Bruce Momjian wrote: > > Justin Clift wrote: > > Only two things which have the potential to be worth waiting for, from > > what I'm aware of. There may be others: > > > > - Find out from Sir Mordred if he wants to take a look at the CVS > >version

Re: Release of v7.2.2 (Was: Re: [HACKERS] @(#)Mordred Labs ad...)

that will need to be applied to the 7.2.x branch. :-) Regards and best wishes, Justin Clift Oleg Bartunov wrote: > > Tom, > > I think it's worth to include patch for query planner which > fixes using indices with predicates for join plans. We found it's > quite use

Re: [HACKERS] Wanted: pgdiff ($$$)

Hi all, Just a link to this from the front page of the techdocs.postgresql.org site. Hope it helps. :-) Regards and best wishes, Justin Clift Greg Stark wrote: > > [EMAIL PROTECTED] (ad wolf) writes: > > > We're offering a small reward for a PG hacker that can cod

  1   2   3   4   5   >