Hi folks,
Was recently poked and reminded that this patch may be of interest to
the community. It was mostly done as an academic exercise, just to see
how it works, and so it has a rather hackish feel. The patch adds the
sequence owner, if available, to psql's \d output, as
suggested in a recen
FWIW,
I have experienced some oddities in performing SELECT statements after
restarting on an 8.2 system, whereby I occasionally would get a ton of
duplicate records when I would do a select statement (my assumption is that
they are deleted tuples being returned). If I executed the same select
sta
Abhijit Menon-Sen wrote:
> At 2008-09-22 12:54:34 -0500, [EMAIL PROTECTED] wrote:
> >
> > can we tell there is consensus in create a new has_sequence_privilege()?
> > Abhijit will you make it? if not i can make a try...
>
> Yes, I'll do it.
This hasn't been done so I added it to the TODO list.
-
Patch applied, thanks.
---
Robert Haas wrote:
> > I had a deeper look at this now. The patch looks clean and applies without
> > any problems, regression tests passes. However, ATRewriteTables() has a
> > problem when adding
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > KaiGai Kohei wrote:
> I don't oppose to elimination of "--disable-row-acl" options, however,
> it is not clear for me whether it should be unavoidable selection in
> the future, or not.
> >>> Look at the existing configure options; we d
Andrew Chernow wrote:
I don't think view-based security solves my problem. I need to limit
a user to 20 fixed queries, for example. That means the user cannot
execute "SELECT NOW()" or "SELECT 'hello world'". The user can only
execute a pre-defined list of queries.
Put your queries i
Kurt Harriman wrote:
The foremost opposing argument seems to have been that there
should be no attempt to alleviate the existing reserved word
problem without automatic enforcement to guarantee that never
in the future can new occurrences be introduced.
Is there anything in the source that would
Greg Smith wrote:
> On Fri, 5 Dec 2008, Robert Treat wrote:
>
> > Might I suggest you collect all of these various arguments (both for and
> > against) and patches into a wiki page on the developers wiki?
>
> I'm getting the feeling this is going to take a while to sort out too.
> Page with most
That might only be the case when the pg_statistic record is in shared
buffers.
Also I wonder if eqjoinsel and company might need to be made more
toast-aware by detoasring all the things it needs once rather than
every time it accesses them.
greg
On 6 Dec 2008, at 06:19 PM, "Robert Haas"
Grzegorz Jaskiewicz wrote:
On 2008-12-06, at 18:30, Andrew Chernow wrote:
Grzegorz Jaskiewicz wrote:
On 2008-12-06, at 18:21, Andrew Chernow wrote:
Looking for a way to limited a user to a specific set of queries. I
don't think this can be done right now ... or can it? Has this
feature re
It's slow because there's no way around running through the entire
input. The optimization tmp is talking about wouldn't be relevant
becase there is an order by clause which was precisely why I I said it
was a fairly narrow use case. Most people who use limit want a
specific subset even if
On 2008-12-06, at 18:30, Andrew Chernow wrote:
Grzegorz Jaskiewicz wrote:
On 2008-12-06, at 18:21, Andrew Chernow wrote:
Looking for a way to limited a user to a specific set of queries.
I don't think this can be done right now ... or can it? Has this
feature request surfaced in the past
Grzegorz Jaskiewicz wrote:
On 2008-12-06, at 18:21, Andrew Chernow wrote:
Looking for a way to limited a user to a specific set of queries. I
don't think this can be done right now ... or can it? Has this
feature request surfaced in the past?
I currently need this as an extra security mea
On 2008-12-06, at 18:21, Andrew Chernow wrote:
Looking for a way to limited a user to a specific set of queries. I
don't think this can be done right now ... or can it? Has this
feature request surfaced in the past?
I currently need this as an extra security measure for a libpq
client
Looking for a way to limited a user to a specific set of queries. I don't think
this can be done right now ... or can it? Has this feature request surfaced in
the past?
I currently need this as an extra security measure for a libpq client app (want
to block arbitrary queries from malicious a
Sorry for top posting but we are getting a bit far afield from the
original topic. I followed up the tests I did last night:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00369.php
I benchmarked 100 iterations of EXPLAIN on the query Greg Stark put
together as a synthetic benchmark for
On 2008-12-06, at 11:29, David Lee Lambert wrote:
I use "ORDER BY random() LIMIT :some_small_number" frequently to get
a "feel"
for data. That always builds the unrandomized relation and then
sorts it. I
guess an alternate path for single-table queries would be to
randomly choose
a bl
Pavan Deolasee wrote:
/*
* Size of the bitmap on each visibility map page, in bytes. There's no
* extra headers, so the whole page minus except for the standard page
header
* is used for the bitmap.
*/
#define MAPSIZE (BLCKSZ - SizeOfPageHeaderData)
ISTM that we should MAXALIGN the SizeOfPa
Pavan Deolasee wrote:
On Sat, Dec 6, 2008 at 7:57 PM, Heikki Linnakangas <
[EMAIL PROTECTED]> wrote:
Umm, what non-atomic state could the bit be in? Half-set, half-cleared? Or
do you think that if some other bit in proximity is changed, the other bit
would temporarily flip 0->1->0, or something
On Sat, Dec 6, 2008 at 7:57 PM, Heikki Linnakangas <
[EMAIL PROTECTED]> wrote:
>
> Umm, what non-atomic state could the bit be in? Half-set, half-cleared? Or
> do you think that if some other bit in proximity is changed, the other bit
> would temporarily flip 0->1->0, or something like that? I don
Pavan Deolasee wrote:
ISTM that the PD_ALL_VISIBLE flag and the visibility map bit can be set at
the end of pruning operation if we know that there are only tuples visible
to all transactions left in the page.
Right.
The way pruning is done, I think it
would be straight forward to get this in
Pavan Deolasee wrote:
/*
* We don't need to lock the page, as we're only looking at a single
bit.
*/
result = (map[mapByte] & (1 << mapBit)) ? true : false;
Isn't this a dangerous assumption to make ? I am not so sure that even a bit
can be read atomically on all platforms.
Guillaume Smet wrote:
On Sat, Dec 6, 2008 at 12:53 PM, hubert depesz lubaczewski
<[EMAIL PROTECTED]> wrote:
First run - without visibility maps, timing of vacuums:
Time: 267844.822 ms
Time: 138854.592 ms
Time: 305467.950 ms
Time: 487133.179 ms
Second run - on head:
Time: 252218.609 ms
Time: 23
On Sat, Dec 6, 2008 at 12:53 PM, hubert depesz lubaczewski
<[EMAIL PROTECTED]> wrote:
> First run - without visibility maps, timing of vacuums:
> Time: 267844.822 ms
> Time: 138854.592 ms
> Time: 305467.950 ms
> Time: 487133.179 ms
>
> Second run - on head:
>
> Time: 252218.609 ms
> Time: 234388.76
--- repost to hackers as suggested by RhodiumToad ---
hi,
i tried to test new "visibility map" feature.
to do so i:
1. fetched postgresql sources from cvs
2. compiled
3. turned autovacuum off
4. started pg
5. ran this queries:
- CREATE TABLE test_1 (i INT4);
- CREATE TABLE test_2 (i INT4);
On Thursday 04 December 2008 15:09, Gregory Stark wrote:
> tmp <[EMAIL PROTECTED]> writes:
> > Also, it is my impression that many people use LIMIT to minimize the
> > evaluation time of sub queries from which the outer query only needs a
> > small subset of the sub query output.
>
> I've seen lot
Greetings!
On Fri, Dec 5, 2008 at 6:59 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-12-05 at 16:00 +0900, Fujii Masao wrote:
>
>> On Fri, Dec 5, 2008 at 12:09 PM, Fujii Masao <[EMAIL PROTECTED]> wrote:
>> >> I was expecting you to have walreceiver and startup share an end of WAL
>>
Hi,
On Fri, Dec 5, 2008 at 7:09 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-12-05 at 12:09 +0900, Fujii Masao wrote:
>
>> On Thu, Dec 4, 2008 at 6:29 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>> > The only sensible settings are
>> > synchronous_commit = on, synchronous_replication
28 matches
Mail list logo
