=?ISO-8859-1?Q?Benedek_L=E1szl=F3?= l...@benedekl.tvnetwork.hu 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,
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 trouble is,
On Mon, Jan 5, 2009 at 3:18 AM, Stephen R. van den Berg s...@cuci.nl 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
Douglas McNaught wrote:
On Mon, Jan 5, 2009 at 3:18 AM, Stephen R. van den Berg s...@cuci.nl 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
Andrew Dunstan wrote:
Douglas McNaught wrote:
On Mon, Jan 5, 2009 at 3:18 AM, Stephen R. van den Berg s...@cuci.nl
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
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 be possible to have a
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.
+1 it
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
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
On Mon, Jan 5, 2009 at 4:44 AM, KaiGai Kohei kai...@ak.jp.nec.com 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
Bruce Momjian br...@momjian.us 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
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)
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
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
sideeffects.
I
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,
Douglas McNaught d...@mcnaught.org 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
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 they
see
Tom Lane t...@sss.pgh.pa.us wrote:
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp 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
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
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
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
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
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]
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
Robert Haas robertmh...@gmail.com 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:
Robert Haas robertmh...@gmail.com 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
Gregory Stark wrote:
Peter Eisentraut pete...@gmx.net 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
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 the
Tom Lane t...@sss.pgh.pa.us 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
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
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.
Zdenek
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 robertmh...@gmail.com 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
Bruce Momjian br...@momjian.us 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
* Peter Eisentraut pete...@gmx.net [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
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,
Robert Haas wrote:
On Mon, Jan 5, 2009 at 4:44 AM, KaiGai Kohei kai...@ak.jp.nec.com 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
On Sat, Jan 3, 2009 at 1:32 AM, Alex Hunsaker bada...@gmail.com wrote:
On Fri, Jan 2, 2009 at 18:46, Tom Lane t...@sss.pgh.pa.us 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
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
Bruce Momjian píše v st 31. 12. 2008 v 11:22 -0500:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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.,
On Mon, Jan 5, 2009 at 2:02 PM, Gregory Stark st...@enterprisedb.com 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:
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 mean by
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.
IMHO,
On Mon, Jan 5, 2009 at 11:45 AM, Alvaro Herrera
alvhe...@commandprompt.com 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:
Peter Eisentraut pete...@gmx.net 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
Pavel Stehule pavel.steh...@gmail.com 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,
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
Alvaro Herrera wrote:
On Sat, Jan 3, 2009 at 17:56, Lasse Reinhold l...@quicklz.com 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
2009/1/5 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
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
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Tom Lane t...@sss.pgh.pa.us 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
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 least one
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 makes
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 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
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
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
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* 50% of the
Mark Mielke m...@mark.mielke.cc 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
Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
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, Custom
Alvaro Herrera alvhe...@commandprompt.com 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
Gregory Stark st...@enterprisedb.com 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.
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
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
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.
Rushabh Lathia rushabh.lat...@gmail.com 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
Gregory Stark wrote:
Mark Mielke m...@mark.mielke.cc 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
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
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
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
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 notion
The attached applied patch prevents a compiler warning; the compiler
doesn't know about our elog(ERROR) exit case.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be
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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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
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 official
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.
Agreed. I
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 break for a
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
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 minimum
Robert Haas robertmh...@gmail.com 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
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
Hello
2009/1/6 Gurjeet Singh singh.gurj...@gmail.com:
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
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 pavel.steh...@gmail.comwrote:
Hello
2009/1/6 Gurjeet Singh singh.gurj...@gmail.com:
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
Robert Haas robertmh...@gmail.com 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.
87 matches
Mail list logo
