Is there any reason that the zone.tab information is not included in the
pg_timezone_names system view? ISTM that there is really no reason not
to, as that view is really populated using that file anyway. There is a
1:1 mapping (assuming the aliases are mapped to the zone.tab entries
they are
Tom Lane wrote:
Michael Akinde [EMAIL PROTECTED] writes:
INFO: vacuuming pg_catalog.pg_largeobject
ERROR: out of memory
DETAIL: Failed on request of size 536870912
Are you sure this is a VACUUM FULL, and not a plain VACUUM?
Very sure.
Ran a VACUUM FULL again yesterday (the prior query was
On Jan 8, 4:14 am, [EMAIL PROTECTED] (Tom Lane) wrote:
[EMAIL PROTECTED] writes:
I am using tsearch2 with pgsql 8.2.5 and get the following error when
calling to_tsvector :
translation failed from server encoding to wchar_t
My database is UTF8 encoded and the data sent to to_tsvector
Sorry to reply, but there should also be a field in the system view
is_alias so that devs are able to tell which zone names are in the
zone.tab file and which are not. That way a perfect 1:1 mapping between
zone.tab and app can be made. If this were done then it'd make things
like using CLDR
On Mon, Jan 07, 2008 at 04:24:13PM -0800, Darcy Buskermolen wrote:
On Monday 07 January 2008 16:06:27 Bruce Momjian wrote:
Devrim GÜNDÜZ wrote:
Hi,
On Mon, 2008-01-07 at 17:12 -0500, Tom Lane wrote:
if no serious bugs come up this week, core is thinking of wrapping
8.3.0 at the
On Mon, Jan 07, 2008 at 08:00:36PM -0500, Bruce Momjian wrote:
Joshua D. Drake wrote:
Hi,
On Mon, 2008-01-07 at 17:12 -0500, Tom Lane wrote:
if no serious bugs come up this week, core is thinking of wrapping
8.3.0 at the end of the week,
Please give the packagers
On 08/01/2008, Darcy Buskermolen [EMAIL PROTECTED] wrote:
On Monday 07 January 2008 16:06:27 Bruce Momjian wrote:
Devrim GÜNDÜZ wrote:
Hi,
On Mon, 2008-01-07 at 17:12 -0500, Tom Lane wrote:
if no serious bugs come up this week, core is thinking of wrapping
8.3.0 at the end of
On Tue, Jan 08, 2008 at 09:47:15AM +, Peter Childs wrote:
On 08/01/2008, Darcy Buskermolen [EMAIL PROTECTED] wrote:
On Monday 07 January 2008 16:06:27 Bruce Momjian wrote:
Devrim GÜNDÜZ wrote:
Hi,
On Mon, 2008-01-07 at 17:12 -0500, Tom Lane wrote:
if no serious bugs
[EMAIL PROTECTED] wrote:
NEW.idxFTI := to_tsvector('simple', encode($x$E$x$||
NEW.messageblk, 'escape'));
I strongly doubt that this does what you think it does - I would check
the results if I were you. The $x$E$x$ should almost certainly not be
there - if you are trying to
On Jan 8, 10:43 am, [EMAIL PROTECTED] wrote:
On Jan 8, 4:14 am, [EMAIL PROTECTED] (Tom Lane) wrote:
[EMAIL PROTECTED] writes:
I am using tsearch2 with pgsql 8.2.5 and get the following error when
calling to_tsvector :
translation failed from server encoding to wchar_t
My database
If you hit tab on a table name containing a \ you get spammed with a series of
WARNINGS and HINTS about nonstandard use of \\ in a string literal:
postgres=# select * from bar\bazTAB
WARNING: nonstandard use of \\ in a string literal
LINE 1: ...
Option 5 would be to deprecate the ability to use a \ in an object name.
Jon
-Original Message-
From: Gregory Stark [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 08, 2008 8:14 AM
To: pgsql-hackers list
Subject: [HACKERS] Psql command-line completion bug
If you hit tab on a
We previously tried to send this proposal/patch, but it never showed up.
We tried twice in a 16 hour period. It might be something with the
attachment, who knows. This time, we are providing a URL instead of
attaching the patch. Please disregard previous emails if they come back
from
On Tue, Jan 08, 2008 at 09:50:07AM +0100, Michael Akinde wrote:
stack size (kbytes, -s) 8192
Perhaps this is the issue? (I don't know.) Also, this _is_ for the
postgres user, right? That's the relevant one: the one that's actually
running the back end process.
Also, are you
Hi,
Andrew Chernow wrote:
It might be something with the
attachment, who knows.
Most probably that was the case, yes. The -hackers list is limited,
please use -patches to send patches. ;-)
Regards
Markus
---(end of broadcast)---
TIP 6:
Michael Akinde [EMAIL PROTECTED] writes:
We went over this somewhat prior to Christmas. Here's how its currently
set up.
$ ulimit -a
core file size (blocks, -c) 1
...
What you're showing us is the conditions that prevail in your
interactive session. That doesn't
Magnus Hagander [EMAIL PROTECTED] writes:
On Tue, Jan 08, 2008 at 09:47:15AM +, Peter Childs wrote:
Indeed the website still says we are on Beta 4. I did not even know RC1 was
out until I saw this thread this morning.
RC1 isn't out. What's available on the ftp site is a preliminary
On Tue, Jan 08, 2008 at 05:27:16PM +0100, Michael Akinde wrote:
Those are the ulimits of the db_admin account (i.e., the user that set
up and runs the DB processes). Is Postgres limited by other settings?
Are you sure?
On one system I used many years ago, /bin/sh wasn't what I thought it
Magnus Hagander [EMAIL PROTECTED] writes:
On Tue, Jan 08, 2008 at 11:23:13AM -0500, Tom Lane wrote:
We didn't include 8.3RC1 in the security announcement because Josh
wanted to make a separate announcement for it, but from every
perspective except the PR one, it's out.
There has been no
On Tue, Jan 08, 2008 at 01:08:52AM +0100, Markus Schiltknecht wrote:
Uh, which key are you talking about? AFAIU Simon's proposal, he suggests
maintaining min/max values for all columns of the table.
Right, but I think that's just because that approach is automatable. Only
some use cases are
On Tue, Jan 08, 2008 at 02:12:28AM +, Gregory Stark wrote:
Yes: it doesn't solve the problem I have, which is that I don't want to
have to manage a whole bunch of tables. I want one table, and I want to
be able to say, That section is closed.
That's not your problem, that's the
On Tue, Jan 08, 2008 at 11:23:13AM -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Tue, Jan 08, 2008 at 09:47:15AM +, Peter Childs wrote:
Indeed the website still says we are on Beta 4. I did not even know RC1 was
out until I saw this thread this morning.
RC1
Tom Lane wrote:
Michael Akinde [EMAIL PROTECTED] writes:
$ ulimit -a
core file size (blocks, -c) 1
...
What you're showing us is the conditions that prevail in your
interactive session. That doesn't necessarily have a lot to do with
the ulimits that init-scripts run
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Tue, Jan 08, 2008 at 11:23:13AM -0500, Tom Lane wrote:
We didn't include 8.3RC1 in the security announcement because Josh
wanted to make a separate announcement for it, but from every
perspective except the PR one, it's out.
There
Tom Lane a écrit :
Magnus Hagander [EMAIL PROTECTED] writes:
On Tue, Jan 08, 2008 at 11:23:13AM -0500, Tom Lane wrote:
We didn't include 8.3RC1 in the security announcement because Josh
wanted to make a separate announcement for it, but from every
perspective except the PR one, it's
Andrew Sullivan [EMAIL PROTECTED] writes:
On Tue, Jan 08, 2008 at 05:27:16PM +0100, Michael Akinde wrote:
Those are the ulimits of the db_admin account (i.e., the user that set
up and runs the DB processes). Is Postgres limited by other settings?
Are you sure?
On one system I used many
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Tue, Jan 08, 2008 at 11:23:13AM -0500, Tom Lane wrote:
We didn't include 8.3RC1 in the security announcement because Josh
wanted to make a separate announcement for it, but from every
perspective except the PR
On Tue, Jan 08, 2008 at 12:33:34PM -0500, Tom Lane wrote:
Andrew Sullivan [EMAIL PROTECTED] writes:
On one system I used many years ago, /bin/sh wasn't what I thought it was,
and so the ulimit that I got when logged in was not what the postmaster was
starting under. Took me many days to
Markus Schiltknecht wrote:
Hi,
Andrew Chernow wrote:
It might be something with the attachment, who knows.
Most probably that was the case, yes. The -hackers list is limited,
please use -patches to send patches. ;-)
Regards
Markus
Noted.
In our case, its a little ambiguos whether
Andrew Chernow wrote:
Markus Schiltknecht wrote:
Hi,
Andrew Chernow wrote:
It might be something with the attachment, who knows.
Most probably that was the case, yes. The -hackers list is limited,
please use -patches to send patches. ;-)
Regards
Markus
Noted.
In our case, its a
Sam Mason [EMAIL PROTECTED] writes:
On Tue, Jan 08, 2008 at 12:33:34PM -0500, Tom Lane wrote:
The only thing I find convincing is to insert ulimit -a someplace
into the script that starts the postmaster,
What about a stored procedure in a language that allows you to do
system(3) calls?
Hi,
IMO, the lengthy discussion about Segment Exclusion and Segment
Visibility Maps has long turned into a discussion about partitioning in
general. I'm thankful for all the new insights it has brought me and I
want to continue sharing my view on things. What's following is highly
Andrew Dunstan wrote:
Andrew Chernow wrote:
Markus Schiltknecht wrote:
Hi,
Andrew Chernow wrote:
It might be something with the attachment, who knows.
Most probably that was the case, yes. The -hackers list is limited,
please use -patches to send patches. ;-)
Regards
Markus
On Jan 8, 2008 12:57 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
You should split it and send the proposal to -hackers. Ideally, you
would have had a proposal discussed before you wrote a line of code.
This is the latest in a long series of submissions...check the
archives. We are (and have
Tom Lane wrote:
Comparing the behavior of this to my patch for HEAD, I am coming to the
conclusion that this is actually a *better* planning method than
removing the redundant join conditions, even when they're truly
rendundant! The reason emerges as soon as you look at cases involving
more
I wrote:
Haven't looked closely at how to fix 8.2, yet.
After some study it seems that the simplest, most reliable fix for 8.2
is to dike out the code that removes redundant outer join conditions
after propagating a constant across them. This gives the right answer
in the cases of concern
All,
There has been no annonucement whatsoever. Our web site stll claims
beta4 is the current version. I was under the impression that this
tarball, like all others, are considered preliminary until announced
one way or another.
Sorry about that. I was confused and thought we were
Alvaro Herrera [EMAIL PROTECTED] writes:
Would it be a good idea to keep removing redundant clauses and rethink
the preference for clauseful joins, going forward?
No --- it would create an exponential growth in planning time for large
join problems, while not actually buying anything in the
Merlin,
That said, we have been a little dismayed in the lack of comment.
I think most people can't really follow what functionality this would allow
users driver authors to access, and what the spec for that functionality
would. I know I'm not clear on it.
A high-level proposal would
Merlin Moncure [EMAIL PROTECTED] writes:
That said, we have been a little dismayed in the lack of comment.
Personally, I'm ignoring this thread, as well as the one on
partitioning, because I'm up to my arse in 8.3-release alligators.
I'm going to try hard not to think about any 8.4 development
On Jan 8, 2008 4:31 PM, Josh Berkus [EMAIL PROTECTED] wrote:
Merlin,
That said, we have been a little dismayed in the lack of comment.
I think most people can't really follow what functionality this would allow
users driver authors to access, and what the spec for that functionality
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
That said, we have been a little dismayed in the lack of comment.
Personally, I'm ignoring this thread, as well as the one on
partitioning, because I'm up to my arse in 8.3-release alligators.
I'm going to try hard not to think about
Gregory Stark [EMAIL PROTECTED] writes:
Further poking around shows that the unrecognized locktag is because
lmgr.c:DescribeLockTag was never taught about virtual xids.
That's fixed, thanks for the patch.
The pid it's waiting on is long since gone but looks like it was probably an
autovacuum
Gregory Stark [EMAIL PROTECTED] writes:
The pid it's waiting on is long since gone but looks like it was probably an
autovacuum process. I have a vague recollection that you had rigged CREATE
INDEX CONCURRENTLY to ignore vacuum processes when checking for conflicting
processes. Since any such
Tom Lane [EMAIL PROTECTED] writes:
It cannot be one of the first two, because those only block
for xacts that *already have* a conflicting lock. The problem must be
at the third wait step, which waits out all xacts that might conceivably
be interested in recently-dead tuples that are not in
So I adjusted the patch I was working on as suggested here
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00251.php
and things started blowing up all over the place --- Assert failures,
too few pathkeys for mergeclauses errors, etc :-(
On investigation, the problem seems to be a bit of
Tom Lane wrote:
I think I can fix this in a day or so, but I now definitely feel that
we'll need an RC2 :-(
Understood. :-|
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard
Markus Schiltknecht [EMAIL PROTECTED] writes:
There are two very distinct ways to handle partitioning. For now, I'm calling
them named and unnamed partitioning.
I had most of a draft email written which I seem to have lost in a reboot. To
a large degree I was on the same line of thought as
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Now an unindexed dead tuple is not a problem from vacuum's point of
view, nor does ANALYZE care, so AFAICS there is no need for this step
to wait for autovacuum processes --- nor indeed for manual vacuums.
Also,
Gregory Stark wrote:
I am hoping our other things which ignore VACUUM such as the globalxmin
calculation are careful not to ignore VACUUM ANALYZE processes?
It doesn't matter -- the ANALYZE is done in a separate transaction (so
the VACUUM part is ignored, the ANALYZE part is not).
--
Alvaro
On Tue, Jan 08, 2008 at 05:53:28PM +, Sam Mason wrote:
What about a stored procedure in a language that allows you to do
system(3) calls?
PL/bash? (I think there is something like this). But surely the ulimit
before start is much easier!
A
---(end of
Now that the dust has settled, I want to post some notes about CVE-2007-6600,
which is to my mind the most important of the five security problems fixed
in our recent security updates. There are some unfinished issues here.
Itagaki Takahiro originally identified the issue. The crux of it is
On Wed, Jan 02, 2008 at 05:56:14PM +, Simon Riggs wrote:
This technique would be useful for any table with historical data keyed
by date or timestamp. It would also be useful for data where a
time-of-insert component is implicit, such as many major entity tables
where the object ids are
53 matches
Mail list logo
