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
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 that
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 broadcast)
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
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.
"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
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 har
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" <[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
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
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
> aut
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
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 functionali
"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 developme
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
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
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 ar
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
>
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 (wh
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
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
Noted.
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
theoretical
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) c
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 li
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 da
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 P
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
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 o
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 -ha
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.
Ther
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
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 bee
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
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 a
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 ru
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.
>
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
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 ne
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: expl
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 su
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 never-n
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 ta
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\baz<>
WARNING: nonstandard use of \\ in a string literal
LINE 1: ... substring(pg_catalog.quote_ident(c.relname),1,7)='
[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 get
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
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:
> > >
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
>
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
> > >
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,
> > > >
> > >
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_tsv
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
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 w
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 a
53 matches
Mail list logo
