"Dann Corbit" writes:
>> From: Andrew Dunstan [mailto:and...@dunslane.net]
>> Why won't
>> PQstatus(conn) == CONNECTION_OK
>> be true and thus the code will succeed without requiring a password?
> It returns the value CONNECTION_STARTED
It certainly shouldn't. You're effectively asserting that
Pg_ctl.exe is exiting with a success code from line 1946 of PG_CTL.C
This is not appropriate behavior for a service unless shutdown has been
requested.
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Dann Corbit
>
Alvaro Herrera writes:
> Bruce asked me to look for places in the docs that mention that an
> ANALYZE is recommended, to mention the possibility that autovacuum takes
> care. This patch does that.
I think you found the right places to touch, but is "let the autovacuum
daemon do it" sufficient?
Dann Corbit wrote:
-Original Message-
From: Andrew Dunstan [mailto:and...@dunslane.net]
Sent: Tuesday, April 28, 2009 2:27 PM
To: Dann Corbit
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Building Postgresql under Windows question
Dann Corbit wrote:
In this function:
> -Original Message-
> From: Andrew Dunstan [mailto:and...@dunslane.net]
> Sent: Tuesday, April 28, 2009 2:27 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Building Postgresql under Windows question
>
>
>
> Dann Corbit wrote:
> > In this function:
> > s
Hi,
Bruce asked me to look for places in the docs that mention that an
ANALYZE is recommended, to mention the possibility that autovacuum takes
care. This patch does that.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
Dann Corbit wrote:
In this function:
static bool
test_postmaster_connection(bool do_checkpoint)
This code will never succeed:
snprintf(connstr, sizeof(connstr),
"dbname=postgres port=%s connect_timeout=5",
portstr);
for (i = 0; i < wait_seconds; i++)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
In this function:
static bool
test_postmaster_connection(bool do_checkpoint)
This code will never succeed:
snprintf(connstr, sizeof(connstr),
"dbname=postgres port=%s connect_timeout=5",
portstr);
for (i = 0; i < wait_seconds; i++)
{
> -Original Message-
> From: Andrew Dunstan [mailto:and...@dunslane.net]
> Sent: Tuesday, April 28, 2009 12:42 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Building Postgresql under Windows question
>
>
>
> Dann Corbit wrote:
> > Pg_ctl.exe is exiting
> -Original Message-
> From: Andrew Dunstan [mailto:and...@dunslane.net]
> Sent: Tuesday, April 28, 2009 12:42 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Building Postgresql under Windows question
>
>
>
> Dann Corbit wrote:
> > Pg_ctl.exe is exiting
Dann Corbit wrote:
Pg_ctl.exe is exiting with a success code from line 1946 of PG_CTL.C
This is not appropriate behavior for a service unless shutdown has been
requested.
pg_ctl calls *StartServiceCtrlDispatcher*(). It can only get to the line
you mention when called as a service after t
On Tue, Apr 28, 2009 at 11:57:19AM +0300, Heikki Linnakangas wrote:
> Greg Stark wrote:
>> I had previously considered adding an assertion in the backend to
>> check they're sorted properly. That would be less formatting
>> dependent and would be only a couple lines of C.
>>
>> I don't think we ca
We are still having trouble with the service controller pg_ctl.exe
vanishing after some period of time.
Hence I am doing debug builds from the source tree according to the
instructions found at:
http://developer.postgresql.org/pgdocs/postgres/install-win32-full.html
Specifically, I am using this
On Monday 27 April 2009 11:17:42 Tom Lane wrote:
> Alvaro Herrera writes:
> > Anton Egorov escribió:
> >> I need to recover deleted rows from table. After I delete those rows I
> >> stopped postgres immediately and create tar archive of database. I found
> >> solution
> >> http://archives.postgres
On Wednesday 22 April 2009 15:49:32 Tom Lane wrote:
> I wrote:
> > Heikki Linnakangas writes:
> >> Configuration affects what can be tested in installcheck, that's quite
> >> natural. I would be happy with simply adding an alternative expected
> >> output file for min_prepared_xacts=0 case. Like w
Tom Lane wrote:
> I was thinking in terms of throwing a warning in 8.4 and
> implementing new behavior in 8.5.
If we're on that time frame with it, I guess it's not too early to
suggest what we would implement in 8.5.
I would suggest that it is clear that what Pavel is requesting is
fully c
"Kevin Grittner" writes:
> Tom Lane wrote:
>> However, if we're going to do that then we should start
>> throwing warnings for use of the keywords, preferably before the
>> release in which they actually start doing something different.
> We might actually want to have a major release which re
Tom Lane wrote:
> One thing I just noticed is that the spec does not consider
> GLOBAL/LOCAL to be optional --- per spec you *must* write one or the
> other in front of TEMPORARY.
Agreed.
> So we could adopt the view that omitting this keyword
> implies our current non-spec behavior (which
"Kevin Grittner" writes:
> Tom Lane wrote:
>> it could be considered either a global or a local temp table per
>> spec (without any module support you can't really say which it is).
> That seems bogus -- without modules it is clearly not LOCAL.
You could just as easily say it's not GLOBAL.
>
Alvaro Herrera writes:
> Greg Stark wrote:
>> On Tue, Apr 28, 2009 at 4:41 PM, Tom Lane wrote:
>>> Another place where planner regression tests might've helped :-(
>>
>> I would suggest we start gathering up such tests in an sql file now
>> and worry about how to compare the output later.
> At
Greg Stark writes:
> On Tue, Apr 28, 2009 at 4:41 PM, Tom Lane wrote:
>> Another place where planner regression tests might've helped :-(
> I would suggest we start gathering up such tests in an sql file now
> and worry about how to compare the output later.
If anyone feels like doing the legwo
"Kevin Grittner" writes:
> ... Both forms of CREATE TEMP
> TABLE should persist the definition if you go by the standard, so you
> don't want to muddy the waters by complying on one and not the other?
Right. This goes back to our old principle of trying not to use
spec-defined syntax for not-pe
Tom Lane wrote:
> GLOBAL/LOCAL TEMP TABLE distinction is not related to cross-session
> persistence of the table definitions
On a re-read, I think I see your point -- it is the DECLARE LOCAL TEMP
TABLE versus CREATE { GLOBAL | LOCAL } TEMP TABLE which determines
whether the table definition i
"Kevin Grittner" writes:
> Tom Lane wrote:
>> we have already concluded that the spec's
>> GLOBAL/LOCAL TEMP TABLE distinction is not related
>> to cross-session persistence of the table definitions
> How do you reconcile that conclusion with the following,
> from ISO/IEC 9075-2:2003 (E), 4.14
Tom Lane wrote:
> it could be considered either a global or a local temp table per
> spec (without any module support you can't really say which it is).
That seems bogus -- without modules it is clearly not LOCAL. What
Pavel is requesting exactly matches the spec's definition of a global
tem
Greg Stark wrote:
> On Tue, Apr 28, 2009 at 4:41 PM, Tom Lane wrote:
> > Another place where planner regression tests might've helped :-(
>
> I would suggest we start gathering up such tests in an sql file now
> and worry about how to compare the output later.
At the very least, we could run the
On Tue, Apr 28, 2009 at 4:41 PM, Tom Lane wrote:
> Another place where planner regression tests might've helped :-(
I would suggest we start gathering up such tests in an sql file now
and worry about how to compare the output later. There are a lot of
people who can put together some perl hackery
Tom Lane wrote:
> we have already concluded that the spec's
> GLOBAL/LOCAL TEMP TABLE distinction is not related
> to cross-session persistence of the table definitions
How do you reconcile that conclusion with the following,
from ISO/IEC 9075-2:2003 (E), 4.14 Tables:
"The definition of a g
I noticed that queries involving constant-false join conditions are a
lot dumber than they were a couple of months ago. For instance
regression=# explain select * from tenk1 a where (unique1,0) in (select
unique2,1 from tenk1 b);
QUERY PLAN
On Tue, Apr 28, 2009 at 5:22 PM, Heikki Linnakangas
wrote:
> At a normal startup, the checkpoint record would be there as usual. And an
> archive recovery starts at the location indicated by the backup label.
>
> AFAICS calling RequestXLogSwitch() before CreateCheckPoint would be
> equivalent to c
Perhaps call them "session tables" instead of "temp tables"?
regards, tom lane
Or "transient table" ...
Maybe we can define when such table lose data
But in real - there is no need in this feature - databases are made to hold
data, not to lose.
If an application requi
Tom Lane wrote:
Heikki Linnakangas writes:
Andreas Pflug wrote:
So to get this down to a solution, it appears to be correct to execute
the RequestXLogSwitch right before CreateCheckPoint?
Hmm, then the checkpoint record isn't archived. That might be
acceptable, though, since all data would
Alvaro Herrera writes:
> Maybe we could make this work by fiddling with a different smgr -- on
> it, smgr_sync would be a noop, as would smgr_immedsync, and we could
> kludge something up to truncate relations during recovery.
Interesting thought but I think it falls down on pg_statistic.
One co
Tom Lane wrote:
> Not at all, because the database would be very unhappy at restart
> if it can't find the checkpoint record pg_control is pointing to.
>
So for several weeks now all postings just say how it will _not_ work.
Does this boil down to "There's no way to make sure that a graceful
fa
Pavel Stehule escribió:
> Hello
>
> I am thinking about global temp tables. One possible solution is
> creating global temporary table like normal table and in planner stage
> check using this table. When some global temporary table is detected,
> then real temporary table is created and used in e
On Tue, Apr 28, 2009 at 3:02 PM, Robert Haas wrote:
> You may be right, but on the other hand, I'm not sure there's any
> sense in NOT trying to model the impact of the additional heap
> fetches.
Yeah, the flip side of the argument is that we generally try to do the
best job we can modeling costs
Robert Haas writes:
> On Tue, Apr 28, 2009 at 3:51 AM, Greg Stark wrote:
>> If the logic you're suggesting would kick in at all it would be for a
>> narrow range of scan sizes,
> You may be right, but on the other hand, I'm not sure there's any
> sense in NOT trying to model the impact of the ad
Heikki Linnakangas writes:
> Andreas Pflug wrote:
>> So to get this down to a solution, it appears to be correct to execute
>> the RequestXLogSwitch right before CreateCheckPoint?
> Hmm, then the checkpoint record isn't archived. That might be
> acceptable, though, since all data would be safe
On Tue, Apr 28, 2009 at 3:51 AM, Greg Stark wrote:
> On Tue, Apr 28, 2009 at 7:45 AM, higepon wrote:
>> "How much extra cost should we add for lossy mode?".
>
> There is something odd in this concern. Normally people aren't raising
> and lowering their work_mem so the comparison would be between
Hi,
I was wondering whether there is a way to see which column in a view
depends on which column(s) in a table?
If I am not mistaking pg_depend only provides information about which
view depends on which tables columns only. (same as view_column_usage)
Regards,
Gevik.
--
Sent via pgsql-ha
Greg Stark wrote:
I had previously considered adding an assertion in the backend to check
they're sorted properly. That would be less formatting dependent and
would be only a couple lines of C.
I don't think we can do that with the gram.y check though.
Well, the ordering in gram.y is just pr
I had previously considered adding an assertion in the backend to
check they're sorted properly. That would be less formatting dependent
and would be only a couple lines of C.
I don't think we can do that with the gram.y check though.
--
Greg
On 28 Apr 2009, at 09:33, Heikki Linnakangas >
I wrote a little perl script to perform a basic sanity check to keywords
in gram.y and kwlist.h. It checks that all lists are in alphabetical
order, all keywords present in gram.y are listed in kwlist.h in the
right category, and conversely that all keywords listed in kwlist.h are
listed in gra
Hi.
> There is something odd in this concern. Normally people aren't raising
> and lowering their work_mem so the comparison would be between a plan
> where the planner expects to see n records and a plan where the
> planner expects to see n+1 records where n would fit and n+1 wouldn't.
I see.
>
If it works without any change to client SQL queries and compatible with JPA,
then I'm all ears. Otherwise, I really think Sam Mason's idea was spot on...
it works around the inadequacies of encrypted drives and provides the same
level of on-server security.
Tomas Zerolo wrote:
>
> -BEGIN P
On Tue, Apr 28, 2009 at 7:45 AM, higepon wrote:
> "How much extra cost should we add for lossy mode?".
There is something odd in this concern. Normally people aren't raising
and lowering their work_mem so the comparison would be between a plan
where the planner expects to see n records and a plan
47 matches
Mail list logo
