I updated patch set of SE-PostgreSQL and related stuff (r1389).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1389.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1389.patch
[3/5]
http://sepgsql.googlecode.com/files/sepostgresql-policy
Tom Lane wrote:
> "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 ha
I took your cue, and have formulated this solution for 8.3.1 :
create or replace function unknown2text(unknown) returns text as
$$ begin return text($1::char); end $$ language plpgsql;
drop cast (unknown as text);
create cast (unknown as text) with function unknown2text( unknown ) as
implicit;
On Tue, Jan 6, 2009 at 2:04 AM, Gurjeet Singh wrote:
> I took your cue, and have formulated this solution for 8.3.1 :
Is there a good reason you're running against a db version with known
bugs instead of 8.3.5? Seriously, it's an easy upgrade and running a
version missing over a year of updates
On Tue, Jan 6, 2009 at 2:43 PM, Scott Marlowe wrote:
> On Tue, Jan 6, 2009 at 2:04 AM, Gurjeet Singh
> wrote:
> > I took your cue, and have formulated this solution for 8.3.1 :
>
> Is there a good reason you're running against a db version with known
> bugs instead of 8.3.5? Seriously, it's an e
On Tue, Jan 6, 2009 at 2:24 AM, Gurjeet Singh wrote:
> On Tue, Jan 6, 2009 at 2:43 PM, Scott Marlowe
> wrote:
>>
>> On Tue, Jan 6, 2009 at 2:04 AM, Gurjeet Singh
>> wrote:
>> > I took your cue, and have formulated this solution for 8.3.1 :
>>
>> Is there a good reason you're running against a db
Stephen R. van den Berg wrote:
>
> I asked the author of the QuickLZ algorithm about licensing...
> Sounds like he is willing to cooperate. This is what I got from him:
>
> On Sat, Jan 3, 2009 at 17:56, Lasse Reinhold wrote:
>> Hi Stephen,
>>
>> That sounds really exciting, I'd love to see Qu
I notice that if an ERROR occurs during ProcessCatchupEvent() then the
messages back to client get out of sync with each other. I've inserted
an optional error into ProcessCatchupEvent() to show what happens
(attached).
> postgres=# begin;
> BEGIN
> postgres=# d;
> ERROR: an error occurred while
On Mon, 2009-01-05 at 17:12 -0800, Josh Berkus wrote:
> -- Reducing some DDL Locks to ShareLock (remaining unapplied portions)
This just needs some testing by me, so don't kick this one out please.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
S
KaiGai Kohei wrote:
> Alvaro, could you check the patched code on reloptions.h, reloptions.c
> and rel.h? It is a working example of string reloptions, and I could
> found a few strange codes.
I'm intending to revisit the string code ... I was thinking yesterday
night that I shouldn't have commit
"Gurjeet Singh" writes:
> create cast (unknown as text) with function unknown2text( unknown ) as
> implicit;
This is a horrendously bad idea; it will bite your *ss sooner or later,
probably sooner.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
Simon Riggs writes:
> On Mon, 2009-01-05 at 17:12 -0800, Josh Berkus wrote:
>> -- Reducing some DDL Locks to ShareLock (remaining unapplied portions)
> This just needs some testing by me, so don't kick this one out please.
The point of the discussion is that we are not going to wait too darn
muc
Alvaro Herrera wrote:
KaiGai Kohei wrote:
Alvaro, could you check the patched code on reloptions.h, reloptions.c
and rel.h? It is a working example of string reloptions, and I could
found a few strange codes.
I'm intending to revisit the string code ... I was thinking yesterday
night that I s
Some further reflection about Rushabh Lathia's bug report of yesterday
led me to the realization that there's a pretty big hole in the function
defaults patch. Since we add default values during planning, it doesn't
work for any expression that's not fed through the planner. For
instance, ALTER C
On Tue, Jan 6, 2009 at 6:31 PM, Tom Lane wrote:
> "Gurjeet Singh" writes:
> > create cast (unknown as text) with function unknown2text( unknown ) as
> > implicit;
>
> This is a horrendously bad idea; it will bite your *ss sooner or later,
> probably sooner.
>
>regards, to
Alex Hunsaker wrote:
> This patch lets you control 3 pg_lzcompress knobs on a per table basis
> (note requires reloptions.patch)
>
> compress_max_size: Controls the maximum size to be considered for
> TOAST compression.
> compress_min_rate: Minimum compression rate (0-100%) required for
> TOAST c
"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 effects on the
default coercion rules, possibly leading to sil
Simon Riggs wrote:
On Wed, 2008-12-31 at 21:45 +0200, Heikki Linnakangas wrote:
Can I fix?
Yes please.
Fix attached.
--- 183,192
* number of pages. Otherwise, the time taken isn't worth it.
*/
possibly_freeable = vacrelstats->rel_pages -
vacrelstats->nonemp
On Tue, 2009-01-06 at 15:48 +0200, Heikki Linnakangas wrote:
> How about simply:
OK
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
--On Montag, Januar 05, 2009 17:12:27 -0800 Josh Berkus
wrote:
-- Automatic View Update Rules
I'm currently adressing the issues Jaime mentioned and will provide an
updated patch very soon.
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Tom Lane wrote:
The minimum-code-change solution would be to run around and try to make
sure every such expression gets passed through eval_const_expressions()
before we try to execute it. This is probably doable (looking for calls
to fix_opfuncids would be a good guide) but it seems like the po
Simon Riggs writes:
> It looks to me that generating a single error message while idle causes
> the server to provide ErrorResponse, which the client assumes is the end
> of the processing of that statement as defined in FE/BE protocol.
Yeah. I think this is actually a client-side issue: it shou
>>> 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 experience
> shows that the
Heikki Linnakangas writes:
> That seems ok to me. Calling eval_const_expressions() in ALTER COLUMN
> and elsewhere is a good idea for performance reasons as well.
Yeah, probably so.
> I can only find one more call to fix_opfuncids, where we're not already
> calling eval_const_expressions(): Ge
After various discussions over last few months, it's now time to
finalise the way we handle query conflicts in Hot Standby.
Please can interested people read
http://wiki.postgresql.org/wiki/Hot_Standby#Query_Conflicts
which is user docs for how HS will handle this. Remember we're nearly in
beta, s
On Tue, 2009-01-06 at 09:44 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > It looks to me that generating a single error message while idle causes
> > the server to provide ErrorResponse, which the client assumes is the end
> > of the processing of that statement as defined in FE/BE protocol.
>
Robert Haas escribió:
> char(n) is kind of a wierd case because you could also compress by
> storing a count of the trailing spaces, without applying a
> general-purpose compression algorithm. But either way the field is no
> longer fixed-width, and therefore field access can't be done as a
> sim
Simon Riggs wrote:
On Tue, 2009-01-06 at 15:48 +0200, Heikki Linnakangas wrote:
How about simply:
OK
Committed and backpatched all the way back to 7.4 stable.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
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 attention; if only 50% of them are
sign
Bruce Momjian writes:
> 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 full list here:
>
Tom Lane wrote:
> Bruce Momjian writes:
> > 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
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 full list here:
>
I realize the list is incomplete and inaccurate. My point is if only
50% need work, we still have lots of work to do.
I will update my mailbox and post a new version soon.
---
Alvaro Herrera wrote:
> Bruce Momjian 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 I am tracking 291
> threads
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
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
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
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
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
>>> 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
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
> 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
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
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
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
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
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
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
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
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
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)
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
> 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
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
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
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
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
"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 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
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
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
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
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
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
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
"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
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)
>> 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
"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
1 - 100 of 134 matches
Mail list logo
