> "Robert Haas" writes:
>
>> not compressing very small datums (< 256 bytes) also seems smart,
>> since that could end up producing a lot of extra compression attempts,
>> most of which will end up saving little or no space.
That was presumably the rationale for the original logic. However exper
2009/1/6 Gurjeet Singh :
> As I mentioned, we cannot change the query, so adding casts to the query is
> not an option. I was looking for something external to the query, like a
> CREATE CAST command that'd resolve the issue.
I am sorry, I blind - I tested casting on 8.3.0 and it doesn't work
(but
As I mentioned, we cannot change the query, so adding casts to the query is
not an option. I was looking for something external to the query, like a
CREATE CAST command that'd resolve the issue.
Best regards,
On Tue, Jan 6, 2009 at 12:00 PM, Pavel Stehule wrote:
> Hello
>
> 2009/1/6 Gurjeet Sing
Hello
2009/1/6 Gurjeet Singh :
> Q1: select '' union all select ''
> Q2: select '' union all select * from (select '' ) as s
>
> version: PostgreSQL 8.3.1, compiled by Visual C++ build 1400
>
> Hi All,
>
> Q1 works just fine, but Q2 fails with:
>
> ERROR: failed to find conversion function fr
Q1: select '' union all select ''
Q2: select '' union all select * from (select '' ) as s
version: PostgreSQL 8.3.1, compiled by Visual C++ build 1400
Hi All,
Q1 works just fine, but Q2 fails with:
ERROR: failed to find conversion function from "unknown" to text
Q2 is a generalization
"Robert Haas" writes:
> After reading these discussions, I guess I still don't understand why
> we would treat small and large datums differently. It seems to me
> that you had it about right here:
> http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php
> # Or maybe it should just be
Robert Haas wrote:
> > After poking around in those threads a bit, I think that the current
> > threshold of 1MB was something I just made up on the fly (I did note
> > that it needed tuning...). Perhaps something like 10MB would be a
> > better default. Another possibility is to have different m
Peter Eisentraut wrote:
Joe Conway wrote:
I'm mainly concerned about re-opening security holes that we spent a
lot of time debating and subsequently closing. I suspect if we assume
that any FDW-derived connect string can bypass the checks we put in
place, we will regret it later. But I'm open
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > The attached applied patch prevents a compiler warning; the compiler
> > doesn't know about our elog(ERROR) exit case.
>
> Hmm, I don't like your fix; ISTM it would be better to set the variable
> only in the default: case (or maybe change the "bre
> > These files are outdated and are not necessarily living there since
> > the official docs are now provided as SGML files (Japanese docs are
> > provided by JPUG).
> >
> > For these reasons I propose to remove them. Unless there's an
> > objection, I will commit the removal into CVS Head.
>
>
Tatsuo Ishii wrote:
> Hi,
>
> There are some Japanese README files in contrib module:
>
> contrib/pgbench/README.pgbench_jis
> contrib/pgrowlocks/README.pgrowlocks.euc_jp
> contrib/pgstattuple/README.pgstattuple.euc_jp
>
> These files are outdated and are not necessarily living there since
> the
Bruce Momjian wrote:
> The attached applied patch prevents a compiler warning; the compiler
> doesn't know about our elog(ERROR) exit case.
Hmm, I don't like your fix; ISTM it would be better to set the variable
only in the default: case (or maybe change the "break" for a "return").
--
Alvaro H
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 string is as good as anyplac
Hi,
There are some Japanese README files in contrib module:
contrib/pgbench/README.pgbench_jis
contrib/pgrowlocks/README.pgrowlocks.euc_jp
contrib/pgstattuple/README.pgstattuple.euc_jp
These files are outdated and are not necessarily living there since
the official docs are now provided as SGML
The attached applied patch prevents a compiler warning; the compiler
doesn't know about our elog(ERROR) exit case.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Inde
> I suggest that before we make any knee-jerk responses, we need to go
> back and reread the prior discussion.
> http://archives.postgresql.org/pgsql-patches/2008-02/msg00053.php
> and that message links to several older threads that were complaining
> about the 8.3 behavior. In particular the not
Tom Lane wrote:
> Alvaro Herrera writes:
> > Bruce Momjian wrote:
> >> gmake: *** [install] Segmentation fault
>
> > Your make is buggy?
>
> I'm not totally sure, but I think this is make reporting that install
> crashed. Perhaps a corrupted install executable?
Turns out the cause was a buggy
Bruce Momjian wrote:
Now that we are two months into the final commit fest, it is time to
finalize all the open patches so we can target a February beta.
The two major outstanding patches are:
o SE-PostgreSQL: The author has done an outstanding job of
reworking the patch so the burden
Holger Hoffstaette wrote:
On Mon, 05 Jan 2009 13:44:57 -0500, Andrew Chernow wrote:
Robert Haas wrote:
What we do have is a suggestion from several people that the database
shouldn't be in the business of compressing data AT ALL. If we want
DB2 users generally seem very happy with the built
Gregory Stark wrote:
Mark Mielke writes:
It seems to me that transparent file system compression doesn't have limits
like "files must be less than 1 Mbyte to be compressed". They don't exhibit
poor file system performance.
Well I imagine those implementations are more complex than toa
"Rushabh Lathia" writes:
> Following test returns wrong result ..
Ooops, seems we forgot to add default arguments recursively.
Fixed, thanks for the report!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
On Mon, 2009-01-05 at 17:12 -0800, Josh Berkus wrote:
> -- B-Tree GIN (this was reviewed late, so Oleg may fix it)
This one is really pretty much ready. The only reason I didn't pass it
along for committer review are a couple very minor things that I thought
the authors might want to comment on. I
Bruce,
Aside from the big patches you mentioned.
The following patches do not appear to be ready to commit based on most
recent feedback, and should probably be deferred for 8.5:
-- Column-Level permissions
-- Automatic View Update Rules
-- GIN Fast Insert
-- On-Disk Bitmap Index (Gianni says
I just wanted to give you guys a virtual pat on the back for PG
v8.4dev. I've been out of the computer world for a little over a year
and we're still using v8.1 here where I work, so I'm a little behind
the changes timeline since v8.1, but v8.4 is looking very nice.
I'm working on migratin
Gregory Stark writes:
> Hm, It occurs to me we could almost use the existing code. Just store it as a
> regular uncompressed external datum but allow the toaster to operate on the
> data column (which it's normally not allowed to) to compress it, but not store
> it externally.
Yeah, it would be v
Alvaro Herrera writes:
> Bruce Momjian wrote:
>> gmake: *** [install] Segmentation fault
> Your make is buggy?
I'm not totally sure, but I think this is make reporting that install
crashed. Perhaps a corrupted install executable?
regards, tom lane
--
Sent via pgsql-ha
Bruce Momjian wrote:
> gmake: *** [install] Segmentation fault
> $
>
> I rebooted my server but it didn't help. All this just started today.
Your make is buggy?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custo
Tom Lane wrote:
>"Robert Haas" writes:
>> The whole thing got started because Alex Hunsaker pointed out that his
>> database got a lot bigger because we disabled compression on columns >
>> 1MB. It seems like the obvious thing to do is turn it back on again.
>After poking around in those threads
Mark Mielke writes:
> It seems to me that transparent file system compression doesn't have limits
> like "files must be less than 1 Mbyte to be compressed". They don't exhibit
> poor file system performance.
Well I imagine those implementations are more complex than toast is. I'm not
sure what l
A.M. wrote:
>On Jan 5, 2009, at 1:16 PM, Stephen R. van den Berg wrote:
>>Upon reading the DFSG, it seems you have a point...
>>However...
>>QuickLZ is dual licensed:
>>a. Royalty-free-perpetuous-use as part of the PostgreSQL backend or
>> any derived works of PostgreSQL which link in *at least* 5
Guaranteed compression of large data fields is the responsibility of the
client. The database should feel free to compress behind the scenes if
it turns out to be desirable, but an expectation that it compresses is
wrong in my opinion.
That said, I'm wondering why compression has to be a probl
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 occur at the
isolation level SERI
I am seeing the following segmentation fault when doing 'gmake install'
on CVS HEAD; any idea why?
$ gmake install
/bin/sh ../config/mkinstalldirs '/usr/local/pgsql/lib/pgxs/src'
/bin/sh ../config/install-sh -c -m 644 Makefile.global
'/usr/local/pgsql/lib/pgxs/src/Makefil
Peter Eisentraut wrote:
> Martin Pihlak wrote:
>>> I would call it something like
>>>
>>> pg_postgresql_fdw_options_string(server, user) returns text
>>
>> Hmm, it is probably a good idea to avoid the fdw abbreviation -- the term
>> "foreign data wrapper" is already confusing enough. My suggestion:
I wrote:
> I rememebered what INFO is for: it's the elevel that VACUUM VERBOSE
> uses to ensure that its output gets seen at the client. (I missed
> that in my first grep because vacuum's elog/ereport calls don't use
> INFO as a hard-wired elevel.) So we probably can't get rid of it.
> But that m
On Mon, 2009-01-05 at 13:04 -0500, Robert Haas wrote:
> > Are
> > we willing to be dropped from Debian and possibly Red Hat if this is
> > the case?
> Regardless of whether we do that or not, no one has offered any
> justification of the arbitrary decision not to compress columns >1MB,
> and at le
On Mon, 2009-01-05 at 15:05 -0500, Bruce Momjian wrote:
> I assume hot standby is ready for review/commit.
It's in good shape, yes.
With such a large patch I don't expect review->commit to be a single
iteration. Though that isn't because I think there is flaky stuff in
there, just that review
2009/1/5 Tom Lane :
> "Pavel Stehule" writes:
>> I am thinking about reimplementation PL/pgPSM, where code should be
>> shared with PL/pgSQL. I have idea of some middle language, that should
>> be used for both languages. This language could be based on SPI
>> interface with some procedural elemen
On Mon, 2009-01-05 at 19:27 +, Simon Riggs wrote:
> There's a long standing requirement for filtering WAL records during
> recovery, allowing us to select databases, tables etc.
>
> My approach to this has been to submit a patch for rmgr plugins.
>
> The patch has other good uses too, most e
"Pavel Stehule" writes:
> I am thinking about reimplementation PL/pgPSM, where code should be
> shared with PL/pgSQL. I have idea of some middle language, that should
> be used for both languages. This language could be based on SPI
> interface with some procedural elements (if, jmp, return).
You
On Mon, 05 Jan 2009 13:44:57 -0500, Andrew Chernow wrote:
> Robert Haas wrote:
>>
>> What we do have is a suggestion from several people that the database
>> shouldn't be in the business of compressing data AT ALL. If we want
DB2 users generally seem very happy with the built-in compression.
>
Simon Riggs wrote:
>
> On Sat, 2009-01-03 at 22:34 -0500, Bruce Momjian wrote:
>
> > o Recovery, Replication, Hot Standby: We need a _final_ version
> > of any patches that are targeted for 8.4. There is so much activity in
> > this area I am unclear what is ready for 8.4.
>
> What do we m
On Mon, Jan 5, 2009 at 2:02 PM, Gregory Stark wrote:
>> Regardless of whether we do that or not, no one has offered any
>> justification of the arbitrary decision not to compress columns >1MB,
>
> Er, yes, there was discussion before the change, for instance:
>
> http://archives.postgresql.org/pg
Bruce Momjian writes:
> Tom Lane wrote:
>> (I'm actually kind of wondering what the INFO elog level is good for,
>> as this is just about the only use and it seems wrong.)
> +1 for one less logging level.
I rememebered what INFO is for: it's the elevel that VACUUM VERBOSE
uses to ensure that its
"Robert Haas" writes:
> I haven't looked at the patches, but one thing I'm concerned about is
> the fact that it seems we still don't have a working implementation of
> non-SEPostgresql column-level privileges. Apparently, the latest
> patch set from Stephen Frost doesn't handle those permissions
There's a long standing requirement for filtering WAL records during
recovery, allowing us to select databases, tables etc.
My approach to this has been to submit a patch for rmgr plugins.
The patch has other good uses too, most especially being able to decode
WAL records by having access to a
"Robert Haas" writes:
> The whole thing got started because Alex Hunsaker pointed out that his
> database got a lot bigger because we disabled compression on columns >
> 1MB. It seems like the obvious thing to do is turn it back on again.
I suggest that before we make any knee-jerk responses, we
"Robert Haas" writes:
> Regardless of whether we do that or not, no one has offered any
> justification of the arbitrary decision not to compress columns >1MB,
Er, yes, there was discussion before the change, for instance:
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php
An
On Jan 5, 2009, at 1:16 PM, Stephen R. van den Berg wrote:
Upon reading the DFSG, it seems you have a point...
However...
QuickLZ is dual licensed:
a. Royalty-free-perpetuous-use as part of the PostgreSQL backend or
any derived works of PostgreSQL which link in *at least* 50% of the
origina
Hello,
I am thinking about reimplementation PL/pgPSM, where code should be
shared with PL/pgSQL. I have idea of some middle language, that should
be used for both languages. This language could be based on SPI
interface with some procedural elements (if, jmp, return).
sample
create or replace fu
Robert Haas wrote:
What we do have is a suggestion from several people that the database
shouldn't be in the business of compressing data AT ALL. If we want
+1
IMHO, this is a job for the application. I also think the current
implementation is a little odd in that it only compresses data o
On Mon, 2009-01-05 at 18:24 +0100, Zeugswetter Andreas OSB sIT wrote:
> > Logically, "xmin horizon" conflicts could be flexible/soft.
> > That is, if we implemented the idea to store a lastCleanedLSN for each
> > buffer then
> > "xmin horizon" conflicts would be able to continue executing until
"Douglas McNaught" writes:
> I think Postgres becomes non-DFSG-free if this is done. All of a
> sudden one can't pull arbitrary pieces of code out of PG and use them
> in other projects (which I'd argue is the intent if not the letter of
> the DFSG). Have we ever allowed code in on these terms b
On Sat, 2009-01-03 at 22:34 -0500, Bruce Momjian wrote:
> o Recovery, Replication, Hot Standby: We need a _final_ version
> of any patches that are targeted for 8.4. There is so much activity in
> this area I am unclear what is ready for 8.4.
What do we mean by _final_? This a serious, p
Douglas McNaught wrote:
>> "Grant license to use the code in question without cost, provided that
>> the code is being linked to at least 50% of the PostgreSQL code it is
>> being distributed alongside with."
>> This should allow commercial reuse in derived products without undesirable
>> sideef
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 string is as good as anyplace.
I think the business abo
> Are
> we willing to be dropped from Debian and possibly Red Hat if this is
> the case?
No. I frankly think this discussion is a dead end.
The whole thing got started because Alex Hunsaker pointed out that his
database got a lot bigger because we disabled compression on columns >
1MB. It seems
Andrew Dunstan wrote:
Douglas McNaught wrote:
On Mon, Jan 5, 2009 at 3:18 AM, Stephen R. van den Berg
wrote:
I'm not speaking for Lasse, merely providing food for thought, but it
sounds
feasible to me (and conforming to Lasse's spirit of his intended
license)
to put something like the fol
Douglas McNaught wrote:
On Mon, Jan 5, 2009 at 3:18 AM, Stephen R. van den Berg wrote:
I'm not speaking for Lasse, merely providing food for thought, but it sounds
feasible to me (and conforming to Lasse's spirit of his intended license)
to put something like the following license on his c
On Mon, Jan 5, 2009 at 3:18 AM, Stephen R. van den Berg wrote:
> I'm not speaking for Lasse, merely providing food for thought, but it sounds
> feasible to me (and conforming to Lasse's spirit of his intended license)
> to put something like the following license on his code, which would allow
> i
> Logically, "xmin horizon" conflicts could be flexible/soft.
> That is, if we implemented the idea to store a lastCleanedLSN for each buffer
> then
> "xmin horizon" conflicts would be able to continue executing until they
> see a buffer with buffer.lastCleanedLSN > conflictLSN.
I think the tro
Tom Lane writes:
> 2. I'm unconvinced by the proposed changes to accumulate backend-local
> I/O counters, too. The fact of the matter is that those counters are
> left over from Berkeley days, a time when PG hackers tended to do their
> performance measurements in standalone backends (!). They'
=?ISO-8859-1?Q?Benedek_L=E1szl=F3?= writes:
> Here is an updated patch, which deals with 's in the rolename.
Committed with revisions as per subsequent discussion: pg_restore has
its own switch and there's no change in archive contents.
regards, tom lane
--
Sent via pgs
On Mon, Jan 5, 2009 at 11:45 AM, Alvaro Herrera
wrote:
> Peter Eisentraut escribió:
>> James Mansion wrote:
>>> Peter Eisentraut wrote:
> c. Are there any well-known pitfalls/objections which would prevent
> me from
>changing the algorithm to something more efficient (read: IO-boun
Robert Haas wrote:
> On Mon, Jan 5, 2009 at 4:44 AM, KaiGai Kohei wrote:
> > BTW, what is the currect status of my patches?
> > I guess you have many comments in the five patches, because they are a bit
> > large to be commited obviously.
> > Could you tell me, even if these are not comprehensive
Peter Eisentraut escribió:
> James Mansion wrote:
>> Peter Eisentraut wrote:
c. Are there any well-known pitfalls/objections which would prevent
me from
changing the algorithm to something more efficient (read: IO-bound)?
>>>
>>> copyright licenses and patents
>>>
>> Would it
James Mansion wrote:
Peter Eisentraut wrote:
c. Are there any well-known pitfalls/objections which would prevent
me from
changing the algorithm to something more efficient (read: IO-bound)?
copyright licenses and patents
Would it be possible to have a plugin facility?
Well, befo
Tom Lane wrote:
> I notice that EmitWarningsOnPlaceholders produces its warning messages
> at elog level INFO, which makes it nearly useless for bogus custom
> variable settings for a preloaded module: the only place such a module
> can warn is in the postmaster log, but INFO is too low to go into
On Mon, Jan 5, 2009 at 4:44 AM, KaiGai Kohei wrote:
> BTW, what is the currect status of my patches?
> I guess you have many comments in the five patches, because they are a bit
> large to be commited obviously.
> Could you tell me, even if these are not comprehensive ones.
I haven't looked at th
Hi All,
Following test returns wrong result ..
Testcase ( on 8.4 cvs head )
===
CREATE OR REPLACE FUNCTION f1(retval VARCHAR DEFAULT 'Argument') RETURNS
VARCHAR as
$$
BEGIN
return retval;
END;
$$ LANGUAGE plpgsql;
CREATE OR REPLACE FUNCTION f2(p1 IN int, p2 IN VARCHAR DEFAU
On Sat, Jan 3, 2009 at 1:32 AM, Alex Hunsaker wrote:
> On Fri, Jan 2, 2009 at 18:46, Tom Lane wrote:
>>
>> It would be fairly easy, I think, to add some reloption fields that
>> would let these parameters be controlled on a per-table level.
>
> +1
>
> Or something easier that just lets you use PG
Gregory Stark wrote:
Peter Eisentraut writes:
On Friday 02 January 2009 06:49:57 Greg Stark wrote:
The guc run-time check is checking for known-buggy versions of glibc
using sysconf to check what version of glibc you have.
Could you please mention the bug number in the relevant source code
Zdenek Kotala wrote:
>
> Alvaro Herrera p??e v st 31. 12. 2008 v 12:54 -0300:
>
> > Maybe we could have a separate function which returned the info in
> > various columns (OUT params). Maybe it would be useful to normalize the
> > info as reported the buildfarm, which right now is a bit ad-hoc.
Joe Conway wrote:
> I'm mainly concerned about re-opening security holes that we spent a lot
> of time debating and subsequently closing. I suspect if we assume that
> any FDW-derived connect string can bypass the checks we put in place, we
> will regret it later. But I'm open to arguments on both
Joe Conway wrote:
I'm mainly concerned about re-opening security holes that we spent a lot
of time debating and subsequently closing. I suspect if we assume that
any FDW-derived connect string can bypass the checks we put in place, we
will regret it later. But I'm open to arguments on both side
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 need to change
a display of vxid
Martin Pihlak wrote:
I would call it something like
pg_postgresql_fdw_options_string(server, user) returns text
Hmm, it is probably a good idea to avoid the fdw abbreviation -- the term
"foreign data wrapper" is already confusing enough. My suggestion:
pg_foreign_server_conninfo(server)
pg_fo
* Peter Eisentraut [090102 18:33]:
> On Friday 02 January 2009 23:33:34 Aidan Van Dyk wrote:
> > Has this gone anywhere? Is the CVS repo safe yet?
>
> Nothing has been done about this.
So, what's the concensus. Are we(you,everybody?) going to leave the CVS
repo alone, or is someone going to mu
>>> Peter Eisentraut wrote:
> A language lawyer might also point out that the note that contains
> the "explicitness" isn't actually part of the formal standard. The
only
> thing that the standard formally defines are the excluded phenomena.
Previously quoted, from the standard:
"The execut
Alvaro Herrera píše v st 31. 12. 2008 v 12:54 -0300:
> Maybe we could have a separate function which returned the info in
> various columns (OUT params). Maybe it would be useful to normalize the
> info as reported the buildfarm, which right now is a bit ad-hoc.
+1 it sounds good.
Zden
Tom Lane wrote:
> ITAGAKI Takahiro writes:
> > If we set shared_preload_libraries or local_preload_libraries to
> > load some modules, "loaded library" messages are logged in server
> > log every new connections and autovacuum workers.
>
> Yeah, I was noticing that myself while testing pg_stat
I updates patch set of SE-PostgreSQL and related stuff (r1386).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1386.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1386.patch
[3/5]
http://sepgsql.googlecode.com/files/sepostgresql-policy
Alvaro Herrera wrote:
>> On Sat, Jan 3, 2009 at 17:56, Lasse Reinhold wrote:
>> > That sounds really exciting, I'd love to see QuickLZ included into
>> > PostgreSQL. I'd be glad to offer support and add custom optimizations,
>> > features or hacks or whatever should turn up.
>> > My only concern
KaiGai Kohei wrote:
> If the caller allocates a surplus area to store string on tail of the
> StdRdOptions (or others), the string option can be represented as an
> offset value and should be accessed via macros, like:
Excellent. I thought about storing an offset but I didn't know how to
make it
Bruce Momjian píše v st 31. 12. 2008 v 11:22 -0500:
> Tom Lane wrote:
> > Peter Eisentraut writes:
> > > On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
> > >> PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
> >
> > > Maybe we should separate all that, e.g.,
I notice that EmitWarningsOnPlaceholders produces its warning messages
at elog level INFO, which makes it nearly useless for bogus custom
variable settings for a preloaded module: the only place such a module
can warn is in the postmaster log, but INFO is too low to go into the
postmaster log by de
ITAGAKI Takahiro writes:
> Tom Lane wrote:
>> Yeah, I was noticing that myself while testing pg_stat_statements.
>> I agree that we should fix it to reduce the message level for reloads
>> occurring in child processes. I'd suggest using DEBUG2 if
>> (IsUnderPostmaster && process_shared_preload_l
87 matches
Mail list logo
