Sunday, July 6, 2008

Re: [GENERAL] roll back to 8.1 for PyQt driver work-around

Sorry to drag this on further. Though I'm now able to start pg8.3
again (thanks!), I still can't launch pg8.1. Rolling back to 8.1 is
my goal in order to work around a driver issue in Qt.

Is there an example postgresql.conf file for pg 8.1 I can review?
Mine appears to be valid only for pg8.3.

Adding quotes to the shared_buffers value allows pg8.3 to start
successfully. Unfortunately, pg8.1 continues to have issues with it.
eg:


FATAL: syntax error in file "/Library/PostgreSQL8/data/
postgresql.conf" line 107, near token "kB"
FATAL: parameter "shared_buffers" requires an integer value
FATAL: unrecognized configuration parameter
"default_text_search_config"

Thanks again!
Scott


On Jul 6, 2008, at 10:48 AM, Tom Lane wrote:

> Scott Frankel <frankel@circlesfx.com> writes:
>> When I try to start 8.3, the log file lists a fatal error in the
>> postgresql.conf file. But there are no obvious errors in that file.
>> Line 107 reads: "shared_buffers = 1600kB".
>
> You need quotes, like
> shared_buffers = '1600kB'
>
>> FATAL: incorrect checksum in control file
>
> This looks like a version compatibility problem, though I'm surprised
> it wasn't complained of earlier.
>
> regards, tom lane
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Scott Frankel
President/VFX Supervisor
Circle-S Studios
510-339-7477 (o)
510-332-2990 (c)

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [sydpug] crash in psql unixodbc driver

2008/7/7 Charles Duffy <charles.duffy@gmail.com>:
> On Fri, Jul 4, 2008 at 8:50 PM, Amos Shapira <amos.shapira@gmail.com> wrote:
>
>>
>> We are having troubles with unixodbc postgresql driver on CentOS 5
>> x86_64 on a Xen DomU.
>>
>> Here is a sample program which demonstrates the problem:
>>
>
> If I get a bit of free time later today, I'll try and reproduce your
> problem here. In the meantime, I recommend you post on one of the main
> postgresql lists with your problem, if you haven't already. Be sure to
> include an actual description of the issue, rather than just some
> source for a program which exhibits it. Also include exact versions
> for every piece of software involved (postgres, odbc driver, etc).

Thanks for the advise. I'll try to provide more complete details if we
can't solve it.

>
> There is a specific postgresql-ODBC list, but there's very little
> traffic on it. You might be better off posting on -general...

I subscribed and posted there but haven't heard anything back.

In the meantime, we had some progress with a friend I contacted
outside the list.

Cheers,

--Amos

--
Sent via sydpug mailing list (sydpug@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/sydpug

Re: [GENERAL] Quick way to alter a column type?

is there any quick hacks to do this quickly? There's around 20-30million
rows of data.

I want to change a column type from varchar(4) to varchar(5) or should I
just use text instead.

ALTER TABLE tablename ALTER COLUMN columnname TYPE VARCHAR(5);

HTH.

-
Eric

Re: [BUGS] error ' Client encoding Mismatch' with Version 8.1.4

Hi all,

I tried to look into the problem, still unable to solve the problem.

Problem details:

We have a custom application which installs Postgres 8.1.4. It provides option for selection of encoding.

Below is the line which does the same based on the encoding selection:

"

msiexec /i postgresql-8.1-int.msi /qn -l  %LogFile% ADDLOCAL=server,psql,pgadmin INTERNALLAUNCH=1 DOSERVICE=1 DOINITDB=1 SERVICEDOMAIN="%COMPUTERNAME%" SERVICEACCOUNT="postgres" SERVICEPASSWORD="Password1*2*3"  SUPERPASSWORD="postgres" CREATESERVICEUSER=1 ENCODING=%Lang% LISTENPORT=7432 PERMITREMOTE=1 NOSHORTCUTS=1 BASEDIR=%JM_ROOT_WIN%\StdyDb DATADIR=%JM_ROOT_WIN%\StdyDb\data

"

Where “Lang” is the selection done by user.

 

I changed it to ENCODING=”UTF8” installation in UTF8 format.

 

I installed the Postgres 8.1.4 version with UTF8 as encoding. This works properly when my regional settings are Japanese but the same installation fails as soon as I change my regional settings to Greek. When I try to connect to the database with Greek regional settings it throws the error "Client Encoding mismatch".

 

I feel there is some setting done at the installation time which makes it work correctly in Japanese regional language settings only. Hence it fails when I change them to Greek.

What can be the cause for this behavior? Do I need to change some settings on cygwin or pgaccess side at installation time?

I even tried changing the encoding for database to Unicode still the same error. (createdb –E UTF8 Xyz)

 

 

Note:-

I have even tried with direct installation of Postgres version 8.1.4. It behaves in the same way as our Custom installer is behaving. It seems there is problem in the version 8.1.4 itself.

Tom,

I think the error is thrown from the Postgres side only. I am getting the same error while working with direct installer of Postgres. I get this error with Greek and Thai regional language settings, not with Japanese.

 

Please help me on the same.

 

 

 

Regards,

Ashutosh

 

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Thursday, June 26, 2008 8:29 PM
To: Ashutosh Kumar S-TLS,Chennai
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] error ' Client encoding Mismatch' with Version 8.1.4

 

"Ashutosh Kumar S-TLS,Chennai" <ashutoshks@hcl.in> writes:

> Problem is whenever I am trying to open the database through ODBC

> connection it throws an error 'Client encoding mismatch'.

 

That phrase occurs noplace in Postgres 8.1, so the error must be coming

from something on the client side.  We can't really help you here ---

you need to find out which bit of software is throwing the error and

ask its authors what is the cause.

 

                  regards, tom lane

[ANNOUNCE] == PostgreSQL Weekly News - July 06 2008 ==

== PostgreSQL Weekly News - July 06 2008 ==

The July CommitFest has begun. Start reviewing :)
http://wiki.postgresql.org/wiki/CommitFest:2008-07

== PostgreSQL Product News ==

MicroOLAP Database Designer 1.2.4 for PostgreSQL released.
http://microolap.com/products/database/postgresql-designer/

== PostgreSQL Jobs for July ==

http://archives.postgresql.org/pgsql-jobs/2008-07/threads.php

== PostgreSQL Local ==

pgDay Portland is July 20, just before OSCON.
http://pugs.postgresql.org/node/400

PGCon Brazil 2008 will be on September 26-27 at Unicamp in Campinas.
http://pgcon.postgresql.org.br/index.en.html

PGDay.IT 2008 will be October 17 and 18 in Prato.
http://www.pgday.org/it/

== PostgreSQL in the News ==

Planet PostgreSQL: http://www.planetpostgresql.org/

General Bits, Archives and occasional new articles:
http://www.varlena.com/GeneralBits/

PostgreSQL Weekly News is brought to you this week by David Fetter.

Submit news and announcements by Sunday at 3:00pm Pacific time.
Please send English language ones to david@fetter.org, German language
to pwn@pgug.de, Italian language to pwn@itpug.org.

== Applied Patches ==

Heikki Linnakangas committed:

- Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size.
As the buffer could now be a lot larger than before, and copying it
could thus be a lot more expensive than before, use strcpy instead
of memcpy to copy the query string, as was already suggested in
comments. Also, only copy the PgBackendStatus struct and string if
the slot is in use. Patch by Thomas Lee, with some changes by me.

- Extend VacAttrStats to allow typanalyze functions to store statistic
values of different types than the underlying column. The capability
isn't yet used for anything, but will be required by upcoming patch
to analyze tsvector columns. Jan Urbanski

- In pgsql/src/bin/pg_dump/pg_dump.c, move volatility, language, etc.
modifiers before function body in the pg_dump output for CREATE
FUNCTION. This makes it easier to read especially if the function
body is long. Original idea and patch by Greg Sabino Mullane,
though this is a stripped down version of that.

Teodor Sigaev committed:

- ltree support for multibyte encodings. Patch was made by Weiping
(laser) He, with some editorization by me.

- In pgsql/src/backend/access/gin/ginscan.c, fix initialization of
GinScanEntryData.partialMatch

Bruce Momjian committed:

- Add psql TODO item: "Add option to wrap column values at whitespace
boundaries, rather than chopping them at a fixed width. Currently,
'wrapped' format chops values into fixed widths. Perhaps the word
wrapping could use the same algorithm documented in the W3C
specification."

- Add psql TODO item: "Add 'auto' expanded mode that outputs in
expanded format if "wrapped" mode can't wrap the output to the
screen width."

- Fix recovery.conf boolean variables to take the same range of string
values as postgresql.conf.

- Issue psql connection warnings on connection start and via \c, per
observation by David Fetter.

- Add to TODO: "Fix TRUNCATE ... RESTART IDENTITY so its affect on
sequences is rolled back on transaction abort."

- Add URL for TODO: "Add database and transaction-level triggers."

- In pgsql/doc/src/sgml/config.sgml, documentation patch by Kevin L.
McBride explaining GUC lock variables, which are available if
LOCK_DEBUG is defined.

- In pgsql/src/include/c.h, update source code comment about when to
use gettext_noop().

Tom Lane committed:

- Teach autovacuum how to determine whether a temp table belongs to a
crashed backend. If so, send a LOG message to the postmaster log,
and if the table is beyond the vacuum-for-wraparound horizon,
forcibly drop it. Per recent discussions. Perhaps we ought to
back-patch this, but it probably needs to age a bit in HEAD first.

- In pgsql/src/timezone/pgtz.c, fix identify_system_timezone() so that
it tests the behavior of the system timezone setting in the current
year and for 100 years back, rather than always examining years
1904-2004. The original coding would have problems distinguishing
zones whose behavior diverged only after 2004; which is a situation
we will surely face sometime, if it's not out there already. In
passing, also prevent selection of the dummy "Factory" timezone,
even if that's exactly what the system is using. Reporting time as
GMT seems better than that.

- In pgsql/src/backend/utils/misc/guc.c, remove GUC extra_desc strings
that are redundant with the enum value lists.

- In pgsql/src/backend/utils/adt/xml.c, fix transaction-lifespan
memory leak in xpath(). Report by Matt Magoffin, fix by Kris Jurka.

- Fix psql's \d and allied commands to work with all server versions
back to 7.4. Guillaume Lelarge, with some additional fixes by me.

- Add a function pg_get_keywords() to let clients find out the set of
keywords known to the SQL parser. Dave Page

- In pgsql/src/backend/utils/misc/guc.c, prevent integer overflows
during units conversion when displaying a GUC variable that has
units. Per report from Stefan Kaltenbrunner. Backport to 8.2. I
also backported my patch of 2007-06-21 that prevented comparable
overflows on the input side, since that now seems to have enough
field track record to be back-patched safely. That patch included
addition of hints listing the available unit names, which I did not
bother to strip out of it --- this will make a little more work for
the translators, but they can copy the translation from 8.3, and
anyway an untranslated hint is better than no hint.

Magnus Hagander committed:

- In pgsql/src/backend/utils/misc/guc.c, split apart message_level_options
into one set for server-side settings and one for client-side,
restoring the previous behaviour with different sort order for the
'log' level. Also, remove redundant list of available options, since
the enum code will output it automatically.

- In pgsql/src/backend/utils/misc/guc.c, "debug" level was supposed to
be hidden, since it's just an alias for debug2.

- In pgsql/src/backend/port/win32_shmem.c, fix a couple of bugs in
win32 shmem name generation: 1. Don't cut off the prefix. With this
fix, it's again readable. 2. Properly store it in the Global
namespace as intended.

Joe Conway committed:

- When an ERROR happens on a dblink remote connection, take pains to
pass the ERROR message components locally, including using the
passed SQLSTATE. Also wrap the passed info in an appropriate
CONTEXT message. Addresses complaint by Henry Combrinck. Joe
Conway, with much good advice from Tom Lane.

Peter Eisentraut committed:

- In pgsql/src/test/regress/expected/prepare.out, clean up weird
whitespace. Separate patch to simplifiy the next change.

- Don't print the name of the database in psql \z.

- Don't refer to the database name "regression" inside the regression
test scripts, to allow running the test successfully with another
database name.

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Simon Riggs sent in a patch which introduces a distinction between
hint bit setting and block dirtying, when such a distinction can
safely be made.

Simon Riggs sent in a patch which adds planner statistic hooks.

Tom Raney sent in another revision of his patch to allow EXPLAIN to
output XML.

Peter Eisentraut sent in a patch to let people set the name of the
regression test database on the command line.

Teodor Sigaev sent in revisions to the multicolumn and fast-insert
patches to GIN.

Dean Rasheed sent in a patch to add a debug_explain_plan GUC variable
which, when set to on, dumps the output of EXPLAIN ANALYZE to the
appropriate logging level.

Zdenek Kotala sent in three more revisions of his page macros cleanup
patch.

Garick Hamlin sent in a patch to support ident authentication when
using unix domain sockets on Solaris.

Simon Riggs sent in a bug fix for pg_standby per note from Ferenc
Felhoffer.

Simon Riggs sent in two revisions of a patch to document the
toggliness of certain psql commands.

Simon Riggs sent in a patch to pgbench which restricts vacuuming to
pgbench tables and changes a DELETE/VACUUM to a TRUNCATE.


---------------------------(end of broadcast)---------------------------
-To unsubscribe from this list, send an email to:

pgsql-announce-unsubscribe@postgresql.org

[GENERAL] Quick way to alter a column type?

Is there any quick hacks to do this quickly? There's around 20-30million
rows of data.

I want to change a column type from varchar(4) to varchar(5) or should I
just use text instead.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] postgresql's MVCC implementation

Tom Lane-2 wrote:
>
> It's not defined by the SQL standard, nor any other standard that I know
> of. So yes, different implementations might mean subtly different
> things by it.
>

OK, I see. Where can I find out the precise meaning of MVCC as in
PostgreSQL. I've read

http://www.postgresql.org/docs/8.3/interactive/transaction-iso.html
and wondering if there is any more detailed description.

Thanks!

-----
--
Kent Tong
Wicket tutorials freely available at http://www.agileskills2.org/EWDW
Axis2 tutorials freely available at http://www.agileskills2.org/DWSAA
--
View this message in context: http://www.nabble.com/postgresql%27s-MVCC-implementation-tp18302020p18309553.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] postgresql's MVCC implementation

Kent Tong <kent@cpttm.org.mo> writes:
> Is MVCC not well defined?

It's not defined by the SQL standard, nor any other standard that I know
of. So yes, different implementations might mean subtly different
things by it.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] postgresql's MVCC implementation

Tom Lane-2 wrote:
>
> If you want that to fail, use a SELECT FOR UPDATE at steps 3/4.
>
> My interpretation of MVCC is that the above example isn't even
> meaningful, because it assumes that "writing into Y" is an overwrite,
> which it is not in Postgres --- that is, if T2 reads Y again, it'll
> get the same value as before.
>

Hi Tom,

Thanks for your reply. I think what I'd like to know is the exact meaning
of MVCC as implemented in PostgreSQL. It seems that a transaction
(with isolation set to serializable) will always read the values as if they
were when the transaction started.

If it is the case, why? Is MVCC not well defined? Could say Oracle or MS
SQL implement it differently?

-----
--
Kent Tong
Wicket tutorials freely available at http://www.agileskills2.org/EWDW
Axis2 tutorials freely available at http://www.agileskills2.org/DWSAA
--
View this message in context: http://www.nabble.com/postgresql%27s-MVCC-implementation-tp18302020p18309342.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgsql-es-ayuda] DATESTYLE

El día 5 de julio de 2008 14:27, Noel Martínez Juárez
<noelius79@hotmail.com> escribió:
> Fabio, te refieres al tipo de dato? me podrías explicar, gracias...

>> Porke no manejas el formato con to_char o to_date?

>> 2008/7/4, Noel Martínez Juárez <noelius79@hotmail.com>:
>> > Buenas noches, he intentado cambiar el formato de la fecha en
>> > postgresql, a
>> > día-mes-año, pero el PG-ADMIN no me muestra dicho cambio, la variable
>> > que
>> > modifico es DATESTYLE, gracias.NOEL

Amigo, se refiere, al formateado de las columnas de tipo date a la
hora de mostrarlas, date una vuelta por la ayuda en:

http://www.postgresql.org/docs/8.3/interactive/runtime-config-client.html
http://www.postgresql.org/docs/8.3/interactive/functions-formatting.html
http://www.postgresql.org/docs/8.3/interactive/datatype-datetime.html

Y si quieres materiales en español busca en el archivo de la lista en:
http://archives.postgresql.org/pgsql-es-ayuda/

Ahi si ya te debo la busqueda, porque ya hablamos de este tema
muuuuchas veces. ;)

Espero que te sirva, un abrazo,
--
§~^Calabaza^~§ from Villa Elisa, Paraguay
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

http://archives.postgresql.org/pgsql-es-ayuda

Re: [sydpug] crash in psql unixodbc driver

On Fri, Jul 4, 2008 at 8:50 PM, Amos Shapira <amos.shapira@gmail.com> wrote:

>
> We are having troubles with unixodbc postgresql driver on CentOS 5
> x86_64 on a Xen DomU.
>
> Here is a sample program which demonstrates the problem:
>

If I get a bit of free time later today, I'll try and reproduce your
problem here. In the meantime, I recommend you post on one of the main
postgresql lists with your problem, if you haven't already. Be sure to
include an actual description of the issue, rather than just some
source for a program which exhibits it. Also include exact versions
for every piece of software involved (postgres, odbc driver, etc).

There is a specific postgresql-ODBC list, but there's very little
traffic on it. You might be better off posting on -general...

Thanks,

Charles Duffy

--
Sent via sydpug mailing list (sydpug@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/sydpug

Re: [GENERAL] creating "a perfect sequence" column

On Sun, Jul 6, 2008 at 7:33 PM, Berend Tober <btober@ct.metrocast.net> wrote:
> Jack Brown wrote:
>>
>> Dear list,
>>
>> I need some tips and/or pointers to relevant documentation implementing
>> (what I chose to call) "a perfect sequence" i.e. a sequence that has no
>> missing numbers in the sequence. I'd like it to auto increment on insert,
>> and auto decrement everything bigger than its value on delete. There are
>> many mechanisms (rules, triggers, sequences, locks etc.) but I'm not sure
>> which combination would result in the most elegant implementation.
>>
>> Oh, and if you know the right term for what I just described, I'd be more
>> than pleased to hear it! :-)
>>
>
> This question comes up a lot. A term used in prior discussions is "gapless
> sequence".
>
> What would be really more interesting for discussion on this community forum
> is a detailed description or your actual use case and requirements.

I will say that if you need a gapless serial numbering system it's
still better to NOT try and do it with a pre-checked out number. For
instance, you might have a system like a court document system that
might have this requirement, that you hace CR-1 through CR-99999999 or
whatever.

In that case it's better to let the user start work, then hit CREATE
DOCUMENT when they're ready. Then your business logic can put the
data into the database, and if it goes in, then check out a number
from the sequence. I.e. there are no deletes, only failed inserts. A
system that requires you to show a number before the document has been
"created" in the system but wants no gaps is flawed. Don't give them
a number until they HAVE a document. reusing numbers already shown to
a user is a recipe for a disaster. they write down the number, and
two weeks later reference it, but it's not there.

That's one use case. It's important here to look for the way that is
less likely to lead to "oh crap!" moments.

Adding gapless sequences increases the complexity. Better to let the
complexity only live in a display layer of sorts than to rely on it
for FK-PK type stuff.

If there's any FK->PK relations involving these keys and they aren't
fully cascaded, then allowing them to be renumbered is courting
disaster. If you use a separate table for "user visible sequence
number" and store the plain sequence, gaps and all in the db, then
your actual core data is safer. You can recreate the user visible
sequence number table without affecting the actual relationship of the
data in the real data table.

I hope I'm not rambling too much.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[HACKERS] pg_ctl -w with postgresql.conf in non-default path

Hello guys,

This is my first post to this list..

I'm using PostgreSQL8.3.3 and I moved postgresql.conf to the
outside of DATA direcotory, and invoked postgres via pg_ctl
as following.

pg_ctl -w -D /data -o '--config-file=/home/hirano/postgresql.conf' start

This seems to work well, but when I changed the port parameter in
that postgresql.conf, pg_ctl waits for timeout by "-w" option.
In this case, postgres correctly listens the port I wrote in
config, but pg_ctl checkes the port in the data/postgresql.conf
file.

I think this is because the path to postgresql.conf is hard-coded
in the pg_ctl.c

| snprintf(conf_file, MAXPGPATH, "%s/postgresql.conf", pg_data);

But actually there're no descriptions of --config-file option in the
manual of postgres command, although I'm not sure how I could
find it...

Is it bad way to use --config-file option or pg_ctl bug?

Regards.

--
HIRANO Yoshitaka


--
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] [PATCHES] WIP: executor_hook for pg_stat_statements

Simon Riggs <simon@2ndquadrant.com> wrote:

> > The attached patch (executor_hook.patch) modifies HEAD as follows.
> >
> > - Add "tag" field (uint32) into PlannedStmt.
> > - Add executor_hook to replace ExecutePlan().
> > - Move ExecutePlan() to a global function.
>
> The executor_hook.patch is fairly trivial and I see no errors.
>
> The logic of including such a patch is clear. If we have a planner hook
> then we should also have an executor hook.

One issue is "tag" field. The type is now uint32. It's enough in my plugin,
but if some people need to add more complex structures in PlannedStmt,
Node type would be better rather than uint32. Which is better?


> Will you be completing the plugin for use in contrib?

Yes, I'll fix memory management in my plugin and re-post it
by the next commit-fest.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-es-ayuda] Problema con caractere en un select

2008/7/4 Marcos Saldivar <baron.rojo.cuerdas.de.acero@gmail.com>:
> El día 4 de julio de 2008 17:21, Fernando Siguenza <fsigu@hotmail.com> escribió:
>>
>> Amigos yo nuevamente espero me puedan dar una mano ota ves muchas gracias a
>> todos los que me han ayudado hasta el momento
>> ahora tengo otro inconveniente, quiero realizar un select a la base de
>> datos.
>> tengo un campo de tipo cod varchar(3) y otro nom varchar(20) lo que quiero
>> hacer es esto
>> select * from tabla where cod like '%' or nom like '%' para que me retorne
>> todos los valores.
>
> quieres saber si cod o nom contiene el string "%" ???

O sea, te falta lo que va a variar en tu where:

select * from tabla
where cod like '%tupalabraabuscar%' or nom like '%tupalabraabuscar%'

Algo así verdad?

Ahora, sobre el error que te da, puede que sea otra cosa también, si
lo anterior no funciona, puedes probar lo siguiente:

select * from tabla
where cod::char like '%tupalabraabuscar%' or nom::char like
'%tupalabraabuscar%'

Date una vuelta por:
http://www.postgresql.org/docs/8.3/interactive/errcodes-appendix.html

Ahi explica algo sobre el error que tienes;

Un Abrazo,
--
§~^Calabaza^~§ from Villa Elisa, Paraguay
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

Re: [GENERAL] creating "a perfect sequence" column

Jack Brown wrote:
> Dear list,
>
> I need some tips and/or pointers to relevant documentation implementing (what I chose to call) "a perfect sequence" i.e. a sequence that has no missing numbers in the sequence. I'd like it to auto increment on insert, and auto decrement everything bigger than its value on delete. There are many mechanisms (rules, triggers, sequences, locks etc.) but I'm not sure which combination would result in the most elegant implementation.
>
> Oh, and if you know the right term for what I just described, I'd be more than pleased to hear it! :-)
>

This question comes up a lot. A term used in prior discussions is
"gapless sequence".

What would be really more interesting for discussion on this
community forum is a detailed description or your actual use case
and requirements.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] Sorting writes during checkpoint

(Go back to -hackers)

Simon Riggs <simon@2ndquadrant.com> wrote:

> No action on this seen since last commitfest, but I think we should do
> something with it, rather than just ignore it.

I will have a plan to test it on RAID-5 disks, where sequential writing
are much better than random writing. I'll send the result as an evidence.

Also, I have a relevant idea to sorting writes. Smoothed checkpoint in 8.3
spreads write(), but calls fsync() at once. With sorted writes, we can
call fsync() segment-by-segment for each writes of dirty pages contained
in the segment. It could improve worst response time during checkpoints.

> Note that if we do this for checkpoint we should also do this for
> FlushRelationBuffers(), used during heap_sync(), for exactly the same
> reasons.

Ah, I overlooked FlushRelationBuffers(). It is worth sorting.

> Would suggest calling it bulk_io_hook() or similar.

I think we need to reconsider the "bufmgr - smgr - md" layers, not only
an I/O elevator hook. If we will have spreading fsync(), bufmgr should
know where the file segments are switched. It seems to break area
between bufmgr and md in the current architecture unhappily.

In addition, the current smgr layer is completely useless because
it cannot be extended dynamically and cannot handle multiple md-layer
modules. I would rather merge current smgr and part of bufmgr into
a new smgr and add smgr_hook() than bulk_io_hook().

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] creating "a perfect sequence" column

On Sun, Jul 6, 2008 at 6:15 PM, Jack Brown <zidibik@yahoo.com> wrote:
> Dear list,
>
> I need some tips and/or pointers to relevant documentation implementing (what I chose to call) "a perfect sequence" i.e. a sequence that has no missing numbers in the sequence. I'd like it to auto increment on insert, and auto decrement everything bigger than its value on delete. There are many mechanisms (rules, triggers, sequences, locks etc.) but I'm not sure which combination would result in the most elegant implementation.

This would actually be a perfectly awful sequence. :) Seriously,
it's costly to lock the whole table, set the sequence to the last
available value and lock it in terms of concurrency.

>
> Oh, and if you know the right term for what I just described, I'd be more than pleased to hear it! :-)

I believe it's called a "How to destroy concurrency" or something like that.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] creating "a perfect sequence" column

Dear list,

I need some tips and/or pointers to relevant documentation implementing (what I chose to call) "a perfect sequence" i.e. a sequence that has no missing numbers in the sequence. I'd like it to auto increment on insert, and auto decrement everything bigger than its value on delete. There are many mechanisms (rules, triggers, sequences, locks etc.) but I'm not sure which combination would result in the most elegant implementation.

Oh, and if you know the right term for what I just described, I'd be more than pleased to hear it! :-)

All the best,
Jack

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[HACKERS] Priority of timezone names vs abbreviations in AT TIME ZONE

I've been thinking about the complaint here:
http://archives.postgresql.org/pgsql-general/2008-07/msg00201.php
and I think that the real issue boils down to the fact that timestamp
input checks a name against the timezone abbrevs list first, and the
zic database second; whereas the various forms of AT TIME ZONE
do the lookup in the other order. I am not sure what the original
rationale for that behavior was, if indeed it was thought through
at all --- but what I think now is we should change AT TIME ZONE to
check for abbrevs first. Consistency suggests that both lookups
should produce the same result, and given that timestamp input is
far more heavily used than AT TIME ZONE, changing the behavior of
the latter seems safest. I'm inclined to think that the timestamp
input behavior is more correct anyway: to me "midnight EST" means
midnight standard time, regardless of whether daylight savings
time is in force or not.

Should we consider this a bug and back-patch it, or just fix it
for 8.4 and later?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [SQL] Egroupware infolog query slow (includes query plan)

Mark Stosberg <mark@summersault.com> writes:
> I'm not skilled enough at reading the "Explain Analzyze" output to
> understand what the primary problem is.

The problem is the repeated execution of the subquery in the SELECT
list; that's taking over 683 of the 686 seconds:

> SubPlan
> -> Aggregate (cost=2162.60..2162.61 rows=1
> width=0) (actual time=21.073..21.073 rows=1 loops=32424)
^^^^^^ ^^^^^

The current formulation of the query guarantees that you can't do better
than a nestloop join with "sub" on the inside, and that nestloop isn't
even indexed. See if you can convert it to a regular join instead of a
sub-select (probably with GROUP BY instead of DISTINCT).

Also, those LIKE conditions are just horrid: slow *and* unreadable.
Consider redesigning your data representation. Perhaps converting
info_responsible to an int array would be reasonable.

regards, tom lane

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Re: [PORTS] contrib - fuzzystrmatch installation issue

Tom Lane wrote:
>> psql:fuzzystrmatch.sql:32: ERROR: could not find function "dmetaphone_alt"
>> in file "/usr/lib/pgsql/fuzzystrmatch.so"
>
> I'm suspicious that /usr/lib/pgsql/fuzzystrmatch.so is actually the 7.4
> version of that module (which is what shipped in RHEL4 to begin with,
> and which would've lacked exactly those three functions). However a
> hole in this theory is that an 8.3 server should've refused to load
> a 7.4 extension module at all. Anyway, double check versions,
> installation locations, etc. A self-configured Postgres installation
> would not default to installing into /usr/lib/pgsql, so it certainly
> seems possible that that file isn't your newly built version.

He had also written me directly off list -- version mismatch it was. See
below. I should have thought to copy the list on my reply -- sorry about
that.

Joe

----------------------
Kenaniah Cerny wrote:
> Joe,
>
> You hit the nail right on the head. Apparently, I was trying to use
> Postgres 7.4.x with the 8.1.11 contrib version. Upgrading Postgres to
> 8.1 solved the issue. Can't believe I did that.
>
> Thanks for pointing it out. It would be a great addition to the
> documentation if the contrib functions were labeled with the versions
> that they first appear in the stable distro. It would most definitely
> help out people like me :-/
>
> And sorry for the double-email.
>
> Thanks,
> Kenaniah
>
> On Sat, Jul 5, 2008 at 4:10 PM, Joe Conway <mail@joeconway.com
> <mailto:mail@joeconway.com>> wrote:
>
> Kenaniah Cerny wrote:
>
> The compiler didn't return any errors during the build process,
> leaving me clueless as to why it's not working correctly.
>
> If you have any insight, please feel free to shoot me back an
> email or to call me at (951) 385-9506, as it is slightly urgent.
>
>
> I see that you simultaneously wrote to the list, but please do that
> first next time.
>
> You haven't provided enough information to be sure, but it sounds to
> me like you have at least two different versions of Postgres
> installed -- probably both 8.3.3 and 7.4.x. Try doing:
>
> locate fuzzystrmatch.so
>
> In 7.4.x the functions being complained about did not exist. You
> could also try doing:
>
>
> psql -d template1 -U postgres
> template1=# select version();
>
> and see what version of postgres you wind up attached to.
>
> Joe
>
>


--
Sent via pgsql-ports mailing list (pgsql-ports@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ports

Re: [PORTS] contrib - fuzzystrmatch installation issue

"Kenaniah Cerny" <kenaniah@gmail.com> writes:
> I am running Postgres 8.3.3 on a CentOS box and I had a few issues when
> trying to install the fuzzystrmatch library. The library seemed to compile
> and make install correctly, but when I ran the sql scripts to add the
> functions to a database, I came up with this issue:

> # psql -d template1 -U postgres -f fuzzystrmatch.sql
> SET
> CREATE FUNCTION
> CREATE FUNCTION
> CREATE FUNCTION
> CREATE FUNCTION
> psql:fuzzystrmatch.sql:24: ERROR: could not find function "difference" in
> file "/usr/lib/pgsql/fuzzystrmatch.so"
> psql:fuzzystrmatch.sql:28: ERROR: could not find function "dmetaphone" in
> file "/usr/lib/pgsql/fuzzystrmatch.so"
> psql:fuzzystrmatch.sql:32: ERROR: could not find function "dmetaphone_alt"
> in file "/usr/lib/pgsql/fuzzystrmatch.so"

I'm suspicious that /usr/lib/pgsql/fuzzystrmatch.so is actually the 7.4
version of that module (which is what shipped in RHEL4 to begin with,
and which would've lacked exactly those three functions). However a
hole in this theory is that an 8.3 server should've refused to load
a 7.4 extension module at all. Anyway, double check versions,
installation locations, etc. A self-configured Postgres installation
would not default to installing into /usr/lib/pgsql, so it certainly
seems possible that that file isn't your newly built version.

Another thing that seems pretty odd is that the above complains about
difference(), which *is* present in the .so according to nm.

BTW, why are you compiling fuzzystrmatch for yourself at all, instead
of just installing the postgresql-contrib RPM?

regards, tom lane

--
Sent via pgsql-ports mailing list (pgsql-ports@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ports

Re: [SQL] Egroupware infolog query slow (includes query plan)

I should have mentioned in the last post that PostgreSQL 8.2.9 is in
use. I could upgrade to 8.3.x if that is expected to help performance in
this case.

Mark

On Sun, 2008-07-06 at 16:23 -0400, Mark Stosberg wrote:
> Hello,
>
> I could use some help figuring out how to speed up a query. Below is the
> SQL and query plan for a common SELECT done by the open source
> eGroupware project.
>
> Now that there are about 16,000 rows in egw_infolog and 32,000 in
> egw_infolog_extra, the below query takes about 6 minutes to finish!
>
> I'm not skilled enough at reading the "Explain Analzyze" output to
> understand what the primary problem is.
>
> Thanks!
>
> Mark
>
> ###########
>
> SELECT DISTINCT main.* ,(
> SELECT count(*) FROM egw_infolog sub WHERE
> sub.info_id_parent=main.info_id AND (info_owner=6 OR
> ((','||info_responsible||',' LIKE '%,-2,%' OR
> ','||info_responsible||',' LIKE '%,-1,%' OR
> ','||info_responsible||',' LIKE '%,6,%') AND
> info_access='public') OR info_owner IN (6) OR
> (info_access='public'
> AND info_owner IN(6)))
> ) AS info_anz_subs FROM egw_infolog main
> LEFT JOIN egw_infolog_extra ON main.info_id=egw_infolog_extra.info_id
> WHERE (
> (info_owner=6 OR ((','||info_responsible||',' LIKE '%,-2,%' OR
> ','||info_responsible||',' LIKE '%,-1,%' OR
> ','||info_responsible||',' LIKE '%,6,%') AND
> info_access='public') OR info_owner IN (6) OR
> (info_access='public'
> AND info_owner IN(6))) AND info_status <> 'deleted' )
> ORDER BY
> info_datemodified DESC LIMIT 15 OFFSET 0
>
> Query plan:
> ####
> Limit (cost=68624989.18..68624991.31 rows=15 width=1011) (actual
> time=686260.735..686260.878 rows=15 loops=1)
> -> Unique (cost=68624989.18..68627288.59 rows=16212 width=1011)
> (actual time=686260.733..686260.857 rows=15 loops=1)
> -> Sort (cost=68624989.18..68625068.47 rows=31716 width=1011)
> (actual time=686260.730..686260.766 rows=29 loops=1)
> Sort Key: main.info_datemodified, main.info_id,
> main.info_type, main.info_from, main.info_addr, main.info_subject,
> main.info_des, main.info_owner, main.info_responsible, main.info_access,
> main.info_cat, main.info_startdate, main.info_enddate,
> main.info_id_parent, main.info_planned_time, main.info_used_time,
> main.info_status, main.info_confirm, main.info_modifier,
> main.info_link_id, main.info_priority, main.pl_id, main.info_price,
> main.info_percent, main.info_datecompleted, main.info_location,
> main.info_custom_from, (subplan)
> -> Merge Left Join (cost=0.00..68594428.95 rows=31716
> width=1011) (actual time=21.358..684226.134 rows=32424 loops=1)
> Merge Cond: (main.info_id =
> egw_infolog_extra.info_id)
> -> Index Scan using egw_infolog_pkey on egw_infolog
> main (cost=0.00..3025.84 rows=16212 width=1011) (actual
> time=0.060..135.766 rows=16212 loops=1)
> Filter: (((info_owner = 6) OR (((((','::text
> || (info_responsible)::text) || ','::text) ~~ '%,-2,%'::text) OR
> (((','::text || (info_responsible)::text) || ','::text) ~~ '%,-1,
> %'::text) OR (((','::text || (info_responsible)::text) || ','::text) ~~
> '%,6,%'::text)) AND ((info_access)::text = 'public'::text)) OR
> (info_owner = 6) OR (((info_access)::text = 'public'::text) AND
> (info_owner = 6))) AND ((info_status)::text <> 'deleted'::text))
> -> Index Scan using egw_infolog_extra_pkey on
> egw_infolog_extra (cost=0.00..1546.30 rows=32424 width=4) (actual
> time=0.025..317.272 rows=32424 loops=1)
> SubPlan
> -> Aggregate (cost=2162.60..2162.61 rows=1
> width=0) (actual time=21.073..21.073 rows=1 loops=32424)
> -> Seq Scan on egw_infolog sub
> (cost=0.00..2122.07 rows=16212 width=0) (actual time=21.065..21.065
> rows=0 loops=32424)
> Filter: ((info_id_parent = $0) AND
> ((info_owner = 6) OR (((((','::text || (info_responsible)::text) ||
> ','::text) ~~ '%,-2,%'::text) OR (((','::text ||
> (info_responsible)::text) || ','::text) ~~ '%,-1,%'::text) OR
> (((','::text || (info_responsible)::text) || ','::text) ~~ '%,6,
> %'::text)) AND ((info_access)::text = 'public'::text)) OR (info_owner =
> 6) OR (((info_access)::text = 'public'::text) AND (info_owner = 6))))
> Total runtime: 686278.730 ms
>
>
>
>
>

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

[SQL] Egroupware infolog query slow (includes query plan)

Hello,

I could use some help figuring out how to speed up a query. Below is the
SQL and query plan for a common SELECT done by the open source
eGroupware project.

Now that there are about 16,000 rows in egw_infolog and 32,000 in
egw_infolog_extra, the below query takes about 6 minutes to finish!

I'm not skilled enough at reading the "Explain Analzyze" output to
understand what the primary problem is.

Thanks!

Mark

###########

SELECT DISTINCT main.* ,(
SELECT count(*) FROM egw_infolog sub WHERE
sub.info_id_parent=main.info_id AND (info_owner=6 OR
((','||info_responsible||',' LIKE '%,-2,%' OR
','||info_responsible||',' LIKE '%,-1,%' OR
','||info_responsible||',' LIKE '%,6,%') AND
info_access='public') OR info_owner IN (6) OR
(info_access='public'
AND info_owner IN(6)))
) AS info_anz_subs FROM egw_infolog main
LEFT JOIN egw_infolog_extra ON main.info_id=egw_infolog_extra.info_id
WHERE (
(info_owner=6 OR ((','||info_responsible||',' LIKE '%,-2,%' OR
','||info_responsible||',' LIKE '%,-1,%' OR
','||info_responsible||',' LIKE '%,6,%') AND
info_access='public') OR info_owner IN (6) OR
(info_access='public'
AND info_owner IN(6))) AND info_status <> 'deleted' )
ORDER BY
info_datemodified DESC LIMIT 15 OFFSET 0

Query plan:
####
Limit (cost=68624989.18..68624991.31 rows=15 width=1011) (actual
time=686260.735..686260.878 rows=15 loops=1)
-> Unique (cost=68624989.18..68627288.59 rows=16212 width=1011)
(actual time=686260.733..686260.857 rows=15 loops=1)
-> Sort (cost=68624989.18..68625068.47 rows=31716 width=1011)
(actual time=686260.730..686260.766 rows=29 loops=1)
Sort Key: main.info_datemodified, main.info_id,
main.info_type, main.info_from, main.info_addr, main.info_subject,
main.info_des, main.info_owner, main.info_responsible, main.info_access,
main.info_cat, main.info_startdate, main.info_enddate,
main.info_id_parent, main.info_planned_time, main.info_used_time,
main.info_status, main.info_confirm, main.info_modifier,
main.info_link_id, main.info_priority, main.pl_id, main.info_price,
main.info_percent, main.info_datecompleted, main.info_location,
main.info_custom_from, (subplan)
-> Merge Left Join (cost=0.00..68594428.95 rows=31716
width=1011) (actual time=21.358..684226.134 rows=32424 loops=1)
Merge Cond: (main.info_id =
egw_infolog_extra.info_id)
-> Index Scan using egw_infolog_pkey on egw_infolog
main (cost=0.00..3025.84 rows=16212 width=1011) (actual
time=0.060..135.766 rows=16212 loops=1)
Filter: (((info_owner = 6) OR (((((','::text
|| (info_responsible)::text) || ','::text) ~~ '%,-2,%'::text) OR
(((','::text || (info_responsible)::text) || ','::text) ~~ '%,-1,
%'::text) OR (((','::text || (info_responsible)::text) || ','::text) ~~
'%,6,%'::text)) AND ((info_access)::text = 'public'::text)) OR
(info_owner = 6) OR (((info_access)::text = 'public'::text) AND
(info_owner = 6))) AND ((info_status)::text <> 'deleted'::text))
-> Index Scan using egw_infolog_extra_pkey on
egw_infolog_extra (cost=0.00..1546.30 rows=32424 width=4) (actual
time=0.025..317.272 rows=32424 loops=1)
SubPlan
-> Aggregate (cost=2162.60..2162.61 rows=1
width=0) (actual time=21.073..21.073 rows=1 loops=32424)
-> Seq Scan on egw_infolog sub
(cost=0.00..2122.07 rows=16212 width=0) (actual time=21.065..21.065
rows=0 loops=32424)
Filter: ((info_id_parent = $0) AND
((info_owner = 6) OR (((((','::text || (info_responsible)::text) ||
','::text) ~~ '%,-2,%'::text) OR (((','::text ||
(info_responsible)::text) || ','::text) ~~ '%,-1,%'::text) OR
(((','::text || (info_responsible)::text) || ','::text) ~~ '%,6,
%'::text)) AND ((info_access)::text = 'public'::text)) OR (info_owner =
6) OR (((info_access)::text = 'public'::text) AND (info_owner = 6))))
Total runtime: 686278.730 ms

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Re: [HACKERS] log_rotation_age integer overflow display quirk

Bernd Helmle <mailings@oopsware.de> writes:
> --On Freitag, Juli 04, 2008 11:31:07 +0200 Stefan Kaltenbrunner
> <stefan@kaltenbrunner.cc> wrote:
>> I just noticed that setting log_rotation_age to a value larger than 24
>> days results in rather weird output (I have not actually tested yet if
>> that affects the functionality too or just the output):

> This seems to be a bug in _ShowOption(), where the corresponding value is
> converted into milliseconds to get the biggest possible time unit to
> display. This overflows the result variable (which is declared as int),
> causing this strange output.

Yup --- fixed by using int64 arithmetic for the units conversion.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[COMMITTERS] pgsql: Prevent integer overflows during units conversion when displaying

Log Message:
-----------
Prevent integer overflows during units conversion when displaying a GUC
variable that has units. Per report from Stefan Kaltenbrunner.

Backport to 8.2. I also backported my patch of 2007-06-21 that prevented
comparable overflows on the input side, since that now seems to have enough
field track record to be back-patched safely. That patch included addition
of hints listing the available unit names, which I did not bother to strip
out of it --- this will make a little more work for the translators, but
they can copy the translation from 8.3, and anyway an untranslated hint
is better than no hint.

Tags:
----
REL8_2_STABLE

Modified Files:
--------------
pgsql/src/backend/utils/misc:
guc.c (r1.360.2.2 -> r1.360.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.360.2.2&r2=1.360.2.3)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Prevent integer overflows during units conversion when displaying

Log Message:
-----------
Prevent integer overflows during units conversion when displaying a GUC
variable that has units. Per report from Stefan Kaltenbrunner.

Backport to 8.2. I also backported my patch of 2007-06-21 that prevented
comparable overflows on the input side, since that now seems to have enough
field track record to be back-patched safely. That patch included addition
of hints listing the available unit names, which I did not bother to strip
out of it --- this will make a little more work for the translators, but
they can copy the translation from 8.3, and anyway an untranslated hint
is better than no hint.

Tags:
----
REL8_3_STABLE

Modified Files:
--------------
pgsql/src/backend/utils/misc:
guc.c (r1.432.2.1 -> r1.432.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.432.2.1&r2=1.432.2.2)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Prevent integer overflows during units conversion when displaying

Log Message:
-----------
Prevent integer overflows during units conversion when displaying a GUC
variable that has units. Per report from Stefan Kaltenbrunner.

Backport to 8.2. I also backported my patch of 2007-06-21 that prevented
comparable overflows on the input side, since that now seems to have enough
field track record to be back-patched safely. That patch included addition
of hints listing the available unit names, which I did not bother to strip
out of it --- this will make a little more work for the translators, but
they can copy the translation from 8.3, and anyway an untranslated hint
is better than no hint.

Modified Files:
--------------
pgsql/src/backend/utils/misc:
guc.c (r1.461 -> r1.462)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.461&r2=1.462)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [HACKERS] CommitFest rules

On Sun, Jul 6, 2008 at 11:44 PM, Bruce Momjian <bruce@momjian.us> wrote:
>
> Just a personal request, but I would like a permanent URL that points to
> the in-progress commit page and is only changed when the commit fest of
> _over_.
>

Well, most of the time there isn't any commitfest "in-progress" at
all. If you want a permanent redirect, how do you expect it to behave
when we are between commitfests?

Speaking of the issue of navigating between commitfests, I agree that
this could use some love.

I mentioned to Alvaro over IM that I was thinking about adding a
navigation bar at the bottom of each commitfest. This would show,
e.g., for the current July commitfest:

<< Previous commitfest | Current commitfest | Next commitfest >>
2008-05 2008-07 2008-09
[closed] [current] [open]

I'm still pondering a way to add this that would require minimal
ongoing maintenance, but I wanted to gauge interest before investing
too much more headspace into it.

Is this something that you guys would find valuable?

Cheers,
BJ

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] postgresql's MVCC implementation

Kent Tong <kent@cpttm.org.mo> writes:
> 1: T1 sets isolation to serializable & begins a transaction
> 2: T2 sets isolation to serializable & begins a transaction
> 3: T1 reads X into v1
> 4: T2 reads Y into v2
> 5: T1 writes v1 into Y
> 6: T2 writes v2 into X
> 7: T1 commits
> 8: T2 commits

> Obviously, this sequence is also not a serializable execution. However, it
> is allowed by
> PostgreSQL. Moreover, according to the MVCC reference above, step 5 should
> really
> fail because the read timestamp of Y is that of T2, which is greater than
> that of T1.

If you want that to fail, use a SELECT FOR UPDATE at steps 3/4.

My interpretation of MVCC is that the above example isn't even
meaningful, because it assumes that "writing into Y" is an overwrite,
which it is not in Postgres --- that is, if T2 reads Y again, it'll
get the same value as before.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgsql-www] Proposal to remove some mailing lists

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Thursday, July 03, 2008 13:02:16 -0400 Robert Treat
<xzilla@users.sourceforge.net> wrote:


> This presumes one only uses php for web development... really it can be used
> for scripting and gui applications as well. Heck, I even heard of some
> company trying to use it for database procedural work.

How about pgsql-interfaces?


- --
Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy@hub.org MSN . scrappy@hub.org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkhwz2AACgkQ4QvfyHIvDvOw0gCg45fPEXHLyH8dqmR9tf/VeOao
OdQAnjvIa7nQzyDHwA+34cUtpjJD3Ob2
=r7bz
-----END PGP SIGNATURE-----


--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [GENERAL] Installation problem -- another installation is in progress

Thanks for your prompt response. Actually, I solved the problem after posting. When I got to the "Ready to Install" dialog, in the Task Manager, there were 4 instances of msiexec.exe running. I experimented with deleting 3 of them. At first, I killed the whole install, but finally I deleting the correct three, and the install ran to completion.

Susan


--- On Sun, 7/6/08, Dave Page <dpage@pgadmin.org> wrote:

> From: Dave Page <dpage@pgadmin.org>
> Subject: Re: [GENERAL] Installation problem -- another installation is in progress
> To: susancrayne@yahoo.com
> Cc: pgsql-general@postgresql.org
> Date: Sunday, July 6, 2008, 3:59 AM
> On Sat, Jul 5, 2008 at 11:16 PM, Susan Crayne
> <susancrayne@yahoo.com> wrote:
> > I am attempting to install the postrgresql-8.3.3-1
> download on Windows Vista. When I get to the "Ready
> to install" dialog and click OK, I get the message
> "Another installation is in progress", and I need
> to click on cancel and end the installation -- otherwise I
> am in a loop. This happens even after I reboot. Any help
> would be greatly appreciated.
> >
>
> It sounds like your installer database is, umm, confused. I
> assume
> you're running setup.bat? If so, try just running the
> vcredist
> executable on it's own. If that completes OK, then try
> postgresql-8.3.msi.
>
>
> --
> Dave Page
> EnterpriseDB UK: http://www.enterprisedb.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] CommitFest rules

Dave Page wrote:
> On Sun, Jul 6, 2008 at 6:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Robert Treat <xzilla@users.sourceforge.net> writes:
> >> Hmm, looks like some of the things I was thinking about have been added
> >> recenelt... cool. One question I have still remains though, on the main
> >> developer page (http://wiki.postgresql.org/wiki/Development_information) it
> >> has a link to the "current commitfest", which points to september's
> >> commitfest page. ISTM the current commitfest is July's, since that's the one
> >> we're currently working on.
> >
> > The meaning of "current commitfest" as used on that page is "the place
> > you should submit a new patch today". I agree there's a terminological
> > problem here, and we need to somehow distinguish that meaning from "the
> > commitfest we are currently trying to close out". But you are not
> > helping matters by trying to eliminate the distinction.
>
> Agreed - but Robert does have a point - I know both Greg & I have
> resorted to searching to find the in-progress fest page. I'll see if I
> can improve the index page a little.

Just a personal request, but I would like a permanent URL that points to
the in-progress commit page and is only changed when the commit fest of
_over_.

--
Bruce Momjian <bruce@momjian.us>

http://momjian.us

EnterpriseDB

http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[GENERAL] postgresql's MVCC implementation

Hi,

I read a description of MVCC in http://www.cs.ust.hk/~dimitris/CS530/L24.ppt
and
found that this isn't exactly what is implemented in PostgreSQL. For
example,
for a sequence of operations like:

1: T1 sets isolation to serializable & begins a transaction
2: T2 sets isolation to serializable & begins a transaction
3: T1 reads X into v1
4: T2 reads Y into v2
5: T1 writes v1 into Y
6: T2 writes v2 into X
7: T1 commits
8: T2 commits

Obviously, this sequence is also not a serializable execution. However, it
is allowed by
PostgreSQL. Moreover, according to the MVCC reference above, step 5 should
really
fail because the read timestamp of Y is that of T2, which is greater than
that of T1.

I understand that PostgreSQL doesn't implement predictive locking, but this
example
doesn't involve any phantom at all. It is plain multiversion timestamp
concurency control.

Any idea? Thanks in advance!


-----
--
Kent Tong
Wicket tutorials freely available at http://www.agileskills2.org/EWDW
Axis2 tutorials freely available at http://www.agileskills2.org/DWSAA
--
View this message in context: http://www.nabble.com/postgresql%27s-MVCC-implementation-tp18302020p18302020.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] Git Repository for WITH RECURSIVE and others

On Sun, Jul 06, 2008 at 02:58:38PM +0200, Michael Meskes wrote:
> On Thu, Jul 03, 2008 at 09:18:17AM +0530, Abhijit Menon-Sen wrote:
> > Run git-clone
> > http://git.postgresql.org/git/~davidfetter/postgresql/.git
> > instead. "git://..." apparently doesn't work on that repository (I
> > don't know why not).
>
> Is this the official recursion archive now?

I don't know about official, but it's available :)

> Can we commit there too? I didn't want to try this without having a
> real change. :-)

If you send me a public key, I can put it there. That way, you'll be
able to get in as davidfetter.

Cheers,
David (hoping to close this one out soon on account of its being
committed :)
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
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] Git Repository for WITH RECURSIVE and others

On Thu, Jul 03, 2008 at 09:18:17AM +0530, Abhijit Menon-Sen wrote:
> Run git-clone http://git.postgresql.org/git/~davidfetter/postgresql/.git
> instead. "git://..." apparently doesn't work on that repository (I don't
> know why not).

Is this the official recursion archive now? Can we commit there too? I
didn't want to try this without having a real change. :-)

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] Installation problem -- another installation is in progress

Linux
ps -ef | grep NameOfInstallProgram

Windows
<ctl/alt/del>
go to Task Manager
from Application Manager or Process Management
If you see the install program delete it

Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.


> Date: Sat, 5 Jul 2008 15:16:57 -0700
> From: susancrayne@yahoo.com
> Subject: [GENERAL] Installation problem -- another installation is in progress
> To: pgsql-general@postgresql.org
>
> I am attempting to install the postrgresql-8.3.3-1 download on Windows Vista. When I get to the "Ready to install" dialog and click OK, I get the message "Another installation is in progress", and I need to click on cancel and end the installation -- otherwise I am in a loop. This happens even after I reboot. Any help would be greatly appreciated.
>
> Susan
>
>
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general



Making the world a better place one message at a time. Check out the i'm Talkathon.

Re: [GENERAL] Query Problem

On lau, 2008-07-05 at 23:04 +0000, Sheikh Salman Ahmed wrote:
> Hi Fellows
>
> I still have problem to access my databank.It shows syntax problem,I
> am using VC++ 2005 with postgresql 8.3.My table name is Person and it
> has three column,Person ID,first name and last name (testing
> version).whole c++ code is

more precise schema definition would be more helpful

>
> ...
> res = PQexec(conn, "INSERT INTO public.Person VALUES
> (221,'Siddiqi','Umer')");
> ...
> It shows no relation between public and person,if i write only
> person ,it show ,Person doesn't exist.

and real error messages are preferred.

As someone already told you a few days ago, the problem
could be that the table was created "Person" (mixed case
with double quotes). you have not confirmed or denied this.

If that is the case, you need to quote the name in your SQL:

INSERT INTO public."Person" VALUES (221,'Siddiqi','Umer')

(of course, you need to escape those quotes for your c)


If this is not your problem, please suply us with more information, and
someone may be able to help you.

gnari

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Installation problem -- another installation is in progress

On Sat, Jul 5, 2008 at 11:16 PM, Susan Crayne <susancrayne@yahoo.com> wrote:
> I am attempting to install the postrgresql-8.3.3-1 download on Windows Vista. When I get to the "Ready to install" dialog and click OK, I get the message "Another installation is in progress", and I need to click on cancel and end the installation -- otherwise I am in a loop. This happens even after I reboot. Any help would be greatly appreciated.
>

It sounds like your installer database is, umm, confused. I assume
you're running setup.bat? If so, try just running the vcredist
executable on it's own. If that completes OK, then try
postgresql-8.3.msi.


--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Query Problem

On Sun, Jul 6, 2008 at 12:04 AM, Sheikh Salman Ahmed
<salman_sheikh@hotmail.com> wrote:

> res = PQexec(conn, "INSERT INTO public.Person VALUES

Without quotes around Person, it will be shifted to lower case to
match a table called person. I suspect you need to do:

res = PQexec(conn, "INSERT INTO public.\"Person\" VALUES

It's almost always easier to use lower case names in Postgres.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] CommitFest rules

On Sun, Jul 6, 2008 at 6:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
>> Hmm, looks like some of the things I was thinking about have been added
>> recenelt... cool. One question I have still remains though, on the main
>> developer page (http://wiki.postgresql.org/wiki/Development_information) it
>> has a link to the "current commitfest", which points to september's
>> commitfest page. ISTM the current commitfest is July's, since that's the one
>> we're currently working on.
>
> The meaning of "current commitfest" as used on that page is "the place
> you should submit a new patch today". I agree there's a terminological
> problem here, and we need to somehow distinguish that meaning from "the
> commitfest we are currently trying to close out". But you are not
> helping matters by trying to eliminate the distinction.

Agreed - but Robert does have a point - I know both Greg & I have
resorted to searching to find the in-progress fest page. I'll see if I
can improve the index page a little.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-www] Events moderation

On Sat, Jul 5, 2008 at 11:28 PM, Robert Treat
<xzilla@users.sourceforge.net> wrote:

> Are nagios alerts still going to -slaves? ISTR there was some talk about
> directing them to more specific emails, did that ever happen?

Most probably are, yes.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [HACKERS] introduction of WIP window function patch

2008/7/6 Simon Riggs <simon@2ndquadrant.com>:
>
> On Sun, 2008-07-06 at 17:39 +0900, H.Harada wrote:
>
>> Is there security/performance issue about this?
>
> Performance, yes.
>
> If we need access to more rows than will fit within work_mem we have a
> problem and will need to restart sort. Giving random access to all
> tuples in the current window, whatever its size would be very costly,
> which is why we have optimized that access for merge joins. So we need
> to know how far back access is required, if any - think of that as an
> "access window" definition.

Is this about tuplesort, not tuplestore? At a glance, tuplestore seems
to be able to access tuples randomly without any performance problem,
just fitting its pointer. So I thought planner should always insert
Sort node before Window node to let Window not to sort, as I explained
in the document. But anyways, I understand some kind of optimization
mechanism to scroll in/out window is needed.

> I know I rattle on about performance, but with window functions it will
> be critical to their usability to have them perform well. We can already
> do the types of analysis that window functions allow, it just requires
> hand written procedures to do it. So the window functions must perform
> acceptably well against very large tables (i.e. much bigger than
> memory).

I know, the probable use case is against large data set. There's no
reason to add this feature if it is slower than self joins or other
kludge methods.


--
Hitoshi Harada

--
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] gsoc, text search selectivity and dllist enhancments

Heikki Linnakangas wrote:
> Tom Lane wrote:
>> "Heikki Linnakangas" <heikki@enterprisedb.com> writes:
>>> Tom Lane wrote:
>> Hmm, I had just assumed without looking too closely that it was stats
>> target times a fudge factor. What is the rationale for doing it as
>> above? I don't think I like the idea of the limit varying over the
>> course of the scan --- that means that lexemes in different places
>> in the input will have significantly different probabilities of
>> surviving to the final result.

> will never have a chance to climb up the list. I'm not sure where the
> "times two" figure comes from, maybe it's just a fudge factor, but the
> bottom line is that the minimum size needed depends on the size of the
> longest tsvector.

Thank you for the review.

The whole algorithm was based on the original analyze routine from
analyze.c (compute_minimal_stats() ). The "times two" factor is there, I
think it's purpose is to reduce the chances of an element dropping off
the list before it's number of occurrences gets boosted. It doesn't look
like a factor of 1.5 or 3 would be much better/worse, I just kept it as
I saw it.

It's true that making the limit change in the course of the scan makes
the set of surviving lexemes dependent on the order in which entries are
fetched. I'm inclined to believe that most of the times it won't change
the overall result - some entries will drop off eariler, some later,
some will be discarded when it comes to the final pass at the end of the
algorithm. Maybe I should do a test with - run ANALYZE several times
over a large set of documents and see if the result stays the same?

Since the number of tracked lexemes needs to be correlated with the
length of the longest tsvector, the only one possibility I see is doing
two passes through the statistics sample (determine the length first,
then do the real work). I wasn't sure if rows fetched by the sampling
algorithm are guaranteed to be in memory. If so, then another pass is
just a linear cost (and asymptotically insignificant).

About the array vs dllist issue. If the "two passes" idea is better than
"dynamically expanding list" then an array is of course better. I
thought about using a one-way list, but having it two-way helps with
with inserting and element at the end of the 1-occurrence group (and I
think that's important, read on) and with the final pass, in which you
go through the list backward and stop when you get enough entries to
fill the pg_statistics tuple.
Maybe these could be dealt with efficiently using a one-way list, it was
easier to do with a double-linked one.

Keeping the list sorted at all times has an advantage: if you insert new
entries at the *end* of the 1-occurrence block and have the ones at the
begginning fall off, you are discarding elements that haven't been seen
for the longest time.
Consider a list:
cat:1 dog:1 duck:2 rhino:3
If the next lexeme is "goat", and you'd put it at the begginning of the
list (or put in anywhere and qsort() it, you could get)
goat:1 cat:1 dog:1 duck:2 rhino:3
And if this would've trigger an overflow, you could lose the goat, when
you'd want to lose the cat.

Once again: the whole algorithm is a ripoff from analyze.c, with the
dllist instead of an array because you don't know how big tracking list
will you need and with a hashtable, because the tracking list will
probably be large and looking up things linearly wouldn't be fun.

Cheers,
Jan

--
Jan Urbanski
GPG key ID: E583D7D2

ouden estin

--
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] introduction of WIP window function patch

On Sun, 2008-07-06 at 17:39 +0900, H.Harada wrote:

> Is there security/performance issue about this?

Performance, yes.

If we need access to more rows than will fit within work_mem we have a
problem and will need to restart sort. Giving random access to all
tuples in the current window, whatever its size would be very costly,
which is why we have optimized that access for merge joins. So we need
to know how far back access is required, if any - think of that as an
"access window" definition.

For example,
rownumber() doesn't need access to prior tuples at all.
lag(col, 1) requires access only to the prior row of the current window
ntile() needs to know the size of the window before we begin processing

In some cases the window itself is redefined for each tuple, e.g.
avg() over (order by ... range between 5 preceeding and current row)

In that case, we want the tuples no longer in the window to scroll out
of memory. We already have the mechanism for this: a dynamic tuplestore
(materialize node) in front of the tuplesort (sort node).

Most of that tuning can be done after the initial implementation, but my
point here is this: there needs to be a mechanism by which the window
access requirements can be specified for a function so the executor can
understand how to optimise access. So if you go the route of defining an
extensible API then you must include this also.

I know I rattle on about performance, but with window functions it will
be critical to their usability to have them perform well. We can already
do the types of analysis that window functions allow, it just requires
hand written procedures to do it. So the window functions must perform
acceptably well against very large tables (i.e. much bigger than
memory).

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


--
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] introduction of WIP window function patch

2008/7/6 Simon Riggs <simon@2ndquadrant.com>:
>> I think there are two types of functions for windowed mode.
>> - windowed aggregate
>> this type of function is exactly same as normal aggregate. So we use
>> functions that have been in pgsql already. Actually in my patch above,
>> I didn't introduce any new function. This type of function includes
>> simply sum(), avg(), etc. which returns same values on a partition or
>> a window frame.
>>
>> - windowed function
>> this is the NEW type of function. I guess we should add a new function
>> type to pgsql. This type of function includes rank(), rank_dense(),
>> row_number(), etc. Windowed functions returns different values per
>> tuple.
>>
>> The difference between two types is if the function returns the same
>> value during a partition or different values.
>>
>> So, windowed aggregate and normal aggregate overlap each other. How
>> you know which one is that you see OVER clause in SQL just after the
>> function call. When you see OVER after func(), and pg_proc says it's
>> an aggregate, it's a windowed aggregate. Otherwise, it's a windowed
>> function.
>>
>> If I misunderstood about those definitions please correct me.
>
> Yes, I understand that and I think Martijn does also.
>
> I've done some thinking and rooting around on this and I think I have a
> different proposal for you, different to what we just discussed.
>
> SQL2008 specifies window functions as
>
> * rank functions
> * distribution functions: percent_rank() and cume_dist()
> * rownumber()
> * ntile()
> * lead() and lag()
> * first, last and n-th value functions
> * inverse distribution functions (similar to n-th value, based upon
> distribution function results)
>
> plus window aggregate functions (the normal aggregates COUNT, SUM etc)
>
> Now looking through all of those, I don't see *any* window functions
> that need access to different datatypes, or actually need to see the
> values of the attributes.
>
> The normal aggregates work with windows identically to the way they do
> without windows, so no change needed there.
>
> AFAICS we could define all of the non-aggregate window functions on the
> above list *without* defining them as functions in pg_proc. That would
> be a benefit because the window functions are very powerful and we'd
> need to give them access to any/all tuples in the window.
>
> So that would mean we don't provide a mechanism for user-defined
> windowed aggregate functions at all. Which solves the discussion about
> how to pass generic info through to them (at least long enough to get
> the first implementation done).
>
> We do already have such functions in code, e.g. greatest(). Sure they
> need to be defined in code, but we don't need to come up with a generic
> API for them.
>
> If you disagree, think about how we'd implement lag() or ntile() and
> what info we'd need to pass them.

Well, your idea is one of considerable choices. But I like pgsql's
extensibility that enables pgsql more powerful DBMS. So, I design it
as you propsed though trying to unify the function form somehow.

Just idea, how about pass window object to a function? We'll provide
window operation API then in the function you take window object
through fcinfo:

Datum func(PG_FUNCTION_ARGS)
{
Datum v;
WindowObject w = get_window(fcinfo);
HeapTuple htup_current = window_current_row(w);
HeapTuple htup_prev = window_preceding(w, 1);
/* do something */
PG_RETURN_DATUM(v);
}

so that a function access whole the window. APIs include
- current row
- preceding row
- following row
- current key
- preceding key
- following key
- iterate for the window
where "key" means ORDER BY values in OVER clause. Fortunately, my
patch uses tuplestore/tuplesort to create window, which allows random
access operation such above. Is there security/performance issue about
this?

--
Hitoshi Harada

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] Memory use in 8.3 plpgsql with heavy use of xpath()

> Gregory Stark <stark@enterprisedb.com> writes:
>> That's just a special case of what would be expected to happen with
>> memory
>> allocation anyways though. Few allocators return memory to the OS
>> anyways.
>
> Well, that does happen on Linux for instance. Since Matt knew in his
> original report that the xpath leak was intra-transaction, I assumed
> he must be using a platform where malloc/free can release memory back
> to the OS --- else he couldn't have seen that behavior from outside
> the backend.
>
> Still, it's entirely possible that some sort of high-water-mark is
> involved somewhere, perhaps in malloc's internal data structures.

I was really going on a hunch, as I noticed a definite trend of postgres
processes using more and more memory over time, and it only started after
switching to 8.3 and starting to use xpath() quite heavily. Most of the
memory data I have comes from Linux x64 systems with Postgres compiled as
64-bit. But I did also notice what appeared to be a similar trend on an OS
X PPC system.

In any event, I'm sorry I can't provide any more helpful tests, but I'll
report back how the system changes after I've patched these systems.

-- m@

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general