On Sat, Jan 3, 2009 at 21:56, Philip Warner wrote:
> Alex Hunsaker wrote:
>> For the record I just imported a production database that sits at
>> about ~20G right now with *zero* size increase (rounding to the
>> nearest gigabyte). That's with basically the exact same schema just
>> different dat
Alex Hunsaker wrote:
> For the record I just imported a production database that sits at
> about ~20G right now with *zero* size increase (rounding to the
> nearest gigabyte). That's with basically the exact same schema just
> different data.
>
>
Guessing you don't have many plain text rows >
On Sat, Jan 3, 2009 at 20:47, Philip Warner wrote:
> Tom Lane wrote:
>> It would be fairly easy, I think, to add some reloption fields that
>> would let these parameters be controlled on a per-table level.
>> Per-column would be much more painful; do we really need that?
>>
>
> Another +1 on the p
KaiGai Kohei wrote:
> If it is provided for v8.4, I'm happy at least.
> The Row-level ACLs need its reloption to specify default ACLs in string
> expression. Currently, it modifies "reloptions.c", but using it on common
> framework will be more appropriate implementation.
Modified to add a string
Tom Lane wrote:
> It would be fairly easy, I think, to add some reloption fields that
> would let these parameters be controlled on a per-table level.
> Per-column would be much more painful; do we really need that?
>
Another +1 on the per-table setting. Or a config file setting to disable
this
Now that we are two months into the final commit fest, it is time to
finalize all the open patches so we can target a February beta.
The two major outstanding patches are:
o SE-PostgreSQL: The author has done an outstanding job of
reworking the patch so the burden is now on the communit
On Sunday 04 January 2009 00:53:51 Gregory Stark wrote:
> Peter Eisentraut writes:
> > On Wednesday 31 December 2008 02:33:26 Kevin Grittner wrote:
> >> I'm still working on section "Serializable Isolation versus True
> >> Serializability", but here are all the changes I can see which precede
> >>
On Saturday 03 January 2009 03:36:16 Tom Lane wrote:
> "Stephen R. van den Berg" writes:
> > - I currently have difficulty imagining applications that actually do
> > lots of substring extractions from large compressible fields.
>
> The code that's in there to make this happen was written by peo
Peter Eisentraut writes:
> On Wednesday 31 December 2008 02:33:26 Kevin Grittner wrote:
>> I'm still working on section "Serializable Isolation versus True
>> Serializability", but here are all the changes I can see which precede
>> it. Has the review of the SQL specs convinced everyone that thi
Peter Eisentraut writes:
> On Friday 02 January 2009 06:49:57 Greg Stark wrote:
>> The guc run-time check is checking for known-buggy versions of glibc
>> using sysconf to check what version of glibc you have.
>
> Could you please mention the bug number in the relevant source code comments?
It
On Friday 02 January 2009 22:23:13 Stephen R. van den Berg wrote:
> Three things:
> a. Shouldn't it in theory be possible to have a decompression algorithm
>which is IO-bound because it decompresses faster than the disk can
>supply the data? (On common current hardware).
> b. Has the curre
Joe Conway wrote:
Peter Eisentraut wrote:
Martin had sent some code for that with his original patch series. I
or someone can review that next.
Here is what I would propose (still needs documentation and regression
test changes, but wanted feedback first). I think it is better to keep
the c
On Saturday 27 December 2008 20:32:10 Ron Mayer wrote:
> ISTM ISO should hire you guys (or the postgres project as a whole)
> to proof-read their specs before they publish them.
The way it really works though, effectively, is that vendors hire ISO to
publish their specs.
Having a few inconsisten
On Tuesday 30 December 2008 19:28:01 Kevin Grittner wrote:
> Here we go. I've labeled the transactions consistently with new
> thread I started trying to characterize the full scope of issues and
> workarounds.
OK, I believe it now. :-)
The missing predicate locking is again at fault here. Beca
On Wednesday 31 December 2008 02:33:26 Kevin Grittner wrote:
> I'm still working on section "Serializable Isolation versus True
> Serializability", but here are all the changes I can see which precede
> it. Has the review of the SQL specs convinced everyone that this much
> is appropriate?
I don'
On Friday 02 January 2009 06:49:57 Greg Stark wrote:
> The guc run-time check is checking for known-buggy versions of glibc
> using sysconf to check what version of glibc you have.
Could you please mention the bug number in the relevant source code comments?
--
Sent via pgsql-hackers mailing l
Alex,
* Alex Hunsaker (bada...@gmail.com) wrote:
> Now it looks bogos but why not just move errmsg_col down to where we
> actually use it? Or am I missing something?
Honestly, I think at this point is makes the most sense to just remove
it entirely, which I've done in the attached patch.
I wrote:
Attached is the latest parallel restore patch. I think this is getting
fairly close.
Includes help text, docco and some extra error checking.
I propose to commit this unless someone wants more time for reviewing.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-h
On Fri, Jan 2, 2009 at 16:11, Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
>> Please find attached an updated patch for column-level privileges
>> which incorporates Alvaro's suggested changes and is updated to the
>> latest CVS HEAD.
Hi!
This gives me
aclchk.c: In fu
Simon Riggs a écrit :
> On Fri, 2009-01-02 at 17:35 +, Simon Riggs wrote:
>
>>> I use latest CVS version. I tried to apply the patches and I have the
>>> following error :
>> Thanks, will fix.
>
> Fixed various bit rots and re-packaged. v6a now up, v6 unlinked.
>
Thanks. I only did a few ch
I notice that the pg_stat_statements patch is applying pg_mbcliplen()
to query strings, in the fond illusion that it knows what encoding
they are in.
This brings up a bigger issue, namely that pg_stat_activity isn't
exactly encoding-proof either --- whatever encoding is in use in a
particular data
Tom Lane wrote:
> Alvaro Herrera writes:
>> I need some more opinions on whether I should continue working here, or
>> stop and leave it for 8.5.
>
> Bruce and I were just talking yesterday about the need to start closing
> down this commitfest. I'm not sure what the schedule is going to end
> u
ITAGAKI Takahiro writes:
> "Alex Hunsaker" wrote:
>> How about just pg_stat_statements.track ?
> I renamed the variables to:
> - pg_stat_statements.limit
> - pg_stat_statements.track
> - pg_stat_statements.saved_file
Hmm, this has got a problem:
regression=# show pg_stat_statements
"Alex Hunsaker" writes:
> Right I agree this is a non-issue. For that matter if I really wanted
> to muck with it I could just set
> process_shared_preload_libraries_in_progress = true in my _PG_init
> function. And I guess if anyone thinks thats a problem we can mark
> the flag as static and on
On Fri, Jan 2, 2009 at 20:20, Tom Lane wrote:
> I wrote:
>> * the startup/shutdown hooks will be installed in the postmaster
>> process, but the patch expects them to be executed in a child process.
>> I think nothing will happen.
>
> OK, I figured out what is happening there: the patch makes it w
Tom Lane wrote:
I think you should break those three functions apart. There is no value
in having send_query share any code with the others. It might be
feasible to have the other two share a subroutine that collects the
result data.
OK, will do. I applied the simple fix to the 8.2 and 8.3 br
On Sat, Jan 3, 2009 at 09:37, Tom Lane wrote:
> I wrote:
>> ... This doesn't actually work in the current system.
>
> I have a solution for this, I think. I propose that guc.c only allow
> custom PGC_POSTMASTER variables to be created during
> process_shared_preload_libraries().
Sounds simple en
Alvaro Herrera writes:
> I need some more opinions on whether I should continue working here, or
> stop and leave it for 8.5.
Bruce and I were just talking yesterday about the need to start closing
down this commitfest. I'm not sure what the schedule is going to end
up being; but if you can't se
I wrote:
> ... This doesn't actually work in the current system.
I have a solution for this, I think. I propose that guc.c only allow
custom PGC_POSTMASTER variables to be created during
process_shared_preload_libraries(). (The implementation for this
would involve exporting a bool flag that pro
Simon Riggs wrote:
> If you really can't see a use for this, OK, then: Please can you put in
> a plugin API for user defined reloptions as well as what you are
> proposing. We discussed this before in late July/early Aug on thread
> "Uncopied parameters..."
Hmm, I was just looking at the CREATE
KaiGai Kohei wrote:
> Alvaro Herrera wrote:
>> No, it doesn't. I asked about it some time ago and nobody answered. If
>> people feel it is important, I can implement it.
>
> Oh, I missed to see the message.
>
> If it is provided for v8.4, I'm happy at least.
> The Row-level ACLs need its relopti
Alvaro Herrera wrote:
KaiGai Kohei wrote:
Alvaro Herrera wrote:
So this is an updated patch. This now allows a user-defined AM to
create new reloptions and pass them down to the parser for parsing and
checking.
This patch does not support reloptions in string expression, like:
No, it does
On Sat, 2009-01-03 at 12:20 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > I very much like the idea of adding new/custom options to tables. There
> > are many uses for that.
>
> Hmm, like what? I'm not sure how would it work for tables; you'd have
> to add the options during _PG_init
Joe Conway writes:
> On line 795 below, fail should get set to PG_GETARG_BOOL(1). However, as
> line 842 is about to be executed, fail is still set to true, even though
> PG_GETARG_BOOL(1) is clearly false. Any ideas?
I can't duplicate that here, but my first reaction on studying this code
is "
Dave Page wrote:
> Are we expecting this patch (or whatever it turns into) to go into
> 8.4? It was marked as WIP when feature freeze started and clearly
> still is quite undefined at this stage.
Right. This is a fair objection. I started just by reviewing the
autovacuum-in-reloptions patch, bu
Simon Riggs wrote:
> I very much like the idea of adding new/custom options to tables. There
> are many uses for that.
Hmm, like what? I'm not sure how would it work for tables; you'd have
to add the options during _PG_init or something like that, and I haven't
tried it. It's mainly for user-de
KaiGai Kohei wrote:
> Alvaro Herrera wrote:
> > So this is an updated patch. This now allows a user-defined AM to
> > create new reloptions and pass them down to the parser for parsing and
> > checking.
>
> This patch does not support reloptions in string expression, like:
No, it doesn't. I as
On Tue, 2008-12-30 at 12:31 -0300, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Tom Lane wrote:
> > > Alvaro Herrera writes:
> >
> > > > I'm intending to have a new routine which would reserve a value at
> > > > runtime. This value would be later be passed by the AM to create new
> > > > o
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> Alvaro Herrera writes:
I'm intending to have a new routine which would reserve a value at
runtime. This value would be later be passed by the AM to create new
options on the table.
>>> What do you mean by "at runt
On Wed, Dec 31, 2008 at 9:45 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Peter Eisentraut wrote:
>>> On Sunday 21 December 2008 01:48:42 Alvaro Herrera wrote:
ALTER TABLE foo SET (TOAST autovacuum_enabled = false);
ALTER TABLE foo SET (toast.autovacuum_enabled = false);
ALTER T
Tom Lane wrote:
>and I'm still pretty worried about the longevity of any knob we put in
>here. But we might not have a lot of choice.
>It would be fairly easy, I think, to add some reloption fields that
>would let these parameters be controlled on a per-table level.
>Per-column would be much more
On Fri, 2009-01-02 at 19:27 -0700, Alex Hunsaker wrote:
> On Fri, Jan 2, 2009 at 18:30, Tom Lane wrote:
> > "Alex Hunsaker" writes:
> >> On Fri, Jan 2, 2009 at 11:44, Tom Lane wrote:
> >>> An easy way to prove or disprove the point would be to go into
> >>> src/backend/utils/adt/pg_lzcompress.c
On Fri, 2009-01-02 at 17:35 +, Simon Riggs wrote:
> > I use latest CVS version. I tried to apply the patches and I have the
> > following error :
>
> Thanks, will fix.
Fixed various bit rots and re-packaged. v6a now up, v6 unlinked.
Thanks,
--
Simon Riggs www.2ndQuadrant.com
On Fri, 2009-01-02 at 13:47 -0500, Tom Lane wrote:
> "Kevin Grittner" writes:
> >> What do you mean by referential integrity? I don't believe you can
> >> construct a foreign key problem at any transaction isolation level.
>
> > I mean that if someone attempts to maintain referential integrity
44 matches
Mail list logo
