Hi,
> I'm not very impressed with that patch, even discounting the
> sum-vs-product thinko. Trawling the tlist for SRFs will add a significant
> number of cycles, to modify the rowcount in a way that is practically
> always wrong (since the estimates for SRF output rowcounts are so bad).
It's tr
On Mon, Apr 19, 2010 at 8:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 19, 2010 at 7:18 PM, Tom Lane wrote:
>>> Hmm. The AV launcher is only permitted to touch pg_database.
>
>> Perhaps we should add a TODO.
>
> Actually, while I'm looking at that code, a more immediate TODO is
>
On Mon, Apr 19, 2010 at 10:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 19, 2010 at 9:51 PM, Tom Lane wrote:
>>> The problem is that making a "custom" variable SUSET doesn't really
>>> work: the system will not accept a value that's assigned before the
>>> loadable module is loade
Robert Haas writes:
> On Mon, Apr 19, 2010 at 9:51 PM, Tom Lane wrote:
>> The problem is that making a "custom" variable SUSET doesn't really
>> work: the system will not accept a value that's assigned before the
>> loadable module is loaded, even if it was assigned by a superuser.
>> I suggested
Takahiro Itagaki writes:
> Nikhil Sontakke wrote:
>> I think the place where we set the
>> targetlist of the result_plan to sub_tlist, immediately after that we
>> should update the plan_rows estimate by walking this latest
>> targetlist. I did that and now we seem to get proper row estimates.
>
On Fri, Apr 2, 2010 at 2:06 AM, Fujii Masao wrote:
> On Fri, Apr 2, 2010 at 2:58 AM, Robert Haas wrote:
>> It's probably also easy to fix so that it doesn't NEED to be documented.
>>
>> The thing is, when dealing with new features, we reduce our overall
>> maintenance burden if we get it right th
On Mon, Apr 19, 2010 at 9:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> This thread is still on the open items list, as:
>> Improve behavior of SUSET GUC variables added by loadable modules?
>> Is there something that needs to be done here? If so, what is it?
>
> Well, if we knew exactly what
Robert Haas writes:
> This thread is still on the open items list, as:
> Improve behavior of SUSET GUC variables added by loadable modules?
> Is there something that needs to be done here? If so, what is it?
Well, if we knew exactly what to do, it wouldn't still be on the list.
The problem is th
On Mon, Apr 19, 2010 at 9:23 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > Well, the point is that you are getting it for _unusual_ circumstances.
>> > Seems it is only when you are getting it for typical workloads that it
>> > should be increased.
>>
>> I guess. I am not sure we should cons
Peter Eisentraut wrote:
> On tor, 2010-04-15 at 20:56 -0400, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > Apparently, pgindent replaces multiple spaces in comments by a tab
> > > (possibly subject to additional logic). An example among thousands:
> > >
> > > http://git.postgresql.org/gi
Robert Haas wrote:
> > Well, the point is that you are getting it for _unusual_ circumstances.
> > Seems it is only when you are getting it for typical workloads that it
> > should be increased.
>
> I guess. I am not sure we should consider "doing a large CTAS" to be
> an unusual workload, though
On Thu, Nov 12, 2009 at 6:31 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> With all this fallout, I think it would be cleaner to step back and make
>> it a regular GUC variable, not custom. Pretending that plpgsql is
>> somehow not an integral part of the system is not completely true
>> anywa
On Fri, Apr 16, 2010 at 9:47 PM, Robert Haas wrote:
> On Thu, Apr 15, 2010 at 6:13 PM, Robert Haas wrote:
>> On Thu, Apr 15, 2010 at 2:54 AM, Heikki Linnakangas
>> wrote:
>>> Robert Haas wrote:
I've realized another problem with this patch. standby_keep_segments
only controls the numb
Nikhil Sontakke wrote:
> I observed the following behavior on PG head:
> postgres=# explain verbose insert into public.x values
> (generate_series(1,10));
>
> Insert (cost=0.00..0.01 rows=1 width=0)
Hmmm, there are differences between "SELECT
On Thu, Jan 7, 2010 at 11:55 AM, Magnus Hagander wrote:
>>> BUG #5245: Full Server Certificate Chain Not Sent to client
>>> http://archives.postgresql.org/pgsql-bugs/2009-12/msg00145.php
>>
>> Not clear to me whether this is a bug, or at least our bug.
>
> It's not a bug, it's potentially a featu
Robert Haas writes:
> On Mon, Apr 19, 2010 at 7:18 PM, Tom Lane wrote:
>> Hmm. The AV launcher is only permitted to touch pg_database.
> Perhaps we should add a TODO.
Actually, while I'm looking at that code, a more immediate TODO is
"fix walsender". Somebody has inserted an absolutely flight
On Mon, Apr 19, 2010 at 7:18 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Robert Haas escribió:
>>> Would it be possible to set up a skeleton environment where we can
>>> access shared catalogs only and then decide on which database we're
>>> using later?
>
>> Eh? We already do that ... In fa
Simon Riggs writes:
> There is a command to set privileges
> GRANT SELECT ON ALL TABLES IN SCHEMA foo TO PUBLIC;
> and a command to set default privileges
> ALTER DEFAULT PRIVILEGES IN SCHEMA foo
> GRANT SELECT ON TABLES TO PUBLIC;
> In the first command the ALL is required, whereas in t
Alvaro Herrera writes:
> Robert Haas escribió:
>> Would it be possible to set up a skeleton environment where we can
>> access shared catalogs only and then decide on which database we're
>> using later?
> Eh? We already do that ... In fact the autovac launcher is always
> connected to shared ca
Simon Riggs writes:
> With code as currently, yes, though I see that there is a way to do
> this.
> Rules that have an "all" in the database field of the hba can be applied
> prior to attempting to select the database, as long as the "all" rule is
> above any database-specific rules.
Well, that
Kevin Grittner wrote:
Perhaps, but be aware the current default benchmarked better
than a larger setting in bulk loads.
http://archives.postgresql.org/pgsql-hackers/2009-06/msg01382.php
The apparent reason is that when there were fewer of them the WAL
files were re-used before the RAID contr
Robert Haas wrote:
>> However, this is the first time I am hearing that
>> battery-backed cache favors the default value.
Well, it was discussed on the lists during a CommitFest.
> ...if that's as bad as it gets, I'm still not sure we shouldn't
> increase the default. Most people will not h
On Mon, Apr 19, 2010 at 6:06 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Apr 19, 2010 at 5:36 PM, Bruce Momjian wrote:
>> >> I don't actually know what's best. ?I'm just concerned that we have a
>> >> default in postgresql.conf and a tuning guide that says "don't do
>> >> that". ?May
Robert Haas wrote:
> On Mon, Apr 19, 2010 at 5:36 PM, Bruce Momjian wrote:
> >> I don't actually know what's best. ?I'm just concerned that we have a
> >> default in postgresql.conf and a tuning guide that says "don't do
> >> that". ?Maybe the tuning guide needs to be more nuanced, or maybe
> >> p
On Mon, 2010-04-19 at 17:52 -0400, Robert Haas wrote:
> On Mon, Apr 19, 2010 at 5:22 PM, Simon Riggs wrote:
> > On Mon, 2010-04-19 at 17:08 -0400, Robert Haas wrote:
> >
> >> Oh. Then I'm confused. Tom said: "as of 9.0, it's necessary to
> >> connect to some database in order to proceed with aut
On Mon, Apr 19, 2010 at 5:31 AM, Fujii Masao wrote:
> On Mon, Apr 19, 2010 at 11:04 AM, Robert Haas wrote:
>>> First of all, I wonder why the latter two need to affect the decision of
>>> whether additional information is written to WAL for HS. How about just
>>> removing XLogIsNeeded() condition
On Mon, Apr 19, 2010 at 5:22 PM, Simon Riggs wrote:
> On Mon, 2010-04-19 at 17:08 -0400, Robert Haas wrote:
>
>> Oh. Then I'm confused. Tom said: "as of 9.0, it's necessary to
>> connect to some database in order to proceed with auth checking". Why
>> is that necessary
>
> It's not, I just expl
On Mon, Apr 19, 2010 at 5:12 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Mon, Apr 19, 2010 at 5:04 PM, Alvaro Herrera
>> wrote:
>> > Robert Haas escribió:
>> >> On Mon, Apr 19, 2010 at 4:30 PM, Tom Lane wrote:
>> >
>> >> > The only way I can think of to improve that without going bac
On Mon, Apr 19, 2010 at 5:36 PM, Bruce Momjian wrote:
>> I don't actually know what's best. I'm just concerned that we have a
>> default in postgresql.conf and a tuning guide that says "don't do
>> that". Maybe the tuning guide needs to be more nuanced, or maybe
>> postgresql.conf needs to be ch
Simon Riggs escribió:
> On Mon, 2010-04-19 at 17:08 -0400, Robert Haas wrote:
>
> > Oh. Then I'm confused. Tom said: "as of 9.0, it's necessary to
> > connect to some database in order to proceed with auth checking". Why
> > is that necessary
>
> It's not, I just explained how to do it without
Robert Haas wrote:
> On Mon, Apr 19, 2010 at 10:21 AM, Kevin Grittner
> wrote:
> > Robert Haas wrote:
> >
> >> 2. Reading the section on checkpoint_segments reminds me, again,
> >> that the current value seems extremely conservative on modern
> >> hardware. ?It's quite easy to hit this when doing
There is a command to set privileges
GRANT SELECT ON ALL TABLES IN SCHEMA foo TO PUBLIC;
and a command to set default privileges
ALTER DEFAULT PRIVILEGES IN SCHEMA foo
GRANT SELECT ON TABLES TO PUBLIC;
In the first command the ALL is required, whereas in the second command
the ALL must b
On Mon, 2010-04-19 at 17:08 -0400, Robert Haas wrote:
> Oh. Then I'm confused. Tom said: "as of 9.0, it's necessary to
> connect to some database in order to proceed with auth checking". Why
> is that necessary
It's not, I just explained how to do it without.
--
Simon Riggs www.2n
Robert Haas escribió:
> On Mon, Apr 19, 2010 at 5:04 PM, Alvaro Herrera
> wrote:
> > Robert Haas escribió:
> >> On Mon, Apr 19, 2010 at 4:30 PM, Tom Lane wrote:
> >
> >> > The only way I can think of to improve that without going back to flat
> >> > files would be to develop a way for backends to
On Mon, Apr 19, 2010 at 5:04 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Mon, Apr 19, 2010 at 4:30 PM, Tom Lane wrote:
>
>> > The only way I can think of to improve that without going back to flat
>> > files would be to develop a way for backends to switch databases after
>> > initial
Robert Haas escribió:
> On Mon, Apr 19, 2010 at 4:30 PM, Tom Lane wrote:
> > The only way I can think of to improve that without going back to flat
> > files would be to develop a way for backends to switch databases after
> > initial startup, so that auth could be done in a predetermined databas
On Mon, Apr 19, 2010 at 4:30 PM, Tom Lane wrote:
> Simon Riggs writes:
>> Point of note on giving information to the bad guys: if a
>> should-be-rejected connection request attempts to connect to a
>> non-existent database, we say "database does not exist".
>
> Yeah. This was an acknowledged sho
On Mon, 2010-04-19 at 16:30 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > Point of note on giving information to the bad guys: if a
> > should-be-rejected connection request attempts to connect to a
> > non-existent database, we say "database does not exist".
>
> Yeah. This was an acknowledge
Simon Riggs writes:
> Point of note on giving information to the bad guys: if a
> should-be-rejected connection request attempts to connect to a
> non-existent database, we say "database does not exist".
Yeah. This was an acknowledged shortcoming of the changes to eliminate
flat-file storage of
BTW, just for the archives' sake: it took a good long time to develop a
reproducible test case for this. It seems that 99% of the WAL replay
code does *not* depend on the missing state. I was eventually able to
reproduce the case originally reported, namely a crash during
btree_xlog_cleanup; but
On Mon, 2010-04-19 at 14:34 -0400, Tom Lane wrote:
> Anyone see any obvious holes in the idea?
Nothing springs to mind, so worth a try.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
On Thu, 2010-04-15 at 09:44 -0400, Tom Lane wrote:
> Maybe uaImplicitReject for the end-of-file case would be
> the most readable way.
uaImplicitReject capability added.
We're now free to bikeshed on exact wording. After much heavy thinking,
message is "pg_hba.conf rejects..." with no hint (yet?)
I wrote:
> The point is that a standalone backend will fail to execute recovery
> correctly:
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg01297.php
After digging around a bit, it seems like the cleanest solution would be
to move the responsibility for calling StartupXLOG in a standalo
On Mon, 2010-04-19 at 10:55 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2010-04-19 at 17:44 +0300, Heikki Linnakangas wrote:
> >>> Choices are
> >>> 1. Check RecoveryInProgress() once outside of lock, plus wild rumour of
> >>> Murphy
> >>> 2. Check RecoveryInProgress() before and afte
Robert Haas writes:
> One problem with the current implementation of cost_rescan() is that
> it ignores caching effects.
Well, that's intentional, per the head comment for the function.
We might want to extend it later but I'd like to get some field
experience with what it's trying to model now.
Simon Riggs writes:
> On Mon, 2010-04-19 at 11:19 -0400, Tom Lane wrote:
>> If you think we're at the point where this item is the main thing
>> standing between us and beta, I'll go do something about it. I've
>> been waiting for the HS code to settle before trying to design a
>> solution...
>
Hi Simon,
On Sunday 14 March 2010 20:12:00 Simon Riggs wrote:
> On Sun, 2010-03-14 at 19:50 +0100, Andres Freund wrote:
> > On Sunday 14 February 2010 06:29:45 Simon Riggs wrote:
> > > On Sat, 2010-02-13 at 22:37 +0100, Andres Freund wrote:
> > > > I know it is late in the cycle
> > >
> > > No pr
On Mon, Apr 19, 2010 at 18:24, Peter Eisentraut wrote:
> On mån, 2010-04-19 at 17:02 +0200, Magnus Hagander wrote:
>> The MSVC scripts currently have a "perltidy coding style" so we run
>> perltidy with a specific set of arguments to format the code. (This is
>> in the README). Kind of like pginde
On mån, 2010-04-19 at 17:02 +0200, Magnus Hagander wrote:
> The MSVC scripts currently have a "perltidy coding style" so we run
> perltidy with a specific set of arguments to format the code. (This is
> in the README). Kind of like pgindent.
>
> Should we be doing this on all the perlscripts we us
On Mon, Apr 19, 2010 at 11:19 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 22, 2010 at 9:32 PM, Bruce Momjian wrote:
>>> OK, I re-read it and still don't understand, but I don't have to.
>
>> I re-read it too and I don't understand either.
>
> The point is that a standalone backend
On Mon, 2010-04-19 at 11:19 -0400, Tom Lane wrote:
> If you think we're at the point where this item is the main thing
> standing between us and beta, I'll go do something about it. I've
> been waiting for the HS code to settle before trying to design a
> solution...
I'm not hugely interested in
Magnus Hagander wrote:
The MSVC scripts currently have a "perltidy coding style" so we run
perltidy with a specific set of arguments to format the code. (This is
in the README). Kind of like pgindent.
Should we be doing this on all the perlscripts we use?
And if we do, we should obviously use
Robert Haas writes:
> On Mon, Mar 22, 2010 at 9:32 PM, Bruce Momjian wrote:
>> OK, I re-read it and still don't understand, but I don't have to.
> I re-read it too and I don't understand either.
The point is that a standalone backend will fail to execute recovery
correctly:
http://archives.pos
On Wed, Feb 24, 2010 at 2:11 PM, Bruce Momjian wrote:
> Oleg, Teodor, would you look at this? I see the same behavior in 9.0.
As there has been no movement on this I think we should punt this from:
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
to
http://wiki.postgresql.org/wiki/To
The MSVC scripts currently have a "perltidy coding style" so we run
perltidy with a specific set of arguments to format the code. (This is
in the README). Kind of like pgindent.
Should we be doing this on all the perlscripts we use?
And if we do, we should obviously use the same one everywhere -
On Mon, Mar 22, 2010 at 9:32 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> >> [This is an open item for 9.0, hence the response to an apparently old
>> >> hackers thread]
>>
>> > Thanks for the reply; 9.0 open item removed.
>>
>> I think you misread his reply. Please pu
Simon Riggs writes:
> On Mon, 2010-04-19 at 17:44 +0300, Heikki Linnakangas wrote:
>>> Choices are
>>> 1. Check RecoveryInProgress() once outside of lock, plus wild rumour of
>>> Murphy
>>> 2. Check RecoveryInProgress() before and after holding lock
>>> 3. Check RecoveryInProgress() while holding
On Thu, Feb 18, 2010 at 8:41 PM, Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote:
>> > Basically, configure failed on their OpenBSD system because thread
>> > safety is on but the libxml2 wasn't compiled with threaded support:
>> > http://xmlso
On Mon, 2010-04-19 at 17:44 +0300, Heikki Linnakangas wrote:
> > Choices are
> >
> > 1. Check RecoveryInProgress() once outside of lock, plus wild rumour of
> > Murphy
> >
> > 2. Check RecoveryInProgress() before and after holding lock
> >
> > 3. Check RecoveryInProgress() while holding lock
>
Simon Riggs wrote:
> On Mon, 2010-04-19 at 10:24 -0400, Tom Lane wrote:
>> Robert Haas writes:
>>> On Mon, Apr 19, 2010 at 5:05 AM, Simon Riggs wrote:
It doesn't seem to be something we should place highly on the list of
events we need protection from, does it?
>>> Since when do we not
On Mon, 2010-04-19 at 10:24 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Apr 19, 2010 at 5:05 AM, Simon Riggs wrote:
> >> It doesn't seem to be something we should place highly on the list of
> >> events we need protection from, does it?
>
> > Since when do we not protect against rac
On Mon, Apr 19, 2010 at 10:21 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> 2. Reading the section on checkpoint_segments reminds me, again,
>> that the current value seems extremely conservative on modern
>> hardware. It's quite easy to hit this when doing large bulk data
>> loads or even
Robert Haas writes:
> On Mon, Apr 19, 2010 at 5:05 AM, Simon Riggs wrote:
>> It doesn't seem to be something we should place highly on the list of
>> events we need protection from, does it?
> Since when do we not protect against race-conditions just because
> they're low likelihood?
Murphy's l
Robert Haas wrote:
> 2. Reading the section on checkpoint_segments reminds me, again,
> that the current value seems extremely conservative on modern
> hardware. It's quite easy to hit this when doing large bulk data
> loads or even a big ol' CTAS. I think we should consider raising
> this for
On Fri, Apr 16, 2010 at 09:03, Fujii Masao wrote:
> On Thu, Apr 15, 2010 at 11:26 PM, Robert Haas wrote:
>> I have to admit to finding this confusing. According to the comments:
>>
>> + /*
>> + * Don't emulate the PQexec()'s behavior of returning the
>> last
>> +
Nikhil Sontakke writes:
> I think the semantics should be pretty ok as is. But I saw another DB
> honoring the NOT NULL modifiers and hence the wonder if there is
> something about this in the standards.
Actually, SQL:2008 does say that if an output column of the SELECT is
known not nullable, the
>> Was wondering what are the standards for CTAS. Oracle seems to honor
>> the NOT NULL modifier. This might be a bug if we do not honor
>> modifiers in CTAS.
>
> Given that CREATE TABLE AS creates a table based on the result of a
> query, it seems pretty logical that constraints wouldn't be copied
On Mon, Apr 19, 2010 at 03:59, Takahiro Itagaki
wrote:
>
> Magnus Hagander wrote:
>
>> But I'm unsure how that would work. We're talking about the output of
>> localeconv(), right? I don't see a version of localeconv() that does
>> wide chars anywhere. (You can't just set LC_CTYPE and use the reg
On Mon, Apr 19, 2010 at 5:05 AM, Simon Riggs wrote:
> It doesn't seem to be something we should place highly on the list of
> events we need protection from, does it?
Since when do we not protect against race-conditions just because
they're low likelihood?
...Robert
--
Sent via pgsql-hackers m
On Fri, Apr 16, 2010 at 4:03 PM, Fujii Masao wrote:
> On Thu, Apr 15, 2010 at 11:26 PM, Robert Haas wrote:
>> I have to admit to finding this confusing. According to the comments:
>>
>> + /*
>> + * Don't emulate the PQexec()'s behavior of returning the
>> last
>> +
On Mon, Apr 19, 2010 at 11:04 AM, Robert Haas wrote:
>> First of all, I wonder why the latter two need to affect the decision of
>> whether additional information is written to WAL for HS. How about just
>> removing XLogIsNeeded() condition from XLogStandbyInfoActive()?
>
> Bad idea, I think. If
On Mon, Apr 19, 2010 at 08:32, Nikhil Sontakke
wrote:
> Hi,
>
> I saw this behavior with PG head:
>
> postgres=# create table x(x int default 8 not null);
> CREATE TABLE
> postgres=# create table x1 as select * from x;
> SELECT 0
> postgres=# \d x
> Table "public.x"
> Column | Type |
On Mon, 2010-04-19 at 11:37 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Mon, 2010-04-19 at 10:36 +0300, Heikki Linnakangas wrote:
> >> Simon Riggs wrote:
> >>> Log Message:
> >>> ---
> >>> Tune GetSnapshotData() during Hot Standby by avoiding loop
> >>> through normal backe
Simon Riggs wrote:
> On Mon, 2010-04-19 at 10:36 +0300, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>>> Log Message:
>>> ---
>>> Tune GetSnapshotData() during Hot Standby by avoiding loop
>>> through normal backends. Makes code clearer also, since we
>>> avoid various Assert()s. Perform
On Mon, 2010-04-19 at 10:36 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Log Message:
> > ---
> > Tune GetSnapshotData() during Hot Standby by avoiding loop
> > through normal backends. Makes code clearer also, since we
> > avoid various Assert()s. Performance of snapshots take
75 matches
Mail list logo
