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 ca
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 Dunsta
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 yours
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,
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 simple
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 Sou
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, BUFFER_LOCK_
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 bur
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 c
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 sam
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
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
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" <[EM
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, m
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
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 i
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 cal
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 dangl
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.
"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 i
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], jus
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, 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
> nois
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 compute_index_
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 (pgsql-hac
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.
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 ou
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
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
> 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 t
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 in
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 lo
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 ge
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
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 t
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
> wh
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 t
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 beha
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 a
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
> exclus
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, it
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 favors
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 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
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
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
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 relopti
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] sugg
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()
> -> _dosmaper
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 remi
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-hack
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
>>
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 re
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 backe
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 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 the
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 Archite
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
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 (
"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?
>
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 ne
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
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
> instal
> 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 peo
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 th
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
li
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
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
> >
68 matches
Mail list logo
