On Tue, 2008-10-14 at 19:18 +0300, Peter Eisentraut wrote:
Tom Lane wrote:
So I was looking for other omissions in utility.c, and I noticed that
check_xact_readonly() doesn't reject CLUSTER, REINDEX, or VACUUM.
Now the notion of read only that we're trying to enforce is pretty
weak (I
Hi,
According to the documentation (
http://www.postgresql.org/docs/8.3/interactive/sql-createtrigger.html
), the feaure SQL allows triggers to fire on updates to specific
columns (e.g., AFTER UPDATE OF col1, col2) is missing.
After a bit of research, I found that this feature was in the TODO
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
* tupdesc has more columns than the tuple does. This is possible after
ALTER TABLE ADD COLUMN, for example. The correct interpretation in
this situation is that the extra columns
Bruce Momjian wrote:
I think we could use row-level access control to prevent people from
seeing databases they should not see in pg_database.
The row-level database ACL which I submitted yesterdat does not allow
to assign ACLs to tuples within system catalogs (like pg_database),
because it is
Joshua Tolley [EMAIL PROTECTED] writes:
I've been interested in what it would take to start tracking
cross-column statistics. A review of the mailing lists as linked from
the TODO item on the subject [1] suggests the following concerns:
1) What information exactly would be tracked?
2) How
KaiGai Kohei wrote:
Bruce Momjian wrote:
I think we could use row-level access control to prevent people from
seeing databases they should not see in pg_database.
The row-level database ACL which I submitted yesterdat does not allow
to assign ACLs to tuples within system catalogs (like
Zhe He napsal(a):
I'm currently implement a new operation in Postgres.
If I want to get all tuples of a single attribute table to
create an array defined by myself, how can I do that?
Look into heapam.c and pgstattuple contrib module is good example.
Zdenek
--
Zdenek Kotala
ISTM it'd be useful to have an array_length function (since I just
wrote one for work ;), so here's a patch. Note that I don't have the
docs toolchain setup, so I wasn't able to test the doc patches.
array_length.patch
Description: Binary data
--
Decibel!, aka Jim C. Nasby, Database
On Oct 11, 2008, at 4:05 AM, ITAGAKI Takahiro wrote:
I'd like to submit pg_stat_statements contrib module, that counts up
incoming statements in shared memory and summarizes the result as a
view.
It is just a statements-version of pg_stat_user_functions.
Awesome!
I attach WIP version of
On Oct 14, 2008, at 4:04 PM, Alvaro Herrera wrote:
Tom Lane wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Standard DBAs are blind to LOG level messages.
Indeed, which is why I'm not too concerned about Heikki's complaint.
Well, if the disk fills up due to excessive LOG entries, they
On Oct 10, 2008, at 7:41 PM, Nikolas Everett wrote:
In any case your experience doesn't match mine. On a machine with a
sizable
raid controller setting random_page_cost higher does generate, as
expected,
plans with more bitmap heap scans which are in fact faster.
We're running postgres
On Oct 15, 2008, at 3:21 AM, Laurent Wandrebeck wrote:
According to the documentation (
http://www.postgresql.org/docs/8.3/interactive/sql-createtrigger.html
), the feaure SQL allows triggers to fire on updates to specific
columns (e.g., AFTER UPDATE OF col1, col2) is missing.
After a bit of
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
[ pokes around ... ] The difference between correct and incorrect
behavior here is that it is correct for SPI_getvalue and SPI_getbinval
to return NULL for added columns, but they are incorrect to also set
SPI_result
Decibel! [EMAIL PROTECTED] writes:
Since this is something that's not supposed to happen, making it a
WARNING might be appropriate too...
Uh, the complaint was that the message is too noisy, not that it isn't
noisy enough.
regards, tom lane
--
Sent via pgsql-hackers
The user running initdb (or the postmaster) needs
SeCreateGlobalPrivilege - which is something we cannot really start
Why not ? Doesn't the pg installer already tweak the permissions of the
installation user. On XP you can connect to session 0, so that is an
alternative on XP.
telling
Dave Page wrote:
The reason it should be in the Global namespace is that shmem is one part of
detecting an existing postmaster. Especially in situations where the db is
started
by hand, the protection against duplicate startup is important.
Yeah, as Magnus reminded me.
IMNSHO we
Andrew Dunstan wrote:
Dave Page wrote:
The reason it should be in the Global namespace is that shmem is one
part of
detecting an existing postmaster. Especially in situations where the
db is started
by hand, the protection against duplicate startup is important.
Yeah, as Magnus
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Can we supress this annoying message? It seems to come from _dosmaperr,
but the error postmaster.pid is not found is a *normal* situation
in pg_resetxlog.
- open(%s/postmaster.pid, O_RDONLY, 0)
- pgwin32_open()
- _dosmaperr()
On Wed, Oct 15, 2008 at 7:51 AM, Gregory Stark [EMAIL PROTECTED] wrote:
Joshua Tolley [EMAIL PROTECTED] writes:
I've been interested in what it would take to start tracking
cross-column statistics. A review of the mailing lists as linked from
the TODO item on the subject [1] suggests the
Euler Taveira de Oliveira wrote:
What did I already do? I refactored reloptions.c to support multiple
options. I tried to follow up the same way GUC do (of course, it is much
simpler). I'm thinking about removing (replacing?) StdRdOptions 'cause
we need a different struct to store
Andrew Dunstan wrote:
I have verified that it does indeed work. Underneath the hood it uses
the native call LockFileEx() see win32io.c in Perl source. I suggest we
should switch from this flaky use of Global namespace to having the
postmaster acquire an explicit lock on a file in the
Andrew Dunstan [EMAIL PROTECTED] writes:
I have verified that it does indeed work. Underneath the hood it uses
the native call LockFileEx() see win32io.c in Perl source. I suggest we
should switch from this flaky use of Global namespace to having the
postmaster acquire an explicit lock on a
Alvaro Herrera wrote:
Andrew Dunstan wrote:
I have verified that it does indeed work. Underneath the hood it uses
the native call LockFileEx() see win32io.c in Perl source. I suggest we
should switch from this flaky use of Global namespace to having the
postmaster acquire an explicit
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I have verified that it does indeed work. Underneath the hood it uses
the native call LockFileEx() see win32io.c in Perl source. I suggest we
should switch from this flaky use of Global namespace to having the
postmaster acquire an
Tom Lane wrote:
Does fork/exec preserve lock ownership on Windows?
Not to my knowledge. On windows, there is only CreateProcess
(http://msdn.microsoft.com/en-us/library/ms682425.aspx). That doesn't
resemble the behavior of fork or exec at all. Basically, there is no
fork, windows
Hi,
I am facing issue compiling latest postgresql-8.3.4 code on windows .I
installed Visual Studio 2005 Express and Microsoft windows SDK latest v6.1 on
windows XP (SP2) as described by
http://www.postgresql.org/docs/8.3/static/install-win32-full.html and trying to
build postgresql-8.3.4,
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
That can only be a solution if postmaster child processes will inherit
the lock.
I don't think so, no. But we could have the children explicitly acquire
a shared lock, so if the postmaster at startup tried to grab an
exclusive lock
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Does fork/exec preserve lock ownership on Windows?
Not to my knowledge. On windows, there is only CreateProcess
(http://msdn.microsoft.com/en-us/library/ms682425.aspx). That doesn't
resemble the behavior of fork or exec at all.
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Does fork/exec preserve lock ownership on Windows?
Not to my knowledge. On windows, there is only CreateProcess
(http://msdn.microsoft.com/en-us/library/ms682425.aspx). That doesn't
resemble the behavior of fork
Magnus Hagander wrote:
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Does fork/exec preserve lock ownership on Windows?
Not to my knowledge. On windows, there is only CreateProcess
(http://msdn.microsoft.com/en-us/library/ms682425.aspx). That doesn't
resemble
Andrew Chernow [EMAIL PROTECTED] writes:
Be careful. From LockFileEx docs:
However, the time it takes for the operating system to unlock these
locks depends upon available system resources. Therefore, it is
recommended that your process explicitly unlock all files it has locked
when it
Tom Lane wrote:
Hmm. Now that you mention it, didn't we solve a similar problem by
exploiting the behavior where CreateProcess creates a process but
doesn't start it running? I'm envisioning
* Create child process in suspended state
* Assign it ownership of a lock (can we do
On Wed, Oct 15, 2008 at 10:49 AM, Zeugswetter Andreas OSB sIT
[EMAIL PROTECTED] wrote:
The user running initdb (or the postmaster) needs
SeCreateGlobalPrivilege - which is something we cannot really start
Why not ? Doesn't the pg installer already tweak the permissions of the
installation
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Be careful. From LockFileEx docs:
However, the time it takes for the operating system to unlock these
locks depends upon available system resources. Therefore, it is
recommended that your process explicitly unlock all files it has
Hi,
I'm currently working on a patch for the TODO item :
Allow databases to be moved to different tablespaces
I already changed the syntax, added some code to move the relations of
the specific database to the target tablespace. It works. But I have
three issues I would like to discuss.
To
I've been interested in what it would take to start tracking
cross-column statistics. A review of the mailing lists as linked from
the TODO item on the subject [1] suggests the following concerns:
1) What information exactly would be tracked?
2) How would it be kept from exploding in size?
3) For
2008/10/14 Robert Treat [EMAIL PROTECTED]
On Monday 13 October 2008 04:53:44 Markus Wanner wrote:
Having reviewed the last commit fest's intagg patch as well, I thought
we agreed that a more general functionality is wanted for core. But as
long as we don't have that, I'd like intagg to
Obviously that wasn't the intent of the above, but I guess it is the net
effect. Either way, I don't think it's a huge problem, it just means that
PG may not be able to restart for a few seconds until the OS has time to
clean-up the locks.
Seconds?
Try log off and log on again, and if that
Guillaume Lelarge [EMAIL PROTECTED] writes:
To get the list of relations to move, the user needs to be connected to
the database.
Why? If what you are doing is changing the database's default
tablespace (which IMHO is what such a command ought to do) then
all you have to do is bulk-copy the
SlruPhysicalReadPage() succeeds InRecovery if the file does not exist.
BUT, if the file exists but is wrong size then it will still fail even
InRecovery.
This seems inconsistent. Why is the first page OK to be created, but any
other pages after that cause failure? ISTM the first page is nothing
I am facing problem in tracing in what events the selectivity
histogram in pg_statistic is stored/updated.
I went through the code in src/backend/commands/analyze.c and got to
see the code computing the histogram but when I tried to trace the
caller of analyze_rel or compute_index_stats, I find
Andrew Chernow wrote:
Tom Lane wrote:
Hmm. Now that you mention it, didn't we solve a similar problem by
exploiting the behavior where CreateProcess creates a process but
doesn't start it running? I'm envisioning
* Create child process in suspended state
* Assign it ownership of a
Simon Riggs [EMAIL PROTECTED] writes:
This seems inconsistent. Why is the first page OK to be created, but any
other pages after that cause failure? ISTM the first page is nothing
special.
It's special on the writing side, I'm not sure why the reading side
wouldn't treat it specially too.
rahulg escribió:
Can anybody tell me in what all events is the pg_statistic table
exactly updated?
only ANALYZE
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list
rahulg wrote:
I am facing problem in tracing in what events the selectivity
histogram in pg_statistic is stored/updated.
I went through the code in src/backend/commands/analyze.c and got to
see the code computing the histogram but when I tried to trace the
caller of analyze_rel or
On Wed, Oct 15, 2008 at 11:29 AM, Tom Lane [EMAIL PROTECTED] wrote:
Decibel! [EMAIL PROTECTED] writes:
Since this is something that's not supposed to happen, making it a
WARNING might be appropriate too...
Uh, the complaint was that the message is too noisy, not that it isn't
noisy enough.
On Tue, 2008-10-14 at 18:50 +0100, Simon Riggs wrote:
I've worked out what I think is a workable, efficient process for
deriving snapshots during recovery. I will be posting a patch to show
how this works tomorrow [Wed 15 Oct], just doing cleanup now.
How will this interact with an idea like
On Wed, 2008-10-15 at 12:58 -0700, Jeff Davis wrote:
On Tue, 2008-10-14 at 18:50 +0100, Simon Riggs wrote:
I've worked out what I think is a workable, efficient process for
deriving snapshots during recovery. I will be posting a patch to show
how this works tomorrow [Wed 15 Oct], just
Robert Haas [EMAIL PROTECTED] writes:
A much better solution would be to not print the warning every time.
I think the right solution is to do exactly what you rejected
upthread, namely adding some kind of stack to track the last time this
was printed.
I really doubt that the problem is worth
Sorry for top posting - darn phone...
1) as I mentioned when I reviewed the patch in commitfest I don't see
the point of the manual memory management. Palloc/realloc has just the
same kind of doubling behaviour behind the scenes anyways. Just call
realloc before adding every new element.
2008/10/15 Decibel! [EMAIL PROTECTED]:
If the patch was submitted back in 2005 and nothing's happened since then
I'd say the author probably lost interest, which means that it won't be
added until someone else gets interested in it. So I'd suggest either
rolling up your sleeves or dangling a
2008/10/15 Greg Stark [EMAIL PROTECTED]:
Sorry for top posting - darn phone...
1) as I mentioned when I reviewed the patch in commitfest I don't see the
point of the manual memory management. Palloc/realloc has just the same kind
of doubling behaviour behind the scenes anyways. Just call
Greg Stark [EMAIL PROTECTED] writes:
Come to think of it though... Do we require creators of new aggregates
own the state transition function? If not we have a problem...
No, but they are required to have permission to call it. So you could
restrict the transition function to superusers if
Alvaro Herrera escreveu:
Maybe we could add a category bitmask for which each option would be
valid.
The category tests are fine, that's why I introduced relopt_gen.kind but
I'm not using it yet. I'll try to refactor it to use bitmask (some
options could be used to both -- fillfactor) and to
Euler Taveira de Oliveira wrote:
Alvaro Herrera escreveu:
Maybe we could add a category bitmask for which each option would be
valid.
The category tests are fine, that's why I introduced relopt_gen.kind but
I'm not using it yet.
Ah, right, I hadn't noticed the kind stuff, maybe
Can autovacuum just set a flag on the orphaned temp table's pg_class
record indicating it's been determined to be an orphan? Then other
tools could easily list orphaned tables and offer to delete them.
greg
On 15 Oct 2008, at 10:52 PM, Tom Lane [EMAIL PROTECTED] wrote:
Robert Haas [EMAIL
Greg Stark escribió:
Can autovacuum just set a flag on the orphaned temp table's pg_class
record indicating it's been determined to be an orphan? Then other tools
could easily list orphaned tables and offer to delete them.
Add a new column to pg_class just for orphan tables? Sure sounds
On Wed, 2008-10-15 at 15:13 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
This seems inconsistent. Why is the first page OK to be created, but any
other pages after that cause failure? ISTM the first page is nothing
special.
It's special on the writing side, I'm not sure
2008/10/15 Ian Caulfield [EMAIL PROTECTED]:
I started to look at implementing array_agg by making the existing
intagg stuff more generic
... and here's what I've come up with.
I've currently implemented this as a contrib module to make it quicker
to develop/test.
The aggregate uses the same
Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
I think we could use row-level access control to prevent people from
seeing databases they should not see in pg_database.
The row-level database ACL which I submitted yesterdat does not allow
to assign ACLs to tuples within system
Decibel! [EMAIL PROTECTED] wrote:
How hard would it be to dump this information to a table, or some
other more-permanent form of storage? Of course there would need to
be some means of cleaning that up over time, but if it's a simple
table you can DELETE from, we could put the burden
ITAGAKI Takahiro wrote:
We need to avoid using normal UPDATEs to increment counters
because it requires row-level exclusive locks and kills concurrency.
My idea was modifying heap tuples directly in pages:
buffer = ReadBuffer(stats_rel, blknum);
LockBuffer(buffer,
Alvaro Herrera [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro wrote:
My idea was modifying heap tuples directly in pages:
heap_inplace_update?
It writes WAL. I don't think we need WAL here,
and it is enough to write out pages every checkpoints.
Regards,
---
ITAGAKI Takahiro
NTT Open Source
Tom Lane [EMAIL PROTECTED] wrote:
It's probably not worth the trouble to do that, but maybe we could just
have a FRONTEND_DEBUG compile time switch:
That would at least leave the code in place if anyone needed the
debugging output badly enough to do a custom build.
It would be a simplest
I noticed a minor leak in the per-query context when ExecReScanAgg()
is called for a hashed aggregate. During rescan, build_hash_table() is
called to create a new empty hash table in the aggcontext. However,
build_hash_table() also constructs the hash_needed column list in
the per-query context,
I've been taking a look at this as well and came up with a slightly
different approach. The attached patch is intended to go in core (not
contrib) and uses some array-construction facilities that already
exist in core. I'm not sure which approach is better, so I'll throw
this out there with
Andrew Dunstan wrote:
Bruce,
did you ever look at completing this?
No, it is still in my email box unaddressed. Feel free to work on it; I
doubt I can do it for 8.4.
---
cheers
andrew
Andrew Dunstan wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Okay, so I'll let you deal with this for a while yet. A minor
suggestion: label the enum members distinctively, i.e. instead of
RO_BOOL perhaps use RELOPT_TYPE_BOOL, and RO_HEAP should be
RELOPT_KIND_HEAP (note this cannot be a plain enum, each
68 matches
Mail list logo
