Hello, Tom.
You wrote:
TL> Bruce Momjian writes:
>> Tom Lane wrote:
>>> What's your idea of "affecting the fewest people"? There is no previous
>>> history to be backward-compatible with, because we never supported
>>> keepalive on Windows before.
>> Well, starting in 9.0, keepalives in libpq
On Sat, Jun 26, 2010 at 6:01 PM, Robert Haas wrote:
> On Fri, Jun 25, 2010 at 10:47 PM, Mark Wong wrote:
>> http://pages.cs.wisc.edu/~dewitt/includes/publications.html
>>
>> Some of these papers aren't the type of parallelism we're talking
>> about here, but the ones that I think are relevant tal
On Thu, Jul 1, 2010 at 11:39 AM, Bruce Momjian wrote:
>
> Did these changes ever get into the docs? I don't think so.
Thanks for reminding me. I attached the updated patch.
> > That last sentence is a bit unclear. How about:
> >
> > A restartpoint is triggered if at least one checkpoint record
On Jun 30, 2010, at 22:43 , Takahiro Itagaki wrote:
>
> "Kevin Grittner" wrote:
>
>> It seems potentially useful to LOG the version() string in the log
>> file during startup. It might also help to LOG any settings which
>> might result in the loss of committed transactions or in database
>>
"Kevin Grittner" wrote:
> It seems potentially useful to LOG the version() string in the log
> file during startup. It might also help to LOG any settings which
> might result in the loss of committed transactions or in database
> corruption during startup. (After a crash, the postgresql.conf
Did these changes ever get into the docs? I don't think so.
---
Fujii Masao wrote:
> On Thu, Jun 10, 2010 at 7:19 PM, Heikki Linnakangas
> wrote:
> >> --- 1902,1908
> >> ? ? ? ? ?for standby purposes, and the number o
On tis, 2010-06-22 at 09:37 +0900, KaiGai Kohei wrote:
> As you described at the source code comments as follows,
> it is not portable except for Linux due to the getsockopt() API.
>
> + // TODO: currently Linux-only code, needs to be made
> + // portable; see backend/l
Robert Haas writes:
> You need to make sure not only that you replay commit records in
> order, but also that, for example, you don't replay an
> XLOG_HEAP2_CLEAN record too early.
Hm, good point. That probably means that you *do* need fencepost
records, and furthermore that you might need an in
On 06/30/2010 05:52 PM, Robert Haas wrote:
> And at any rate, the per-database thing isn't really the design goal,
> anyway.
FWIW, I've run into more than one client where PITR and/or warm standby
on a per-database level would be a killer feature.
Joe
signature.asc
Description: OpenPGP digital
2010/6/30 Tom Lane :
> (thinks some more...) Maybe you don't even need the fencepoint record
> per se. I think all it's doing for you is making sure you don't process
> commit records on different streams out-of-order. There might be some
> other, more direct way to do that.
>
> (thinks yet more
Robert Haas writes:
> On Wed, Jun 30, 2010 at 6:57 PM, Tom Lane wrote:
>> The detailed definition is amazingly laborious and yet limited, though,
>> as it basically doesn't address the problem except for that specific
>> case and close relatives.
> Well, solving the problem in general is equival
Tom Lane wrote:
> Bruce Momjian writes:
> > The attached patch shows the hint only during recovery.
>
> BTW, it would be easier and more consistent with the rest of the code to
> look at InRecovery, instead of messing around with the function
> signature. And the usual way to emit a hint conditi
Robert Haas writes:
> 2010/6/30 Tom Lane :
>> Surely you'd have to roll back, not commit, in that situation. You have
>> no excuse for assuming that you've replayed all effects of the
>> transaction.
> Hmm, good point. But you could make it work either way, I think. If
> you flush WAL stream A
On 29/06/10 05:36, Josh Berkus wrote:
Having tinkered with it, I'll tell you that (2) is actually a very
hard problem, so any solution we implement should delay as long as
possible in implementing (2). In the case of Greenplum, what Mark did
originally IIRC was to check against the global me
mag...@hagander.net (Magnus Hagander) writes:
>> I concur with the thought that the most useful solution might be a way
>> to tell pg_restore to remove or disable check constraints.
>
> Uh, say what? Are you saying pg_restore should actually remove
> something from the database schema? And thus no
2010/6/30 Tom Lane :
> Robert Haas writes:
>> I think one per database and one extra one for the shared catalogs
>> would be enough. Most transactions would either touch either just the
>> database, or just the shared catalogs, so you'd write the commit
>> record in whichever stream was appropria
Robert Haas writes:
> I think one per database and one extra one for the shared catalogs
> would be enough. Most transactions would either touch either just the
> database, or just the shared catalogs, so you'd write the commit
> record in whichever stream was appropriate. If you had a transacti
On Wed, Jun 30, 2010 at 6:57 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>>
>> "The shall simply contain a > expression> that is retrospectively deterministic."
>
>> This is then defined in a rather complex manner that ends up disallowing
>> col > now() but allowing col < now().
>>
>
> Oh,
Peter Eisentraut writes:
>
> "The shall simply contain a expression> that is retrospectively deterministic."
> This is then defined in a rather complex manner that ends up disallowing
> col > now() but allowing col < now().
>
Oh, cute. Seems to have been added in SQL:2003. I guess somebody
2010/6/30 Alvaro Herrera :
> Excerpts from Devrim GÜNDÜZ's message of mié jun 30 14:54:06 -0400 2010:
>
>> One of the things that interested me was parallel recovery feature. They
>> said that they are keeping separate xlogs for each database, which
>> speeds ups recovery in case of a crash. It als
On ons, 2010-06-30 at 20:10 +0200, Gibheer wrote:
> On Fri, 25 Jun 2010 15:49:40 -0400, Peter Eisentraut
> wrote:
> >
> > For the record, here is a patch that would address these issues.
> >
> > At the moment, I'm waiting to get my hands on the new version 2.7 of
> > clang to see if some of thes
On ons, 2010-06-30 at 10:38 -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > Shouldn't we disallow anything that's not IMMUTABLE in a check constraint?
>
> I think you'd get too many howls of pain ... also, such a restriction is
> likely contrary to SQL spec.
"The shall simply contain a t
On Fri, Jun 11, 2010 at 10:19 AM, Magnus Hagander wrote:
>>> Especially if someone has a clue how to do it. The last time I fixed
>>> it by runnin repack, but that didn't work this time. I have no clue
>>> why it's asking for a file that doesn't exist.
>> Does the repo run 'update-server-info' i
On Fri, 25 Jun 2010 15:49:40 -0400, Peter Eisentraut
wrote:
>
> For the record, here is a patch that would address these issues.
>
> At the moment, I'm waiting to get my hands on the new version 2.7 of
> clang to see if some of these issues have gone away.
>
> Considering that clang already hel
Simon Riggs wrote:
> On Mon, 2010-06-28 at 10:09 -0700, Josh Berkus wrote:
> > > It will get done. It is not the very first thing on my to-do list.
> >
> > ??? What is then?
> >
> > If it's not the first thing on your priority list, with 9.0 getting
> > later by the day, maybe we should leave
Excerpts from David Fetter's message of lun jun 28 12:00:47 -0400 2010:
> While tracking this down, I didn't see a way to get SQLSTATE or the
> corresponding condition name via psql. Is this an oversight? A bug,
> perhaps?
IIRC
\pset VERBOSITY verbose
to get the SQLSTATE.
I don't think you can
Excerpts from Devrim GÜNDÜZ's message of mié jun 30 14:54:06 -0400 2010:
> One of the things that interested me was parallel recovery feature. They
> said that they are keeping separate xlogs for each database, which
> speeds ups recovery in case of a crash. It also would increase
> performance, s
On Mon, 2010-06-28 at 10:09 -0700, Josh Berkus wrote:
> > It will get done. It is not the very first thing on my to-do list.
>
> ??? What is then?
>
> If it's not the first thing on your priority list, with 9.0 getting
> later by the day, maybe we should leave it to Robert and Simon, who *do*
I talked to Sybase people about their latest technologies. Many features
that shipped with their latest ASE 15.5 product has been in PostgreSQL
since many years (like functional indexes, etc). :)
One of the things that interested me was parallel recovery feature. They
said that they are keeping s
On Fri, 2010-06-25 at 13:10 -0700, Josh Berkus wrote:
> The problem with centralized resource control
We should talk about the problem of lack of centralized resource control
as well, to balance.
Another well observed problem is that work_mem is user settable, so many
programs acting together wi
On Wed, Jun 30, 2010 at 20:13, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Jun 30, 2010 at 19:16, Tom Lane wrote:
>>> I concur with the thought that the most useful solution might be a way
>>> to tell pg_restore to remove or disable check constraints.
>
>> Uh, say what? Are you saying p
On 23/06/10 21:36, Robert Haas wrote:
On Mon, Jun 21, 2010 at 7:50 PM, Heikki Linnakangas
wrote:
On 15/06/10 10:31, Heikki Linnakangas wrote:
You could avoid changing the meaning of fn_expr by putting the check in
the parse analysis phase, into transformFuncCall(). That would feel
safer at l
Magnus Hagander writes:
> On Wed, Jun 30, 2010 at 19:16, Tom Lane wrote:
>> I concur with the thought that the most useful solution might be a way
>> to tell pg_restore to remove or disable check constraints.
> Uh, say what? Are you saying pg_restore should actually remove
> something from the d
On Wed, Jun 30, 2010 at 9:47 AM, Magnus Hagander wrote:
> We currently allow this:
>
> postgres=# create table t(a timestamptz not null primary key, check(a >
> now()));
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> "t_pkey" for table "t"
> CREATE TABLE
>
>
> Which seems very
On Wed, Jun 30, 2010 at 19:16, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 30, 2010 at 11:49 AM, Tom Lane wrote:
>>> I can't recall many
>>> field complaints about it. And the ones I do recall wouldn't have been
>>> prevented by a check as stupid as "are there immutable functions in
>>
Bruce Momjian writes:
> The attached patch shows the hint only during recovery.
BTW, it would be easier and more consistent with the rest of the code to
look at InRecovery, instead of messing around with the function
signature. And the usual way to emit a hint conditionally is
(InRecove
Bruce Momjian writes:
>> FATAL: directory "/path_to/ts" does not exist
>> HINT: create "/path_to/ts" directory for tablespace before
>> restarting the server
>> CONTEXT: xlog redo create ts: 16384 "/path_to/ts"
> This is an interesting patch idea. One problem with the patch is that
> create_t
On Wed, Jun 30, 2010 at 18:33, Richard Huxton wrote:
> On 30/06/10 17:11, Robert Haas wrote:
>>
>> On Wed, Jun 30, 2010 at 11:49 AM, Tom Lane wrote:
>>>
>>> Robert Haas writes:
My scintillating contribution to this discussion is the observation
that unrestorable dumps suck.
>>>
>>
On 30/06/10 18:11, Magnus Hagander wrote:
On Wed, Jun 30, 2010 at 18:33, Richard Huxton wrote:
IMHO The real solution would be something that could strip/rewrite the
constraint on restore rather than trying to prevent people being stupid
though. People *will* just tag their functions as immuta
Robert Haas writes:
> On Wed, Jun 30, 2010 at 11:49 AM, Tom Lane wrote:
>> I can't recall many
>> field complaints about it. And the ones I do recall wouldn't have been
>> prevented by a check as stupid as "are there immutable functions in
>> here".
> Hopefully there aren't too many ways to get
Fujii Masao wrote:
> On Mon, Jun 14, 2010 at 9:16 AM, Greg Smith wrote:
> > I wouldn't be adverse to improving the error messages emitted when this
> > happens by the server to make it more obvious what's gone wrong in 9.1.
> > ?That's the only genuine improvement I'd see value in here, to cut dow
On 30/06/10 17:11, Robert Haas wrote:
On Wed, Jun 30, 2010 at 11:49 AM, Tom Lane wrote:
Robert Haas writes:
My scintillating contribution to this discussion is the observation
that unrestorable dumps suck.
No doubt, but is this a real problem in practice?
Magnus tells me that that was wha
On Wed, Jun 30, 2010 at 11:49 AM, Tom Lane wrote:
> Robert Haas writes:
>> My scintillating contribution to this discussion is the observation
>> that unrestorable dumps suck.
>
> No doubt, but is this a real problem in practice?
Magnus tells me that that was what prompted his original email.
>
Robert Haas writes:
> My scintillating contribution to this discussion is the observation
> that unrestorable dumps suck.
No doubt, but is this a real problem in practice? I can't recall many
field complaints about it. And the ones I do recall wouldn't have been
prevented by a check as stupid a
"Kevin Grittner" writes:
> I also think we may want to suggest that for most environments,
> people may want to change these settings to something more
> aggressive, like a 30 to 120 second initial delay, with a 10 or 20
> second retry interval. The RFC defaults seem approximately right
> for a T
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> What's your idea of "affecting the fewest people"? There is no previous
> >> history to be backward-compatible with, because we never supported
> >> keepalive on Windows before.
>
> > Well, starting in 9.0, keepalives in libpq will
On Wed, Jun 30, 2010 at 11:02 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Jun 30, 2010 at 16:38, Tom Lane wrote:
>>> The example seems to me to be in the category of "so don't do that"
>>> rather than something that we need to save users from. Yes, it's
>
>> In that case, should we
Magnus Hagander wrote:
> Windows default for idle is 2 hours, for interval 1 second.
And it defaults to five retries. With these settings, you could
have a TCP connection break with as little as a five second network
outage, if it happened to come after two hours of silence on the
connection;
Bruce Momjian writes:
> Tom Lane wrote:
>> What's your idea of "affecting the fewest people"? There is no previous
>> history to be backward-compatible with, because we never supported
>> keepalive on Windows before.
> Well, starting in 9.0, keepalives in libpq will default to 'on':
Yes, which
Tom Lane wrote:
> Bruce Momjian writes:
> > I still like #1 because it affects the fewest people, and that option
> > uses the RFC defaults only for unset values when others are set.
>
> What's your idea of "affecting the fewest people"? There is no previous
> history to be backward-compatible w
Bruce Momjian writes:
> I still like #1 because it affects the fewest people, and that option
> uses the RFC defaults only for unset values when others are set.
What's your idea of "affecting the fewest people"? There is no previous
history to be backward-compatible with, because we never suppor
Magnus Hagander writes:
> On Wed, Jun 30, 2010 at 16:38, Tom Lane wrote:
>> The example seems to me to be in the category of "so don't do that"
>> rather than something that we need to save users from. Yes, it's
> In that case, should we at least throw a warning?
I don't see a reason to do tha
Magnus Hagander writes:
>> But you previously stated that this code was ignoring the registry
>> values. So doesn't "system defaults" boil down to whatever Windows'
>> wired-in defaults are?
> The order is Windows wired-in-defaults -> registry values -> what app chooses.
> And yes, we *are* ign
Tom Lane wrote:
> Magnus Hagander writes:
> > On Wed, Jun 30, 2010 at 16:27, Tom Lane wrote:
> >> It's hard to argue about this when most of us have no idea what these
> >> "system defaults" are, or whether they really are any different from the
> >> RFC values in the first place, or whether ordi
On Wed, Jun 30, 2010 at 16:48, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Jun 30, 2010 at 16:27, Tom Lane wrote:
>>> It's hard to argue about this when most of us have no idea what these
>>> "system defaults" are, or whether they really are any different from the
>>> RFC values in the
Magnus Hagander writes:
> On Wed, Jun 30, 2010 at 16:27, Tom Lane wrote:
>> It's hard to argue about this when most of us have no idea what these
>> "system defaults" are, or whether they really are any different from the
>> RFC values in the first place, or whether ordinary users know how to
>>
On Wed, Jun 30, 2010 at 16:38, Tom Lane wrote:
> Magnus Hagander writes:
>> Shouldn't we disallow anything that's not IMMUTABLE in a check constraint?
>
> I think you'd get too many howls of pain ... also, such a restriction is
> likely contrary to SQL spec.
Really? That sounds strange, but I ca
Magnus Hagander writes:
> Shouldn't we disallow anything that's not IMMUTABLE in a check constraint?
I think you'd get too many howls of pain ... also, such a restriction is
likely contrary to SQL spec.
The example seems to me to be in the category of "so don't do that"
rather than something tha
On Wed, Jun 30, 2010 at 16:27, Tom Lane wrote:
> Magnus Hagander writes:
>> Do you have an opinion on the two choices for handling keepalives_idle
>> and keepalives_interval? They basically are:
>
>> 1) When not configured, use system defaults. When only one of the two
>> parameters configured, u
Magnus Hagander writes:
> Do you have an opinion on the two choices for handling keepalives_idle
> and keepalives_interval? They basically are:
> 1) When not configured, use system defaults. When only one of the two
> parameters configured, use RFC default for the other one (overwrite
> system de
It seems potentially useful to LOG the version() string in the log
file during startup. It might also help to LOG any settings which
might result in the loss of committed transactions or in database
corruption during startup. (After a crash, the postgresql.conf file
might not show the values whic
We currently allow this:
postgres=# create table t(a timestamptz not null primary key, check(a > now()));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"t_pkey" for table "t"
CREATE TABLE
Which seems very wrong. For one thing, a dump of this database can not
be restored if now()
On Wed, Jun 30, 2010 at 5:36 AM, Fujii Masao wrote:
>> Before we get too busy frobnicating this gonkulator, I'd like to see a
>> little more discussion of what kind of performance people are
>> expecting from sync rep. Sounds to me like the best we can expect
>> here is, on every commit: (a) wait
On Tue, Jun 29, 2010 at 11:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian wrote:
>>> So this is not something we want fixed for 9.0, as indicated by Simon?
>>> I don't see the patch on the commit-fest page yet.
>
>> I tend to think we should fix it
On 15/06/10 15:19, Florian Pflug wrote:
On Jun 15, 2010, at 9:31 , Heikki Linnakangas wrote:
You could avoid changing the meaning of fn_expr by putting the check in the
parse analysis phase, into transformFuncCall(). That would feel safer at least
for back-branches.
For 9.0, wouldn't a clean
On Wed, Jun 30, 2010 at 11:26 AM, Robert Haas wrote:
> Maybe. As Heikki pointed out upthread, the standby can't even write
> the WAL to back to the OS until it's been fsync'd on the master
> without risking the problem under discussion.
If we change the startup process so that it doesn't go ahea
Hello, Magnus.
You wrote:
MH> 2010/6/30 Pavel Golub :
>> Hello, Bruce.
>>
>> You wrote:
>>
>> BM> Tom Lane wrote:
Robert Haas writes:
> On Mon, Jun 28, 2010 at 8:24 PM, Tom Lane wrote:
>> What I was trying to say is I think we could dispense with the
>> setsockopt() code pat
2010/6/30 Pavel Golub :
> Hello, Bruce.
>
> You wrote:
>
> BM> Tom Lane wrote:
>>> Robert Haas writes:
>>> > On Mon, Jun 28, 2010 at 8:24 PM, Tom Lane wrote:
>>> >> What I was trying to say is I think we could dispense with the
>>> >> setsockopt() code path, and just always use the WSAIoctl() pat
2010/6/30 Robert Haas :
> By the way, does the SQL standard say anything about materialized views?
AFAIK, nope. Probably for the same reason that indexes are not
mentioned by the standard: both are only performance enhancements, and
one could easily imagine future SQL database systems that manage
Hello, Bruce.
You wrote:
BM> Tom Lane wrote:
>> Robert Haas writes:
>> > On Mon, Jun 28, 2010 at 8:24 PM, Tom Lane wrote:
>> >> What I was trying to say is I think we could dispense with the
>> >> setsockopt() code path, and just always use the WSAIoctl() path anytime
>> >> keepalives are turne
70 matches
Mail list logo
