Heikki Linnakangas wrote:
> > The documentation states
> >
> > "The archive command should generally be designed to refuse to overwrite
> > any pre-existing archive file."
> >
> > and suggests an archive_command like "test ! -f .../%f && cp %p .../%f".
> >
> > We ran into (small) problems with
On Jan 22, 2009, at 10:18 AM, Albe Laurenz wrote:
"The archive command should generally be designed to refuse to
overwrite any pre-existing archive file."
...
The server received a fast shutdown request while a WAL segment was
being archived.
The archiver stopped and left behind a half-writt
On Jan 22, 2009, at 8:24 AM, Euler Taveira de Oliveira wrote:
No one that I know of. Well, it is a long road. The addition of a
data type
xml is recent (8.3). We lack a set of features like indexing, a new
data
structure (?), XQuery, XPath improvement and, so on [1]. Don't
expect much of
the
The patch set of SE-PostgreSQL and related stuff were updated (r1460).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1460.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1460.patch
[3/5]
http://sepgsql.googlecode.com/files/sepostgresql
Euler Taveira de Oliveira writes:
> Alvaro Herrera escreveu:
>> Well, the problem is precisely how to size the list. I don't like the
>> idea of keeping an arbitrary number in memory; it adds another
>> mostly-useless tunable that we'll need to answer questions about for all
>> eternity.
Is it s
Alvaro Herrera escreveu:
> Euler Taveira de Oliveira escribió:
>> Alvaro Herrera escreveu:
>>> This could be solved if the workers kept the whole history of tables
>>> that they have vacuumed. Currently we keep only a single table (the one
>>> being vacuumed right now). I proposed writing these h
--On Donnerstag, Januar 22, 2009 15:30:35 -0500 Andrew Dunstan
wrote:
Am I the only person who gets regularly annoyed by pg_get_viewdef()
outputting the target list as one long line? I'd like it to put one
target per line, indented, if pretty printing.
No, so +1 from me.
--
Thanks
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Well, the examples I've looked at fit in 80 columns, but it's true that
> all the identifiers involved were pretty short. The alternative I think
> you're suggesting is
Yeah, I see that now. I guess you'd need a column identifier wider than
'Column Access
Stephen Frost writes:
> One thing that just occured to me is that we could, should we want to,
> move the column-level privs over into the 'Access privileges' column by
> just adding them on after the table-level privs. We would want to make
> sure the table-level privs come first and maybe have
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> BTW, something else I'd meant to bring up for discussion is whether
> anyone likes the formatting of column privileges in \dp:
Well, I kinda like it, but that's not an entirely unbiased opinion. ;)
> Access privileges
> Schem
Alvaro Herrera wrote:
> I'm not sure that we have any use for the top level you propose; the
> attached patch just uses the two lower levels, and I think it fits
> autovacuum usage just fine. Thanks for the idea.
Of course, there's no need to pass the relkind; it goes inside the
pg_class tuple.
Stephen Frost writes:
> Seeing this list reminded me of a pet-peeve.. \du and \dg actually show
> the same info, that's fine, but neither of them show the rolcanlogin
> value.
+1 for fixing that.
>> \dp [PATTERN]list table, view, and sequence access privileges
> erp, I don't think I c
BTW, something else I'd meant to bring up for discussion is whether
anyone likes the formatting of column privileges in \dp:
regression=# create table foo(bar int, baz int);
CREATE TABLE
regression=# grant select on foo to joe;
GRANT
regression=# grant insert(bar), update(baz) on foo to joe;
GRANT
> Needless
to say if you're both waiting for each other nothing will get done.
SET deadlock_timeout = '3d';
;-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera writes:
> >Right now we just plow
> >ahead using a pg_class seqscan, which avoids locking the relations
> >just for the sake of verifying whether they need work.
>
> We should stick with that, and refactor the reloptions code as needed to
> be able to
Robert Haas writes:
>> Of course, there's no much point in an index that's easily corrupted, so
>> I understand the desire to implement WAL too -- I'm just pointing out
>> that concurrency could have been developed independently.
> Anything's possible with enough work, but having good support in
On Thu, 2009-01-22 at 18:20 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > On Wed, 2009-01-21 at 15:08 -0800, Jeff Davis wrote:
> >> If we keep the permission check in LockTableCommand(), I can make a
> >> patch that produces a more useful error message when the table is
> >> removed right before
m...@postgresql.org (Magnus Hagander) writes:
> Explicitly bind gettext to the correct encoding on Windows.
I have a couple of objections to this patch. First, what happens if
it fails to find a matching table entry? (The existing answer is
"nothing", but that doesn't seem right.) Second and mo
Jeff Davis writes:
> On Wed, 2009-01-21 at 15:08 -0800, Jeff Davis wrote:
>> If we keep the permission check in LockTableCommand(), I can make a
>> patch that produces a more useful error message when the table is
>> removed right before the pg_class_aclcheck().
> Attached.
This is pretty horrid
Amit,
You might want to put this on the
http://wiki.postgresql.org/wiki/Table_partitioning wiki page.
How does your timeline look like for this implementation?
I would be happy to contribute C triggers to your implementation. From
what I understood in
http://archives.postgresql.org/pgsql-hack
Euler Taveira de Oliveira escribió:
> Alvaro Herrera escreveu:
> > This could be solved if the workers kept the whole history of tables
> > that they have vacuumed. Currently we keep only a single table (the one
> > being vacuumed right now). I proposed writing these history files back
> > when w
Bruce Momjian writes:
> Was this dealt with?
Yes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera escreveu:
> This could be solved if the workers kept the whole history of tables
> that they have vacuumed. Currently we keep only a single table (the one
> being vacuumed right now). I proposed writing these history files back
> when workers were first implemented, but the idea wa
Jeff Davis wrote:
> On Mon, 2009-01-12 at 13:35 -0500, Tom Lane wrote:
> > I think the behavior Lee is expecting is only implementable with a
> > full-table write lock, which is exactly what FOR UPDATE is designed
> > to avoid. There are certain properties you don't get with a partial
> > lock, an
Simon,
Your suggestion sounds reasonable and I thank you, but doesn't actually
address the plugin discussion at all. It had absolutely zip to do with
making building indexes easier; it was about enabling robust index
plugins, period. (As well as other worthwhile use cases). It's not a
cost benef
Alvaro Herrera writes:
> So I've been progressing on revising the autovacuum patch to make it
> work with the current reloptions. We have a number of options:
> 1. Call heap_open() for every relation that we're going to check, and
>examine the reloptions via the relcache.
>I'm not sure t
Tom Lane escribió:
> Alvaro Herrera writes:
> > Martin Pihlak escribi�:
> >> [ patch to fool with stats refresh logic in autovac ]
>
> (1) I still don't understand why we don't just make the launcher request
> a new stats file once per naptime cycle, and then allow the workers to
> work from that
The recently discovered memory-context-switch bug in 8.1's autovacuum
seems serious enough to force an update release for that branch, since
it could result in crashes in an installation that had been working fine
for a long while. Although this only affects 8.1, the core committee
has concluded t
Alvaro Herrera writes:
> Martin Pihlak escribió:
>> [ patch to fool with stats refresh logic in autovac ]
(1) I still don't understand why we don't just make the launcher request
a new stats file once per naptime cycle, and then allow the workers to
work from that.
(2) The current code in autova
On Wed, 2009-01-21 at 18:38 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > So you *must* replay catalog entries and recreate the original catalog
> > in exact synchronisation with reading WAL files. Recreating the catalog
> > can only be done by Postgres itself.
>
> The startup process
Hi,
So I've been progressing on revising the autovacuum patch to make it
work with the current reloptions. We have a number of options:
1. Call heap_open() for every relation that we're going to check, and
examine the reloptions via the relcache.
I'm not sure that I like this very much. R
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Applied with revisions. The main externally visible change is that I
> implemented per-column REFERENCES privilege, since that's required by
> spec. I did some heavy revision of the parsing support too, as per
> previous dicussions, and editorial cleanup a
On Thu, 2009-01-22 at 11:23 -0800, Josh Berkus wrote:
> I suggest that we take the rmgr patch and combine it with getting WAL
> working properly for Bitmap-on-disk and Hash indexes in 8.5. Having
> this patch attached to an actual implementation will show if it's the
> correct code to make bu
On Thu, Jan 22, 2009 at 3:29 PM, Tom Lane wrote:
>
> * We probably ought to invent has_column_privilege SQL functions
> analogous to has_table_privilege; this is not just for completeness,
> but is probably necessary to finish the above items.
>
+1
> * ISTM that COPY with a column list should su
Am I the only person who gets regularly annoyed by pg_get_viewdef()
outputting the target list as one long line? I'd like it to put one
target per line, indented, if pretty printing.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Stephen Frost writes:
> Attached is an updated patch for column-level privileges.
Applied with revisions. The main externally visible change is that I
implemented per-column REFERENCES privilege, since that's required by
spec. I did some heavy revision of the parsing support too, as per
previ
On Thu, 2009-01-22 at 13:45 +, Simon Riggs wrote:
> But this isn't just for me...
I have an old proposal here:
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00404.php
Of course, the number one problem I ran into was that I never actually
wrote the code, not that I needed it to be a
Euler Taveira de Oliveira wrote:
Simon Riggs escreveu:
On Tue, 2009-01-20 at 21:51 +0200, Heikki Linnakangas wrote:
Attached is a simple patch to only start skipping pages after 20
consecutive pages marked as visible in the visibility map. This doesn't
do any "look-ahead", so it will always s
All,
I have a suggestion for the rmgr patch.
Currently, there are *no* plans to get WAL working for the new hash
indexes, nor is there time.
I suggest that we take the rmgr patch and combine it with getting WAL
working properly for Bitmap-on-disk and Hash indexes in 8.5. Having
this patch
Jonah H. Harris wrote:
On Wed, Jan 21, 2009 at 2:02 PM, Robert Haas wrote:
Was there a reason that this cleanup patch wasn't applied?
1. It was submitted after the deadline for CommitFest:November.
Well, it's just comment changes...
Oh, didn't realize that. That's what I get for replying wi
Amit,
Wow, thanks!
As you probably know, we're already in freeze for 8.4. So this patch
will need to go on the first commitfest for 8.5, in May or June.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
Heikki Linnakangas wrote:
ITAGAKI Takahiro wrote:
- What relation are there between autovacuum_freeze_max_age,
vacuum_freeze_min_age and vacuum_freeze_table_age? If we increase
one of them, should we also increase the others?
Yeah, that's a fair question. I'll try to work a doc patch to ex
Albe Laurenz wrote:
The documentation states in
http://www.postgresql.org/docs/current/static/continuous-archiving.html#BACKUP-ARCHIVING-WAL
"The archive command should generally be designed to refuse to overwrite any
pre-existing archive file."
and suggests an archive_command like "test ! -f
On Thu, 2009-01-22 at 18:13 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-01-22 at 16:15 +0200, Heikki Linnakangas wrote:
> >> That might be useful. But again, could just as well be implemented as an
> >> external tool like pglesslog.
> >
> > There is no WAL record for "
On Wednesday 21 January 2009 20:21:41 Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Robert Treat wrote:
> > > On Thursday 08 May 2008 00:27:10 Tino Wildenhain wrote:
> > > > David Fetter wrote:
> >
> > Ref: http://archives.postgresql.org/pgsql-hackers/2008-05/msg00198.php
> >
> > > > > 1. Creat
Andrew Chernow wrote:
Tom Lane wrote:
Andrew Chernow writes:
I can try. Where should this be documented? ISTM that the best
place is at the top of "30.1 Database Connection Control Functions",
since the issue pertains to any connect/disconnect function. Does
that sound correct? Should it
Tom Lane wrote:
Andrew Chernow writes:
I can try. Where should this be documented? ISTM that the best place
is at the top of "30.1 Database Connection Control Functions", since the
issue pertains to any connect/disconnect function. Does that sound
correct? Should it be a warning or just r
On Thu, Jan 22, 2009 at 11:13 AM, Heikki Linnakangas
wrote:
> Simon Riggs wrote:
>> On Thu, 2009-01-22 at 16:15 +0200, Heikki Linnakangas wrote:
>>>
>>> That might be useful. But again, could just as well be implemented as an
>>> external tool like pglesslog.
>>
>> There is no WAL record for "no-o
Robert Haas wrote:
On Thu, Jan 22, 2009 at 10:31 AM, Heikki Linnakangas
wrote:
The fact the patch does not do anything that anyone might ever want is
not a sufficient grounds for rejecting it.
Huh? That sounds like enough of a reason to me.
s/anything that anyone might ever want/everything t
> Of course, there's no much point in an index that's easily corrupted, so
> I understand the desire to implement WAL too -- I'm just pointing out
> that concurrency could have been developed independently.
Anything's possible with enough work, but having good support in -core
makes it easier and
The documentation states in
http://www.postgresql.org/docs/current/static/continuous-archiving.html#BACKUP-ARCHIVING-WAL
"The archive command should generally be designed to refuse to overwrite any
pre-existing archive file."
and suggests an archive_command like "test ! -f .../%f && cp %p .../%f
On Thu, Jan 22, 2009 at 10:31 AM, Heikki Linnakangas
wrote:
>> The fact the patch does not do anything that anyone might ever want is
>> not a sufficient grounds for rejecting it.
>
> Huh? That sounds like enough of a reason to me.
s/anything that anyone might ever want/everything that anyone mig
Simon Riggs wrote:
On Thu, 2009-01-22 at 16:15 +0200, Heikki Linnakangas wrote:
That might be useful. But again, could just as well be implemented as an
external tool like pglesslog.
There is no WAL record for "no-op", at least not one of variable length.
Hmm, maybe there should be? That see
Robert Haas escribió:
> We allow extensibility and hooks in other parts of the database where
> the use case is pretty thin and tenuous. I betcha there aren't many
> people who try writing their own eqjoinsel() either.
The PostGIS guys do implement their own selectivity estimators. In fact
it w
Teodor Sigaev wrote:
>> What other constraints are there on such non-in-core indexex? Early (2005)
>> GIST indexes were very painful in production environments because vacuuming
>> them held locks for a *long* time (IIRC, an hour or so on my database) on
>> the indexes locking out queries. Was th
Robert Haas wrote:
The fact the patch does not do anything that anyone might ever want is
not a sufficient grounds for rejecting it.
Huh? That sounds like enough of a reason to me.
Much ink has been spilled in this space over the size and difficulty
of reviewing Simon's hot standby patch, on
Andrew Chernow writes:
> I can try. Where should this be documented? ISTM that the best place
> is at the top of "30.1 Database Connection Control Functions", since the
> issue pertains to any connect/disconnect function. Does that sound
> correct? Should it be a warning or just regular tex
On Thu, Jan 22, 2009 at 9:15 AM, Heikki Linnakangas
wrote:
>> Immediate use cases for me would be
>>
>> * ability to filter WAL records based on database or relation
>
> This patch isn't enough to allow the catalog lookups. Without the catalog
> lookups, you might as well implement that as an exte
On Thu, 2009-01-22 at 16:15 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Immediate use cases for me would be
> >
> > * ability to filter WAL records based on database or relation
>
> This patch isn't enough to allow the catalog lookups. Without the
> catalog lookups, you might as w
Magnus Hagander wrote:
Andrew Chernow wrote:
Magnus Hagander wrote:
In which case, we should perhaps just document the workaround using
WSAStartup() yourself, and not bother with either API or connection
parameter...
I didn't originally agree with this but now I do. Any libpq init
function
Carlos Gonzalez-Cadenas escreveu:
> We're looking for a deductive database for our application. Oracle, in
> the 11g version, has extended its RDBMS with deductive capabilities,
> supporting a subset of OWL-DL[1]. They are able to load an ontology,
> perform the inferences, dump the inferred info i
Simon Riggs wrote:
Immediate use cases for me would be
* ability to filter WAL records based on database or relation
This patch isn't enough to allow the catalog lookups. Without the
catalog lookups, you might as well implement that as an external tool,
like pglesslog.
* ability to recove
On Thu, 2009-01-22 at 14:52 +0200, Heikki Linnakangas wrote:
> Oleg Bartunov wrote:
> > as I understand, there are already plans to utilize this feature. If so,
> > we need to be more attentive by now.
>
> Is there? If I understood Simon correctly in the last paragraphs of
> these emails:
>
> h
Bruce Momjian wrote:
Heikki Linnakangas wrote:
IMHO, this is just getting too kludgey. We came up with pretty good
ideas on how to handle temp tables properly, by treating the same as
non-temp tables. That should eliminate all the problems the latest patch
did, and also the issues with sequenc
Oleg Bartunov wrote:
as I understand, there are already plans to utilize this feature. If so,
we need to be more attentive by now.
Is there? If I understood Simon correctly in the last paragraphs of
these emails:
http://archives.postgresql.org/message-id/1221470800.3913.1229.ca...@ebony.2ndq
Hi,
We are implementing table partitioning feature to support
- the attached commands. The syntax conforms to most of the suggestion
mentioned in
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php, barring
the following:
-- Specification of partition names is optional. System will b
Andrew Chernow wrote:
> Magnus Hagander wrote:
>>
>> In which case, we should perhaps just document the workaround using
>> WSAStartup() yourself, and not bother with either API or connection
>> parameter...
>>
>>
>
> I didn't originally agree with this but now I do. Any libpq init
> function for
BTW, gincostestimate could use that information for cost estimation, but is
index opening and metapge reading in amcostestimate acceptable?
That sounds reasonable to me. I think that's what the index-specific
cost estimators are for.
Done.
Do you expect a performance impact?
I'm afraid fo
On Thu, 2009-01-22 at 10:09 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Preventing work on new indexes by non-committers has meant that Bitmap
> > indexes, which first came out in 2005 have not been usable with
> > Postgres. That forced people *away* from Postgres towards Bizgres. L
What other constraints are there on such non-in-core indexex? Early (2005)
GIST indexes were very painful in production environments because vacuuming
them held locks for a *long* time (IIRC, an hour or so on my database) on
the indexes locking out queries. Was that just a shortcoming of the
imp
Hiroshi Inoue wrote:
> Magnus Hagander wrote:
>> Peter Eisentraut wrote:
>>> Magnus Hagander wrote:
However, one question: The comment currently says it's harmless to do
this on non-windows platforms. Does this still hold true?
>>> Yes, the non-WIN32 code path appears to be the same, stil
Hi all,
We're looking for a deductive database for our application. Oracle, in the
11g version, has extended its RDBMS with deductive capabilities, supporting
a subset of OWL-DL[1]. They are able to load an ontology, perform the
inferences, dump the inferred info in the database and after that ans
Currently, Linux.conf.au 2009 is held on Hobart, Tasmania.
I had to plan to talk about SE-PostgreSQL and related stuff,
but it became unavailable to attend the conference due to
the recent economic circumstances unfortunately. :(
Russell Coker is one of the core developers in SELinux community.
H
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jan 21, 2009 at 10:48:21PM +, Simon Riggs wrote:
>
> On Thu, 2009-01-22 at 00:29 +0300, Oleg Bartunov wrote:
[...]
> > Other question, why don't improve GiST to allow support of more indexes ?
> > bitmap indexes could be implemented usi
Hi,
We are extending Gokul's Thick index functionality (
http://archives.postgresql.org/pgsql-patches/2008-01/msg00092.php) on 8.4
code base to
- fix existing defects
- Extend thick index usage for group by, count, nested queries, and
"delete/update with join" queries.
- Improve cost estimates for
Can you please help me solve the problem of ERROR deadlock detected
This is the log incurred in postgressql.log
2009-01-21 15:47:20 IST NOTICE: truncate cascades to table "displet"
2009-01-21 15:47:20 IST NOTICE: truncate cascades to table
"screenscrapesource"
2009-01-21 15:47:20 IST NOTIC
Magnus Hagander wrote:
Peter Eisentraut wrote:
Magnus Hagander wrote:
However, one question: The comment currently says it's harmless to do
this on non-windows platforms. Does this still hold true?
Yes, the non-WIN32 code path appears to be the same, still. But the
ifdef WIN32 part we don't w
Hi all,
I hope to raise some valid concerns with the following two stories, a "true
story" first then a little fiction that I hope has a lot to do with current
reality.
Le jeudi 22 janvier 2009, Heikki Linnakangas a écrit :
> It's also impossible to do many other things without modifying the
>
On Wed, 21 Jan 2009, Bruce Momjian wrote:
Josh Berkus wrote:
Bruce,
Plugability adds complexity. Heikki's comment is that adding this patch
make the job of creating pluggable indexes 5% easier, while no one is
actually working on plugable indexes, and it hard to say that making it
5% easier r
Oleg Bartunov wrote:
bitmap indexes could be implemented usin g GiST.
Huh, how would that work? Bitmap indexes have a very different
structure, AFAICS.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Simon Riggs wrote:
Preventing work on new indexes by non-committers has meant that Bitmap
indexes, which first came out in 2005 have not been usable with
Postgres. That forced people *away* from Postgres towards Bizgres. Lack
of Bitmap indexes is a huge issue for many people. It's 2009 now and it
81 matches
Mail list logo
