Jeff Davis wrote:
On Mon, 2008-12-22 at 21:24 +0200, Heikki Linnakangas wrote:
Introduce new vacuum_freeze_max_age setting. Manual VACUUM will scan the
whole table and advance relfrozenxid, if relfrozenxid is older than
vacuum_freeze_max_age.
It's confusing to have two GUCs named vacuum_fre
Currently,
column-level privileges are not honored when JOINs are involved (you
must have the necessary table-level privileges, as you do today). It
would really be great to have that working and mainly involves
modifying the rewriter to add on to the appropriate range table column
list entries th
On Wed, 31 Dec 2008, Tom Lane wrote:
No one has asked for access to individual components of the version
string, other than the PG version number itself, which we already dealt
with.
I think I'm now up to having wrote something to break apart the output
from version() into individual fields
Hi,
On Wed, Jan 7, 2009 at 3:12 PM, Heikki Linnakangas
wrote:
> It's required by the sync replication patch, but has no value otherwise.
Yes. I'm reworking Synch Rep also including the patch.
BTW, attached is the patch.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT O
It's required by the sync replication patch, but has no value otherwise.
Bruce Momjian wrote:
Is this for 8.4?
---
Heikki Linnakangas wrote:
I've been looking at the signal handling part of the synchronous
replication pat
On Wed, Jan 7, 2009 at 1:23 AM, Bruce Momjian wrote:
> Tom Lane wrote:
>
>> As-is, this list is completely unhelpful. It looks like you've dumped
>> all your unread mail onto this page and asked the rest of us to sort it
>> for you. I'm sorry, but I've got other things to do.
>
> That explains
Based on the comments below, are we sure constraint_exclusion still
needs to be a parameter and can't be on by default?
---
Greg Smith wrote:
> On Thu, 4 Dec 2008, Gregory Stark wrote:
>
> > Greg Smith writes:
> >
> >> Is
Hiroshi Inoue wrote:
> Seems LC_CTYPE and LC_TIME should be convertible even though we use
> wcsftime (which internally calls strftime?).
Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
(at least encoding) on Windows.
The attached patch is an updated version to fix cache
> We would really appreciate help on finalizing this patch, especially in
> regard to style issues. Thank you for all the help.
Here is a cleaned-up version. I fixed a number of whitespace issues,
improved a few comments, and rearranged one set of nested if-else
statements (hopefully without bre
Is this for 8.4?
---
Heikki Linnakangas wrote:
> I've been looking at the signal handling part of the synchronous
> replication patch. It looks OK, but one thing makes me worry.
>
> To set or clear the flag from PGPROC, to
Added to TODO:
Add ability to use case-insensitive regular expressions on multi-byte
characters
ILIKE already works with multi-byte characters
*
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00433.php
-
Fujii Masao wrote:
> Hi,
>
> Attached is a simple patch to unify the log output of 'vxid' between
> csvlog and stderr/syslog. Currently, in csvlog, vxid of an auxiliary
> process isn't displayed. On the other hand, in stderr/syslog, invalid
> vxid (-1/0) of that is displayed. I'm not sure why we n
On Tue, Jan 6, 2009 at 5:54 PM, Andrew Dunstan wrote:
>
> Well, the only reason it was needed was because you can't run a parallel
> restore in a single transaction. If the whole restore is run in a single
> transaction then truncate before load should be unnecessary.
>
doesn't understand you. An
Andrew Dunstan wrote:
>
> Cleaning up the parallel restore patch I came across a question I might
> have asked before, but one which in any case I worked around:
>
> Why do we carefully define fseeko() for WIN32 but then not define
> HAVE_FSEEKO, which makes doing the former pretty much pointle
Hi,
Any one could throw some light on how the unicode support is enabled in
the postgresql code? I know that this is a step during the installation
to select the default locale of the postgresql system & other place is
during the creation of a database, there is a option to select the
languag
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > No, so that the translators don't have to worry about getting alignment
> > > right; and also so that they don't have to translate \\d[S+] etc which
> > > obviously doesn't need any translation.
> >
> > I am thinking w
Markus Wanner wrote:
Hello Stephen,
Stephen Frost wrote:
..in the attached patch.
Thanks, I've reviewed this patch again.
Please find attached an updated patch for column-level privileges
which incorporates Alvaro's suggested changes and is updated to the
latest CVS HEAD.
Cool, applies cl
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > No, so that the translators don't have to worry about getting alignment
> > right; and also so that they don't have to translate \\d[S+] etc which
> > obviously doesn't need any translation.
>
> I am thinking we can do:
>
> fprintf(output, "
Peter Eisentraut wrote:
> We could just use the dummy wrapper and set an
> option for the foreign data wrapper that tells what options are valid. That
> is, you would say
>
> CREATE FOREIGN DATA WRAPPER postgresql_dummy LIBRARY 'dummy_fdw' LANGUAGE C
> OPTIONS (valid_options '{host,port,
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > >
> > > > Informational
> > > > Modifiers: S = show system objects + = Additional detail
> > > > \l[+] list all databases
> > > > \d[S+]
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > Informational
> > > Modifiers: S = show system objects + = Additional detail
> > > \l[+] list all databases
> > > \d[S+]list tables, views, and sequences
> > > \d[S+]
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Informational
> > Modifiers: S = show system objects + = Additional detail
> > \l[+] list all databases
> > \d[S+]list tables, views, and sequences
> > \d[S+] NAME describe tab
The latest version of the patch is attached. The revision considerably
cleans up the code, especially variable naming consistency. We have
adopted the use of IM (in-memory) in variable names for the hash table
structures as suggested.
Two other implementations changes:
1) The overhead of the ha
On Tue, 2009-01-06 at 21:58 -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Informational
> > Modifiers: S = show system objects + = Additional detail
> > \l[+] list all databases
> > \d[S+]list tables, views, and sequences
> >
Alvaro Herrera wrote:
Bruce Momjian wrote:
Everyone knows about the commit fest wiki items, but I am tracking 291
threads that need some type of attention; if only 50% of them are
significant for 8.4, that still leaves +100 items that should be
completed in the next month. You can see the fu
Bruce Momjian wrote:
> Informational
> Modifiers: S = show system objects + = Additional detail
> \l[+] list all databases
> \d[S+]list tables, views, and sequences
> \d[S+] NAME describe table, view, sequence, or ind
On Tue, Jan 6, 2009 at 12:38 PM, Robert Haas wrote:
> - WIP: Hash Join-Filter Pruning using Bloom Filters is in the commitfest
I'm pulling this patch and resubmitting for 8.5.
--
Jonah H. Harris, Senior DBA
myYearbook.com
Tom Lane wrote:
>"Stephen R. van den Berg" writes:
>> BEGIN
>> vcsid:=vfrom;
>> LOOP
>> EXIT WHEN vsid IS NOT NULL OR vcsid=vold;
>> END LOOP;
>> RETURN vsid;
>> END;
>And are you certain that's never an infinite loop? The query string
>gives a starting point that one suspects doesn't ter
On Tue, 2009-01-06 at 19:13 -0500, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> >
> > Per offline comments my thoughts were something like:
> >
> > Informational: S = show system objects + = Additional detail
> > Display:
>
> I don't like the "Display:" here because it mimicks the heading ab
Joshua D. Drake wrote:
> On Tue, 2009-01-06 at 19:06 -0500, Bruce Momjian wrote:
> > Bruce Momjian wrote:
>
> > OK, done (below). 'list' seems kind of redundant. Can we factor that
> > out somehow?
> >
> > Informational
> > Modifiers: S = show system objects + = Additional detail
> >
On Tue, 2009-01-06 at 19:06 -0500, Bruce Momjian wrote:
> Bruce Momjian wrote:
> OK, done (below). 'list' seems kind of redundant. Can we factor that
> out somehow?
>
> Informational
> Modifiers: S = show system objects + = Additional detail
> \l[+] list a
Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > On Tue, 2009-01-06 at 18:08 -0500, Bruce Momjian wrote:
> > > Bruce Momjian wrote:
> >
> > > > I also found a bug that \do didn't work because the AND system table
> > > > check was being added to the LEFT JOIN and not to the WHERE clause
> > > > (
"Stephen R. van den Berg" writes:
> BEGIN
> vcsid:=vfrom;
> LOOP
> vold:=vcsid;
> SELECT INTO vcsid,vsid parent,sid
>FROM cmsstruct
>WHERE csid=vcsid
>LIMIT 1;
> EXIT WHEN vsid IS NOT NULL OR vcsid=vold;
> END LOOP;
> RETURN vsid;
> END;
And are you certain that's never an i
Tom Lane wrote:
>"Stephen R. van den Berg" writes:
>> It seems that the backend is stuck in some kind of endless loop. Since
>> it's a production Debian server, the backend is not compiled with debugging
>> turned on. The best I can do is ltrace it, in hopes of someone recognising
>> the infinit
"Nathan Boley" writes:
>> I don't think this is a bug.
> hmmm... Well, I assumed it was a bug from a comment in analyze.
> From ( near ) line 2130 in analyze.c
> * least 2 instances in the sample. Also, we won't suppress values
> * that have a frequency of at least 1/K where K is the intende
>> For heavy tailed distributions, it is possible for analyze to
>> duplicate histogram boundaries.
>
> I don't think this is a bug.
hmmm... Well, I assumed it was a bug from a comment in analyze.
>From ( near ) line 2130 in analyze.c
* least 2 instances in the sample. Also, we won't suppress
Joshua D. Drake wrote:
> On Tue, 2009-01-06 at 18:08 -0500, Bruce Momjian wrote:
> > Bruce Momjian wrote:
>
> > > I also found a bug that \do didn't work because the AND system table
> > > check was being added to the LEFT JOIN and not to the WHERE clause
> > > (trigger display was also a problem)
"Stephen R. van den Berg" writes:
> It seems that the backend is stuck in some kind of endless loop. Since
> it's a production Debian server, the backend is not compiled with debugging
> turned on. The best I can do is ltrace it, in hopes of someone recognising
> the infinite sequence.
Well, it
On Tue, 2009-01-06 at 18:08 -0500, Bruce Momjian wrote:
> Bruce Momjian wrote:
> > I also found a bug that \do didn't work because the AND system table
> > check was being added to the LEFT JOIN and not to the WHERE clause
> > (trigger display was also a problem).
>
> Let me also say that that \d
I'm running Debian PostgreSQL v8.3.5-1 on x86 in 32-bit mode.
Every once in a while, some backends start taking 100% CPU, as can be seen
below in the excerpt from the process table:
27256 ?Ss 0:04 /usr/lib/postgresql/8.3/bin/postgres -D /var/lib/post
27299 ?Ss 0:00 \_ post
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > momj...@postgresql.org (Bruce Momjian) writes:
> > > > This makes all the \dX commands (most importantly to most: \df) work
> > > > like \dt does, in that it requires a \dXS to see system items.
> > >
> > > The lack of any docum
Bruce Momjian wrote:
> Tom Lane wrote:
> > momj...@postgresql.org (Bruce Momjian) writes:
> > > This makes all the \dX commands (most importantly to most: \df) work
> > > like \dt does, in that it requires a \dXS to see system items.
> >
> > The lack of any documentation change is glaring.
>
> Oh
Jaime Casanova wrote:
On Mon, Dec 29, 2008 at 6:42 PM, Andrew Dunstan wrote:
Attached is the latest parallel restore patch. I think this is getting
fairly close.
mmm... seems this patch are two in one... you're adding --multi-thread
and --truncate-before-load options where the seco
On Mon, Dec 29, 2008 at 6:42 PM, Andrew Dunstan wrote:
>
> Attached is the latest parallel restore patch. I think this is getting
> fairly close.
>
mmm... seems this patch are two in one... you're adding --multi-thread
and --truncate-before-load options where the second one seems to be an
optimiz
On Tue, Jan 6, 2009 at 4:32 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Jaime Casanova wrote:
>>> i'm using:
>>> pg_restore -f mic.backup -Fc -v -m5
>
>> Strange. Maybe the server log will show activity?
>
> There's no connection info, so that should just print to stdout, and
> probably there
"Nathan Boley" writes:
> For heavy tailed distributions, it is possible for analyze to
> duplicate histogram boundaries.
I don't think this is a bug. You've got values that didn't make it into
the MCV list, but nonetheless occupy multiple buckets' worth of space in
the remainder of the distribut
On Tue, Jan 06, 2009 at 11:13:59PM +0530, Gurjeet Singh wrote:
> If we consider the second branch of UNION ALL of both the queries above, if
> "select '' " yields a text column, then so should a "select * from (select
> '')".
The problem is ofcourse that "select ''" doesn't produce a text column
i
Martin Pihlak writes:
> Usually it would have been the server owner who created those user
> mappings in the first place -- so the passwords are already known
> to him/her. Of course it is possible to create the mappings first
> and later change the ownership of the server, thus exposing the
> pas
Andrew Dunstan writes:
> Jaime Casanova wrote:
>> i'm using:
>> pg_restore -f mic.backup -Fc -v -m5
> Strange. Maybe the server log will show activity?
There's no connection info, so that should just print to stdout, and
probably there is no point in any parallelism. I'm guessing the -m
switch
Alvaro Herrera writes:
> They are both very lean, so no objections. I guess that the pg_type.h
> inclusion is needed due to the predefined type OIDs, and it makes me
> wonder whether it would be useful to have them in a separate header.
> Not enough concern for the idea to even make it to Bruce's
> Here's an updated version of the psql backslash patch that should
> apply cleanly to the current HEAD. To recap, this makes all the \dX
> commands (most importantly to most: \df) work like \dt does, in that it
> requires a \dXS to see system items. See the archives for much more
> discussion on t
Jaime Casanova wrote:
On Mon, Dec 29, 2008 at 6:42 PM, Andrew Dunstan wrote:
Attached is the latest parallel restore patch. I think this is getting
fairly close.
hi, i was making some tests in windows...
but for some reason the pg_restore simply hangs...
i'm using:
pg_restore -f
On Tue, Jan 6, 2009 at 4:04 PM, Jaime Casanova
wrote:
> On Mon, Dec 29, 2008 at 6:42 PM, Andrew Dunstan wrote:
>>
>> Attached is the latest parallel restore patch. I think this is getting
>> fairly close.
>>
>
> hi, i was making some tests in windows...
>
anyway, when i try it, it prints on the
>>> Paul Schlie wrote:
>> Kevin Grittner wrote:
>> There is a related thread on which I'm attempting to come up with
>> documentation to assist those familiar with true serializable
>> behavior who are attempting to recognize application coding
>> patterns where the differences between that and
On Mon, Dec 29, 2008 at 6:42 PM, Andrew Dunstan wrote:
>
> Attached is the latest parallel restore patch. I think this is getting
> fairly close.
>
hi, i was making some tests in windows...
but for some reason the pg_restore simply hangs...
i'm using:
pg_restore -f mic.backup -Fc -v -m5
there
Tom Lane wrote:
> I wrote:
> > Okay, I'll do a trial patch and we can see exactly how much has to be
> > added (at least among core and contrib) before deciding for sure.
>
> This compiles and passes regression tests. It looks like the main
> things there might be an argument for adding back to s
Peter Eisentraut wrote:
> On Tuesday 06 January 2009 18:49:00 Bruce Momjian wrote:
> > If people have further updates please, please send them (with subject
> > headings please).
>
> Most of the entries are quite frankly junk, either already committed, already
> rejected, patches not under consid
On Tuesday 06 January 2009 18:49:00 Bruce Momjian wrote:
> If people have further updates please, please send them (with subject
> headings please).
Most of the entries are quite frankly junk, either already committed, already
rejected, patches not under consideration, irrelevant discussions, or
I wrote:
> Okay, I'll do a trial patch and we can see exactly how much has to be
> added (at least among core and contrib) before deciding for sure.
This compiles and passes regression tests. It looks like the main
things there might be an argument for adding back to spi.h would be
pg_type.h and
> Kevin Grittner wrote:
Paul Schlie wrote:
>> Sorry if I'm restating the obvious, however I don't understand the
>> confusion, as it seems the standard's definition isn't mysterious;
>> it simply requires that the resulting state from the concurrent
>> execution of transactions (and implicit
On Tue, Jan 6, 2009 at 12:57, Stephen R. van den Berg wrote:
> Peter Eisentraut wrote:
>>(1) Compress everything within reason by default, causing slower retrieval, do
>>not offer substr optimization. [<= 8.3]
>
>>(2) Compress only up to 1 MB, causing faster retrieval, supporting substr
>>optimiza
Peter Eisentraut wrote:
On Tuesday 06 January 2009 05:54:14 Joe Conway wrote:
--
-- now as untrusted user dblink_regression_test
--
contrib_regression=> SELECT dblink_connect('myconn', 'fdtest');
dblink_connect
OK
(1 row)
I think you want some permission checking on fdtest
Peter Eisentraut wrote:
>(1) Compress everything within reason by default, causing slower retrieval, do
>not offer substr optimization. [<= 8.3]
>(2) Compress only up to 1 MB, causing faster retrieval, supporting substr
>optimization. [8.4devel]
>I am personally completely puzzled by option num
Tom Lane wrote:
> Bruce Momjian writes:
> > Peter Eisentraut wrote:
> >> Most of the entries are quite frankly junk,
>
> > That was the same reaction Tom had. Again, many might be junk, but is
> > it 100% junk. What about:
>
> > 8.4 - psql output for \l
>
> Done (and this is
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> >
> >> Alvaro Herrera wrote:
> >>
> >>> Andrew Dunstan wrote:
> >>>
> >>>
> I'm confused. There is a Cygwin member of buildfarm, working quite
> happily. Can you point me to the exact patch
Alvaro Herrera writes:
> Bruce Momjian wrote:
>> Tom Lane wrote:
>>> I propose changing spi.h to follow the same include-only-what-you-must
>>> rule as every other backend header file. Thoughts?
>>
>> I don't think we ever cleaned out spi.h in the past because we were
>> worried about 3rd party
Bruce Momjian wrote:
> Tom Lane wrote:
> > executor/spi.h includes far more than it needs, starting with postgres.h
> > which as a general rule we don't expect any other header file to
> > include. I think the argument for this was to keep things simple for
> > SPI-using loadable modules, but I do
Bruce Momjian writes:
> Peter Eisentraut wrote:
>> Most of the entries are quite frankly junk,
> That was the same reaction Tom had. Again, many might be junk, but is
> it 100% junk. What about:
> 8.4 - psql output for \l
Done (and this is on the commitfest page anyway)
Peter Eisentraut wrote:
> On Tuesday 06 January 2009 05:54:14 Joe Conway wrote:
>> contrib_regression=> SELECT dblink_connect('myconn', 'fdtest');
>> dblink_connect
>>
>> OK
>> (1 row)
>
> I think you want some permission checking on fdtest then, right?
>
The proposed "conne
Dmitry Koterov wrote:
> Hello.
>
> Here is the SQL to reproduce the server crash:
>
>
> CREATE SCHEMA bug1 AUTHORIZATION postgres;
>
> SET search_path = bug1, pg_catalog;
>
> CREATE FUNCTION bug1.domain_check (integer) RETURNS boolean
> AS
> $body$
> SELECT $1 <> 0
> $body$
> LANGUAGE sql IMMU
Tom Lane wrote:
> executor/spi.h includes far more than it needs, starting with postgres.h
> which as a general rule we don't expect any other header file to
> include. I think the argument for this was to keep things simple for
> SPI-using loadable modules, but I doubt that it's really improving
Tom Lane wrote:
> Peter Eisentraut writes:
>> I think you want some permission checking on fdtest then, right?
>
> What about the permissions on the system catalogs themselves?
> AFAICT, the pg_user_mappings view will expose user passwords to
> the "owner" of the foreign server, which doesn't see
I wrote:
> I tried fixing this
> http://archives.postgresql.org/pgsql-general/2009-01/msg00030.php
> by inserting SPI_push/SPI_pop calls around plperl's use of
> InputFunctionCall and OutputFunctionCall ...
> I also thought about attacking the problem by having InputFunctionCall
> and OutputFuncti
executor/spi.h includes far more than it needs, starting with postgres.h
which as a general rule we don't expect any other header file to
include. I think the argument for this was to keep things simple for
SPI-using loadable modules, but I doubt that it's really improving their
lives much. A qui
Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>>> So what do we want to do for 8.4? Add 32/64-bit version() indicator and
>>> add OUT parameters to the TODO list?
>> +1. There seems a good case for making the 32/64bit distinction
>> visible somewhere, and the text version strin
Peter Eisentraut writes:
> On Tuesday 06 January 2009 19:50:51 Tom Lane wrote:
>> What about the permissions on the system catalogs themselves?
>> AFAICT, the pg_user_mappings view will expose user passwords to
>> the "owner" of the foreign server, which doesn't seem good.
> Well, no one is forci
On Tuesday 06 January 2009 19:50:51 Tom Lane wrote:
> Peter Eisentraut writes:
> > I think you want some permission checking on fdtest then, right?
>
> What about the permissions on the system catalogs themselves?
> AFAICT, the pg_user_mappings view will expose user passwords to
> the "owner" of t
On Monday 05 January 2009 18:45:49 Alvaro Herrera wrote:
> I did some measurements months ago, and it was very clear that libz
> compression was a lot tighter than the PGLZ code.
Back to the issue at hand. The question at the top of the thread was which of
the following behaviors we'd like by de
Tom Lane wrote:
> Bruce Momjian writes:
> > I used the wording from the pg_restore SGML manual page in the --help
> > text, to be more consistent. Thanks for the report.
>
> pg_dump has the same wording. pg_dumpall might need adjustment too,
> though I'm not sure (note its --clean acts on DBs n
I have been thinking that we are setting up the foreign-data wrapper dummies
wrongly.
Eventually, the postgresql_fdw library should contain an implementation that
actually connects to a PostgreSQL database and does useful things (dblink
replacement, basically). Right now, we are proposing to u
Peter Eisentraut writes:
> I think you want some permission checking on fdtest then, right?
What about the permissions on the system catalogs themselves?
AFAICT, the pg_user_mappings view will expose user passwords to
the "owner" of the foreign server, which doesn't seem good.
On Tuesday 06 January 2009 05:54:14 Joe Conway wrote:
> --
> -- now as untrusted user dblink_regression_test
> --
> contrib_regression=> SELECT dblink_connect('myconn', 'fdtest');
> dblink_connect
>
> OK
> (1 row)
I think you want some permission checking on fdtest then, right
On Tue, Jan 6, 2009 at 7:18 PM, Tom Lane wrote:
> "Gurjeet Singh" writes:
> >> This is a horrendously bad idea; it will bite your *ss sooner or later,
> >> probably sooner.
>
> > Can you please let us know how this would be problematic?
>
> The point is that it's going to have unknown, untested
Bruce Momjian writes:
> I used the wording from the pg_restore SGML manual page in the --help
> text, to be more consistent. Thanks for the report.
pg_dump has the same wording. pg_dumpall might need adjustment too,
though I'm not sure (note its --clean acts on DBs not individual
objects)
It seems like it would be helpful if you made a pass through it
yourself just looking for duplicates and commitfest items, since it's
probably just as fast for you to find them and fix them as it is for
us to tell you about them - maybe faster, since the links on this page
don't seem to work very w
On Tue, 2009-01-06 at 11:30 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> >
> > On Tue, 2009-01-06 at 10:21 -0500, Bruce Momjian wrote:
> >
> > > I have already approached developers to get help in completing these
> > > items, but got little assistance.
> >
> > If you can send me the list
On Tue, Jan 6, 2009 at 06:43, Bruce Momjian wrote:
> Alex Hunsaker wrote:
>> This patch lets you control 3 pg_lzcompress knobs on a per table basis
>> (note requires reloptions.patch)
>
> I think we need to live with the TOAST changes for at least one release
> before we know what knobs we will ne
Is there any progress on this patch? I was asked about this feature last
month, during a PostgreSQL talk. I am willing to spend time for testing
this patch, if needed.
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz
Erik Rijkers wrote:
> The help text for the pg_restore --clean option in the documentation is IMHO
> more precise than the
> text that the pg_restore binary gives:
>
> documentation:
> -c
> --clean
>Clean (drop) database objects before recreating them.
>
> pg_restore binary:
>-c, --cle
I've rearranged the sequence of some lines in the previous post to
facilitate discussion. I hope no offense is taken.
>>> "Robert Haas" wrote:
> On further review, I actually think that our documentation is pretty
> clear about this topic, too. Everything we've talked about thus far
> all s
Robert Haas wrote:
> > Can you give subject lines on this? I didn't mean for people to
> > actually start working on items, but rather just to see the scope of the
> > problem.
>
> Hmm, well, when you are ready for people to start working on items, I
> might be able to work on some items, if ther
Bruce Momjian wrote:
> I am now warning that we have an unusually large number of open items
> that must be either completed or moved to the TODO list before 8.4 can
> be released.
>
> Everyone knows about the commit fest wiki items, but I am tracking 291
> threads that need some type of attenti
> Can you give subject lines on this? I didn't mean for people to
> actually start working on items, but rather just to see the scope of the
> problem.
Hmm, well, when you are ready for people to start working on items, I
might be able to work on some items, if there are things that a
non-core, n
Hi.
Sorry very late reaction
I report the test checked again.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/LC_MESSAGES_01.png
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/LC_MESSAGES_02.png
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/LC_M
>>> Paul Schlie wrote:
> Sorry if I'm restating the obvious, however I don't understand the
> confusion, as it seems the standard's definition isn't mysterious;
> it simply requires that the resulting state from the concurrent
> execution of transactions (and implicitly any subset) designated to
On Tue, Jan 6, 2009 at 4:12 PM, Bruce Momjian wrote:
> Dave Page wrote:
>> 243 seems like a priority for release :-p
[GENERAL] happy holidays, christmas etc.,
>> 253 was a website issue that's been fixed.
[pgsql-www] Re: [pgsql-advocacy] Problem with "File Browser" link on
downloadspage
>> 15
Dave Page wrote:
> On Tue, Jan 6, 2009 at 4:12 PM, Bruce Momjian wrote:
> > Dave Page wrote:
>
> >> 243 seems like a priority for release :-p
>
> [GENERAL] happy holidays, christmas etc.,
Removed.
> >> 253 was a website issue that's been fixed.
>
> [pgsql-www] Re: [pgsql-advocacy] Problem wit
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Everyone knows about the commit fest wiki items, but I am tracking 291
> > threads that need some type of attention; if only 50% of them are
> > significant for 8.4, that still leaves +100 items that should be
> > completed in the next month. Y
On Tue, 2009-01-06 at 10:21 -0500, Bruce Momjian wrote:
> I have already approached developers to get help in completing these
> items, but got little assistance.
If you can send me the list that you think applies to me, I'll work on
it. I don't want to spend the time to read every entry if you
Dave Page wrote:
> On Tue, Jan 6, 2009 at 3:21 PM, Bruce Momjian wrote:
> > I am now warning that we have an unusually large number of open items
> > that must be either completed or moved to the TODO list before 8.4 can
> > be released.
> >
> > Everyone knows about the commit fest wiki items, but
1 - 100 of 134 matches
Mail list logo
