On Sun, 2012-09-23 at 21:22 -0500, Karl O. Pinc wrote:
> Hi,
>
> Adds a caution to the pg_restore docs
>
> Against git master.
I'm not sure what you are trying to get at here. It's basically saying,
if you make an incomplete database restore, you might get an incomplete
database. Is there
On Mon, 2012-11-12 at 11:42 -0600, Karl O. Pinc wrote:
> Could ALTER TABLE use an option to drop the
> primary key constraint? I needed to do that,
> found it was not obvious, and this lead me to
> try to improve things.
That could be useful, I think. But it might open a can of worms.
--
S
On Fri, 2012-09-28 at 11:10 -0500, Karl O. Pinc wrote:
> pg_temp-toindex.patch
> Puts pg_temp into the index of the docs.
But there is no object called pg_temp. It always pg_temp_
something. How should that be indexed?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Fri, 2012-10-26 at 16:23 -0500, Karl O. Pinc wrote:
> Attached is: raise_using_keyword_table-v3.patch
> It uses a variable list instead of a table.
>
> I believe I prefer the table but this might
> (or might not) be more consistent with the
> style of other parts of the docs.
I'm unsure wheth
On 12-11-14 08:17 PM, Andres Freund wrote:
For the regular satisfies routines this is needed in prepareation of logical
decoding. I changed the non-regular ones for consistency as well.
The naming between htup, tuple and similar is rather confused, I could not find
any consistent naming anywhere
On Fri, Nov 16, 2012 at 05:31:12PM +0100, Andres Freund wrote:
> On 2012-11-16 13:17:47 -0300, Alvaro Herrera wrote:
> > Andres is on the verge of convincing me that we need to support
> > singleton FOR SHARE without multixacts due to performance concerns.
>
> I don't really see any arguments agai
> You could make that same claim about plain views, but in point of
> fact the demand for making them work in COPY has been minimal.
> So I'm not convinced this is an essential first-cut feature.
> We can always add it later.
Of course. I just had the impression that we could support COPY FROM b
On Fri, 2012-11-16 at 17:04 -0800, Jeff Janes wrote:
> On Thu, Nov 15, 2012 at 4:42 PM, Jeff Davis wrote:
> >
> > Also, I am wondering about PD_ALL_VISIBLE. It was originally introduced
> > in the visibility map patch, apparently as a way to know when to clear
> > the VM bit when doing an update.
On Fri, 2012-11-16 at 16:09 +0100, Andres Freund wrote:
> As far as I understand the code the crash-safety aspects of the
> visibilitymap currently rely on on having the knowledge that ALL_VISIBLE
> has been cleared during a heap_(insert|update|delete). That allows
> management of the visibilitymap
On Thu, Nov 15, 2012 at 4:42 PM, Jeff Davis wrote:
>
> Also, I am wondering about PD_ALL_VISIBLE. It was originally introduced
> in the visibility map patch, apparently as a way to know when to clear
> the VM bit when doing an update. It was then also used for scans, which
> showed a significant s
On Fri, 2012-11-16 at 11:58 -0500, Robert Haas wrote:
> > Also, I am wondering about PD_ALL_VISIBLE. It was originally introduced
> > in the visibility map patch, apparently as a way to know when to clear
> > the VM bit when doing an update. It was then also used for scans, which
> > showed a signi
Robert Haas wrote:
> Josh Berkus wrote:
>> Being empty (in an inaccurate way) is just one kind of stale data.
>
> This is my feeling also.
If you had an MV summarizing Wisconsin courts cumulative case counts
by case type, "empty" would not have been a valid "stale" state for
over 150 years. That
Thom Brown wrote:
> postgres=# create view v_test as select 1;
> CREATE VIEW
> postgres=# create materialized view mv_test as select * from v_test;
> ERROR: could not open file "base/12064/16425": No such file or directory
Thanks for the report; will investigate.
-Kevin
--
Sent via pgsql-hack
Josh Berkus writes:
> There's going to be a pretty strong demand for COPY FROM matviews.
> Forcing the user to use COPY FROM ( SELECT ... ) will be seen as
> arbitrary and unintuitive.
You could make that same claim about plain views, but in point of
fact the demand for making them work in COPY h
"Kevin Grittner" writes:
>> UPDATE MATERIALIZED VIEW was problematic?
>
> Not technically, really, but I saw two reasons that I preferred LOAD MV:
>
> 1. It seems to me to better convey that the entire contents of the MV
> will be built from scratch, rather than incrementally adjusted.
> 2. We
Tom Lane writes:
> Have you considered ALTER SYSTEM SET ... ? We'd talked about that in
> the context of the other patch, but it seems to fit much more naturally
> with this one. Or maybe ALTER GLOBAL SET or ALTER ALL SET.
I would paint that one ALTER SYSTEM SET and the file based one ALTER
CON
Kevin,
> I agree that there are likely to be more use cases for this than
> temp MVs. Unfortunately, I've had a hard time figuring out how to
> flag an MV which is empty because its contents were lost after a
> crash with preventing people from using an MV which hasn't been
> populated, which has
By chance (?) I got similar one today too, when dropping extension:
ERROR: could not open file "base/12623/12548": No such file or directory
I thought something might have gone wrong during Linux upgrade 2 days
ago, but it's not likely that we both have the issue.
I wonder if something is br
2012/11/16 Albe Laurenz :
> Kohei KaiGai wrote:
>> The attached patch is just a refreshed version for clean applying to
>> the latest tree.
>>
>> As previous version doing, it makes pseudo enhancement on file_fdw
>> to print something about the supplied tuple on INSERT, UPDATE and
>> DELETE stateme
On Fri, Nov 16, 2012 at 7:33 PM, Merlin Moncure wrote:
> On Fri, Nov 16, 2012 at 4:32 AM, Amit Kapila
> wrote:
> > On Thursday, November 15, 2012 10:19 PM Merlin Moncure wrote:
> >> On Thu, Nov 15, 2012 at 10:25 AM, Amit Kapila
> >> wrote:
> >
> >>
> >> Sure, although in scans we are using ring
Hannu Krosing writes:
> Can't we keep a separate text .conf file specifically for the background
> processes which can't read system catalogs. It could contain only the
> GUCs these processes are interested in.
What's the value of that, compared to the existing proposal for
write-a-text-file-dire
On 11/16/2012 06:05 PM, Robert Haas wrote:
On Thu, Nov 15, 2012 at 5:38 PM, Tom Lane wrote:
Another and probably bigger thing is that SIGHUP is used for settings
that do something useful only in background processes (eg checkpointer).
Some of those processes are not capable of reading system ca
On Thu, 2012-11-15 at 22:21 -0500, Tom Lane wrote:
> We aren't pressed for flag bits particularly. I think the main
> attraction of this idea is precisely to reduce unnecessary page dirties,
> and so that leads me to suggest a variant: keep the four bits defined as
> now, but do not attempt to set
On Thu, Nov 15, 2012 at 10:55 PM, Michael Paquier
wrote:
> On Fri, Nov 16, 2012 at 12:34 PM, Phil Sorber wrote:
>> On Thu, Nov 15, 2012 at 9:23 PM, Michael Paquier
>> wrote:
>> > 3) Having an output close to what ping actually does would also be nice,
>> > the
>> > current output like Accepting/
Attached is updated patch v4 with the changes Michael pointed out.
On Fri, Nov 16, 2012 at 12:28 AM, Tom Lane wrote:
> Phil Sorber writes:
>> On Thu, Nov 15, 2012 at 10:55 PM, Michael Paquier
>> wrote:
>>> Hum, it is not really consistent to use a magic number here, particularly in
>>> the case
On 15 November 2012 02:28, Kevin Grittner wrote:
> Attached is a patch that...
>
Got this error:
postgres=# create view v_test as select 1;
CREATE VIEW
postgres=# create materialized view mv_test as select * from v_test;
ERROR: could not open file "base/12064/16425": No such file or directory
"Kevin Grittner" writes:
> Josh Berkus wrote:
>> What use would a temporary matview be?
> It would be essentially like a temporary table, with all the same
> persistence options. I'm not really sure how often it will be more
> useful than a temporary table before we have incremental maintenance
>
On Thu, Nov 15, 2012 at 5:38 PM, Tom Lane wrote:
> Another and probably bigger thing is that SIGHUP is used for settings
> that do something useful only in background processes (eg checkpointer).
> Some of those processes are not capable of reading system catalogs at
> all. This is particularly a
On 16 November 2012 16:25, Kevin Grittner wrote:
> Josh Berkus wrote:
>
> > Unlogged is good.
>
> I agree that there are likely to be more use cases for this than
> temp MVs. Unfortunately, I've had a hard time figuring out how to
> flag an MV which is empty because its contents were lost after a
Awesome.
I would love to implement this API in JDBC_FDW.
Atri
Sent from my iPad
On 16-Nov-2012, at 20:20, "Albe Laurenz" wrote:
> Kohei KaiGai wrote:
>> The attached patch is just a refreshed version for clean applying to
>> the latest tree.
>>
>> As previous version doing, it makes pseudo e
On Thu, Nov 15, 2012 at 1:36 PM, Josh Berkus wrote:
> Hmmm. I understand the distinction you're making here, but I'm not sure
> it actually matters to the user. MVs, by their nature, always have
> potentially stale data. Being empty (in an inaccurate way) is just one
> kind of stale data.
This
Josh Berkus wrote:
>> 1. CREATE MATERIALIZED VIEW syntax is stolen directly from CREATE
>> TABLE AS, with all the same clauses supported. That includes
>> declaring a materialized view to be temporary or unlogged.
>
> What use would a temporary matview be?
It would be essentially like a temporar
On Thu, Nov 15, 2012 at 7:42 PM, Jeff Davis wrote:
> But the other tuple hint bits seem to be there just for symmetry,
> because they shouldn't last long. If HEAP_XMIN_INVALID or
> HEAP_XMAX_COMMITTED is set, then it's (hopefully) going to be vacuumed
> soon, and gone completely. And if HEAP_XMAX_
Alvaro Herrera wrote:
> It's not clear to me that it's right to do this by doing regular heap
> updates here instead of heap_inplace_update. Also, I think this might
> end up causing a lot of pg_class tuple churn (at least for matviews that
> delete rows at xact end), which would be nice to avoid.
On 2012-11-16 13:17:47 -0300, Alvaro Herrera wrote:
> Noah Misch wrote:
> > On Wed, Nov 14, 2012 at 01:27:26PM -0300, Alvaro Herrera wrote:
> > > https://github.com/alvherre/postgres/commit/df2847e38198e99f57e52490e1e9391ebb70d770
> > >
> > > (I don't think this is worth a v24 submission).
> >
> >
Jeff Davis wrote:
> On Wed, 2012-11-14 at 21:28 -0500, Kevin Grittner wrote:
> > Attached is a patch that is still WIP but that I think is getting
> > pretty close to completion. It is not intended to be the be-all and
> > end-all for materialized views, but the minimum useful feature set --
> > wh
Noah Misch wrote:
> On Wed, Nov 14, 2012 at 01:27:26PM -0300, Alvaro Herrera wrote:
> > https://github.com/alvherre/postgres/commit/df2847e38198e99f57e52490e1e9391ebb70d770
> >
> > (I don't think this is worth a v24 submission).
>
> Are you aware of any defects in or unanswered questions of this
Peter Eisentraut writes:
> Another way might be something like
> SET GLOBAL name = value
> but that would make the command very dissimilar from the other ones,
> even though their effects are closely related.
Yeah. I think it would also give people a wrong impression about when
the setting would
Hi Pavel,
On 11/16/2012 12:21:11 AM, Pavel Stehule wrote:
> 2012/11/16 Karl O. Pinc :
> > As long as I'm talking crazy talk, why not
> > abandon psql as a shell language and instead make a
> > pl/pgsql interpreter with readlne() in front
> > of it? Solve all these language-related
> > issues by
On Fri, Nov 16, 2012 at 7:13 AM, Dimitri Fontaine
wrote:
> Jeff Davis writes:
>> The documentation says that a materialized view is basically a
>> create-table-as-select except that it remembers the query. Would you say
>> that there is a compelling use case for this alone, or is this a
>> buildi
Greg Smith wrote:
> On 11/14/12 6:28 PM, Kevin Grittner wrote:
>> - Documentation is incomplete.
>> ...
>> - There are no regression tests yet.
>
> Do you have any simple test cases you've been using you could attach?
> With epic new features like this, when things don't work it's hard to
> dist
On 16-11-2012 12:59, Peter Eisentraut wrote:
> Another way might be something like
>
> SET GLOBAL name = value
>
That's the exact syntax I'm about to propose for this feature (changing
settings using SQL).
Are you thinking about allowing changing all configuration settings or just a
subset of it
On 2012-11-15 16:42:57 -0800, Jeff Davis wrote:
> Related to discussion here:
> http://archives.postgresql.org/message-id/cahyxu0zn5emepledozugraqif92f-yjvfr-p5vuh6n0wpkz...@mail.gmail.com
>
> It occurred to me recently that many of the hint bits aren't terribly
> important (at least it's not obvio
On Thu, Nov 15, 2012 at 10:14 PM, Pavan Deolasee
wrote:
> Another approach could be to set those additional bits, but don't dirty the
> page. So if the page is already dirty or gets dirty later on before its
> eviction, those hint bits will get recorded. We can also try some other
> variants like:
On Fri, Nov 16, 2012 at 4:36 AM, Albe Laurenz wrote:
> What do you think?
> Do we feel bound to adhere to RFC 1823?
Well, I guess if we're already using that piece of ugliness elsewhere
there's not much harm in propagating it here, too. The danger of
course is that these APIs will go away under
On Fri, Nov 16, 2012 at 8:58 AM, Andres Freund wrote:
> On 2012-11-16 08:43:12 -0600, Merlin Moncure wrote:
>> On Thu, Nov 15, 2012 at 9:21 PM, Tom Lane wrote:
>> > Jeff Davis writes:
>> >> It occurred to me recently that many of the hint bits aren't terribly
>> >> important (at least it's not o
On 11/15/12 12:53 PM, Peter Eisentraut wrote:
> All you'd need is to add
>
> ApplySetting(InvalidOid, InvalidOid, relsetting, PGC_S_$SOMETHING);
>
> in postinit.c, and have some SQL command to modify this setting.
Alright, any suggestions for the syntax? We currently have
ALTER DATABASE ... SE
On 2012-11-16 08:43:12 -0600, Merlin Moncure wrote:
> On Thu, Nov 15, 2012 at 9:21 PM, Tom Lane wrote:
> > Jeff Davis writes:
> >> It occurred to me recently that many of the hint bits aren't terribly
> >> important (at least it's not obvious to me). HEAP_XMIN_COMMITTED clearly
> >> has a purpose
On 16-11-2012 12:27, Hannu Krosing wrote:
> Why not just make the sending SIGHUP a separate command as it is now ?
>
> SELECT pg_reload_config();
>
... or even a RELOAD command. I've already coded a WIP patch for such command.
--
Euler Taveira de Oliveira - Timbira http://www.timbira.
On 2012-11-14 13:27:26 -0300, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > > * In heap_lock_tuple's XMAX_IS_MULTI case
> > >
> > > [snip]
> > >
> > > why is it membermode > mode and not membermode >= mode?
> >
> > Uh, that's a bug. Fixed. As noticed in the comment above that snippet,
> >
Hi,
Marko Tiikkaja writes:
> The general output scheme looks like this:
>schemaname/OBJECT_TYPES/object_name.sql,
I like this feature, I actually did have to code it myself in the past
and several other people did so, so we already have at least 3 copies of
`getddl` variants around. I really
Kohei KaiGai wrote:
> The attached patch is just a refreshed version for clean applying to
> the latest tree.
>
> As previous version doing, it makes pseudo enhancement on file_fdw
> to print something about the supplied tuple on INSERT, UPDATE and
> DELETE statement.
Basics:
---
The patch a
On Thu, Nov 15, 2012 at 9:21 PM, Tom Lane wrote:
> Jeff Davis writes:
>> It occurred to me recently that many of the hint bits aren't terribly
>> important (at least it's not obvious to me). HEAP_XMIN_COMMITTED clearly
>> has a purpose, and we'd expect it to be used many times following the
>> in
On 11/15/2012 11:38 PM, Tom Lane wrote:
Magnus Hagander writes:
On Thu, Nov 15, 2012 at 6:53 PM, Peter Eisentraut wrote:
The only thing you couldn't handle that way are SIGHUP settings, but the
often-cited use cases work_mem, logging, etc. would work.
How hard would it be to make it work for
On Thu, Nov 15, 2012 at 6:42 PM, Jeff Davis wrote:
> On Tue, 2012-11-06 at 17:55 -0600, Merlin Moncure wrote:
>> So given that -- the patch simple adds an extra check when/where hint
>> bit status is checked in the visibility routines (currently, only
>> HeapTupleSatisfiesMVCC is done but all the
Le vendredi 16 novembre 2012 15:08:30, Amit Kapila a écrit :
> On Thursday, November 15, 2012 8:18 PM Amit kapila wrote:
> > On Wednesday, November 14, 2012 12:24 AM Robert Haas wrote:
> > On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila
> >
> > wrote:
> > > Uh, no, I don't think that's a good idea.
Hi,
On 2012-11-16 14:46:39 +0100, Markus Wanner wrote:
> You may have noticed that there's an additional COID field. This is an
> identifier for the transaction that last changed this tuple. Together
> with the primary key, it effectively identifies the exact version of a
> tuple (during its lifet
On Thu, Nov 15, 2012 at 4:13 PM, Peter Geoghegan wrote:
> On 15 November 2012 19:54, Greg Stark wrote:
>> The only concern I had was about the behaviour after it did the
>> special case. I didn't want it to keep doing the math and trying to
>> grow again a little bit every tuple. I think I was le
On Thu, Nov 15, 2012 at 2:54 PM, Greg Stark wrote:
> On Thu, Nov 15, 2012 at 7:36 PM, Peter Geoghegan
> wrote:
>> On 15 November 2012 19:16, Robert Haas wrote:
>>> So what's next here? Do you want to work on these issue some more?
>>> Or does Jeff? I'd like to see this go in, but I'm not sure
On Thursday, November 15, 2012 8:18 PM Amit kapila wrote:
> On Wednesday, November 14, 2012 12:24 AM Robert Haas wrote:
> On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila
> wrote:
>
> > Uh, no, I don't think that's a good idea. IMHO, what we should do is:
>
> > 1. Read postgresql.conf.auto and rem
Hi Markus,
On 2012-11-16 14:46:39 +0100, Markus Wanner wrote:
> On 11/15/2012 01:27 AM, Andres Freund wrote:
> > In response to this you will soon find the 14 patches that currently
> > implement $subject.
>
> Congratulations on that piece of work.
Thanks.
> I'd like to provide a comparison of t
On Fri, Nov 16, 2012 at 4:32 AM, Amit Kapila wrote:
> On Thursday, November 15, 2012 10:19 PM Merlin Moncure wrote:
>> On Thu, Nov 15, 2012 at 10:25 AM, Amit Kapila
>> wrote:
>
>>
>> Sure, although in scans we are using ring buffer as well so in
>> practical sense the results are pretty close.
>>
On Thursday, November 15, 2012 6:05 PM Heikki Linnakangas wrote:
> On 15.11.2012 12:44, Heikki Linnakangas wrote:
> > Here's an updated version of this patch, rebased with master,
> > including the recent replication timeout changes, and some other
> cleanup.
> >
> > On 12.10.2012 09:34, Amit Kapil
Andres,
On 11/15/2012 01:27 AM, Andres Freund wrote:
> In response to this you will soon find the 14 patches that currently
> implement $subject.
Congratulations on that piece of work.
I'd like to provide a comparison of the proposed change set format to
the one used in Postgres-R. I hope for t
Kohei KaiGai escribió:
> 2012/10/22 Alvaro Herrera :
> > Here's an updated version of this patch, which also works in
> > an EXEC_BACKEND environment. (I haven't tested this at all on Windows,
> > but I don't see anything that would create a portability problem there.)
> >
> I also tried to check
Jeff Davis writes:
> The documentation says that a materialized view is basically a
> create-table-as-select except that it remembers the query. Would you say
> that there is a compelling use case for this alone, or is this a
> building block for more sophisticated materialized view support (e.g.
On Thursday, November 15, 2012 7:29 PM Amit kapila wrote:
> On Monday, November 12, 2012 8:23 PM Fujii Masao wrote:
> On Fri, Nov 9, 2012 at 3:03 PM, Amit Kapila
> wrote:
> > On Thursday, November 08, 2012 10:42 PM Fujii Masao wrote:
> >> On Thu, Nov 8, 2012 at 5:53 PM, Amit Kapila
> >> wrote:
>
On Thursday, November 15, 2012 7:30 PM Robert Haas wrote:
On Thu, Nov 15, 2012 at 12:08 AM, Amit Kapila wrote:
>> Okay.
>> So as Robert and Alvaro suggested to have it separate utility rather than
>> having options in pg_resetxlog to print MAX LSN seems to be quite
>> appropriate.
>> I am planning
2012/10/22 Alvaro Herrera :
> Here's an updated version of this patch, which also works in
> an EXEC_BACKEND environment. (I haven't tested this at all on Windows,
> but I don't see anything that would create a portability problem there.)
>
I also tried to check the latest patch "briefly".
Let me
Hi,
On 2012-11-16 13:44:45 +0900, Michael Paquier wrote:
> This patch looks OK.
>
> I got 3 comments:
> 1) Why changing the OID of pg_class_tblspc_relfilenode_index from 3171 to
> 3455? It does not look necessary.
Its a mismerge and should have happened in "Add a new RELFILENODE
syscache to fetch
On 15 November 2012 10:10, Alvaro Herrera wrote:
> I am unsure about the amount of pre-cooked stuff we need to provide.
> For instance, do we want some easy way to let the user code run
> transactions?
That sounds like a basic requirement. There will be a few
non-transactional bgworkers but most
On Thursday, November 15, 2012 10:19 PM Merlin Moncure wrote:
> On Thu, Nov 15, 2012 at 10:25 AM, Amit Kapila
> wrote:
>
> Sure, although in scans we are using ring buffer as well so in
> practical sense the results are pretty close.
>
> > b. Considering sometimes people want VACUUM to run when
> From: Cédric Villemain [mailto:ced...@2ndquadrant.com]
> Sent: Friday, November 16, 2012 1:55 PM
> To: pgsql-hackers@postgresql.org
> Cc: Amit Kapila; 'Robert Haas'; 'Greg Smith'; 'Josh Berkus'; 'Tom Lane';
> 'Magnus Hagander'; 'Christopher Browne'
> Subject: Re: [HACKERS] Proposal for Allow post
Hello
I found so we doesn't have functionality for simply text aligning - so
I propose support width for %s like printf's behave. glibc
implementation knows a rule for precision, that I don't would to
implement, because it is oriented to bytes and not to chars - and it
can be confusing. Still I wo
On 15 November 2012 23:12, Simon Riggs wrote:
> We need detailed stats that allow many people to make their own tests
> and to report on what they find.
To work out how to proceed we need
* wait event times on clog accesses at table-level
* numbers of blocks dirtied by hint bit settings at tabl
Robert Haas wrote:
>> Here is a patch to support RFC 2255 LDAP URLs in pg_hba.conf.
> I think this is broadly reasonable, but I'm not sure this part is a
good idea:
>
> +#ifdef USE_LDAP
> +#ifndef WIN32
> +/* We use a deprecated function to keep the codepath the same as
win32. */
> +#define LDAP_
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Robert Haas writes:
> > Yeah. If we're going to do this at all, and I'm not convinced it's
> > worth the work, I think it's definitely good to support a variant
> > where we specify exactly the things that will be passed to exec().
> > There's just
Le vendredi 16 novembre 2012 07:16:09, Amit Kapila a écrit :
> On Thursday, November 15, 2012 11:28 PM Cédric Villemain wrote:
> > Le jeudi 15 novembre 2012 15:48:14, Amit kapila a écrit :
> > > On Wednesday, November 14, 2012 12:24 AM Robert Haas wrote:
> > >
> > > On Mon, Nov 12, 2012 at 10:59 P
On 11/16/2012 02:26 AM, Josh Berkus wrote:
>> Extending this to save the key/value set and most of the other data I
>> mentioned before is pretty straightforward.
> Why not use Hstore? Seriously?
The only issue I see is that hstore's text format is non-standard, not
widely understood and a pain t
Il 16/11/2012 05:34, Michael Paquier ha scritto:
Do you have a git repository or something where all the 14 patches are applied?
I would like to test the feature globally.
Sorry I recall that you put a link somewhere but I cannot remember its email...
http://archives.postgresql.org/pgsql-hacke
80 matches
Mail list logo
