On Thu, 2007-10-11 at 17:46 -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Kevin Grittner wrote:
> >> If the goal is to provide fair warning of a high-than-usual-risk
> >> release, you've got it covered.
>
> > No, that was not the intent. The indent was to say we got a lot
Hi All,
Last two mails were sent by mistake without completion. I couldn't
curse my system any further
I apologize for that.
If we comeback to the topic of discussion
So i think we are clear now, that it is possible to have an index with
snapshot info. Let me try to en
On Fri, 2007-10-12 at 07:17 +0100, Simon Riggs wrote:
> On Fri, 2007-10-12 at 01:24 -0400, Alvaro Herrera wrote:
> > Michael Paesold escribió:
> > > Simon Riggs wrote:
> >
> > > Hmm, I am not sure we are there, yet. Autovacuum does take extra care to
> > > vacuum tables nearing xid wrap-around, r
Hi All,
Last mail was sent by mistake without completion. I apologize for
that. i am continuing on that.
So i think we are clear now, that it is possible to have an index with
snapshot info. Let me try to enumerate the uses of having the Index with
snapshot info, in comparison to the Dea
Hi All,
So i think we are clear now, that it is possible to have an index
with snapshot info. Let me try to enumerate the uses of having the Index
with snapshot info, in comparison to the Dead Space Map.
a) Dead Space, if it is successfull in its implementation of what it claims,
will ha
On Fri, 2007-10-12 at 01:24 -0400, Alvaro Herrera wrote:
> Michael Paesold escribió:
> > Simon Riggs wrote:
>
> > Hmm, I am not sure we are there, yet. Autovacuum does take extra care to
> > vacuum tables nearing xid wrap-around, right? It even does so when
> > autovacuum is disabled in the conf
Michael Paesold escribió:
> Simon Riggs wrote:
> Hmm, I am not sure we are there, yet. Autovacuum does take extra care to
> vacuum tables nearing xid wrap-around, right? It even does so when
> autovacuum is disabled in the configuration.
>
> So in case a vacuum is needed for that very reason, th
On Thu, 11 Oct 2007 21:31:20 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > With respect to you Kevin, your managers should wait. You don't
>
> Now I realize that you did say "test" above, but way too often I see
> this sort of argument as a justifi
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> With respect to you Kevin, your managers should wait. You don't
> install .0 releases of "any" software into production without "months"
> of testing. At which point, normally a .1 release has come out anyway.
How exactly do you expect the software t
"Trevor Talbot" <[EMAIL PROTECTED]> writes:
> I don't know if there have ever been retroactive changes to DST laws
> we could look at, but I could easily see a change like that affecting
> some things and not others.
Even a politician would hardly be silly enough to make a retroactive
DST law chan
On Oct 11, 2007, at 18:51 , Joshua D. Drake wrote:
With respect to you Kevin, your managers should wait. You don't
install .0 releases of "any" software into production without "months"
of testing. At which point, normally a .1 release has come out anyway.
At the same time, an open source pro
On Thu, 11 Oct 2007 15:26:43 -0500
"Kevin Grittner" <[EMAIL PROTECTED]> wrote:
> > This release represents a major leap forward by adding significant
> > new functionality and performance enhancements to
> > PostgreSQL. Many complex ideas that normally take
> > years to implement were added rapidl
On Thu, 11 Oct 2007 21:58:45 +0300
Hannu Krosing <[EMAIL PROTECTED]> wrote:
> > We have hooks in executor calling our own collecting functions, so
> > we don't need the trigger machinery to launch replication.
>
> But where do you store the collected info - in your own
> replication_log table,
On 10/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Trevor Talbot" <[EMAIL PROTECTED]> writes:
> > Neither is the birth certificate. The recorded, legal time of the
> > birth is the one that was written down. If it doesn't happen to match
> > an international notion of current time, that's unfort
"Trevor Talbot" <[EMAIL PROTECTED]> writes:
> Neither is the birth certificate. The recorded, legal time of the
> birth is the one that was written down. If it doesn't happen to match
> an international notion of current time, that's unfortunate, but it's
> not subject to arbitrary changes later.
>>> On Thu, Oct 11, 2007 at 3:34 PM, in message
<[EMAIL PROTECTED]>, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> The indent was to say we got a lot done in
> one year. You have a suggestion?
My suggestion would be to stay away from statements about the speed
of development and focus on the user
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Kevin Grittner wrote:
>> If the goal is to provide fair warning of a high-than-usual-risk
>> release, you've got it covered.
> No, that was not the intent. The indent was to say we got a lot done in
> one year. You have a suggestion?
Yeah: take the ent
On 10/11/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Trevor Talbot" <[EMAIL PROTECTED]> writes:
> > While I agree that UTC storage is definitely a needed option, I was
> > trying to point out in the scenario above that sometimes an event
> > recorded at a specific moment in time *is* local tim
On 10/11/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Kevin Grittner wrote:
> > >>> On Thu, Oct 11, 2007 at 3:04 PM, in message
> > <[EMAIL PROTECTED]>, Bruce Momjian <[EMAIL PROTECTED]>
> wrote:
> >
> > > This release represents a major leap forward by adding significant new
> > > functionali
I wrote:
> In fact, it seems there's a different risk here: if such a datum were
> toasted out-of-line, the reference in a cached plan might live longer
> than the underlying toast-table data. Maybe we need a forcible detoast
> in evaluate_function().
Sure enough, it seems we do. The attached sc
On Thu, 2007-10-11 at 16:04 -0400, Bruce Momjian wrote:
> I have added the following introductory paragraph to the release notes:
>
> This release represents a major leap forward by adding significant new
> functionality and performance enhancements to
> PostgreSQL. Many complex
On Thu, 11 Oct 2007 16:34:14 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Kevin Grittner wrote:
> > > PostgreSQL. Many complex ideas that normally take years
> > > to implement were added rapidly to this release by our development team.
> >
> > You do realize that this will make many ma
Kevin Grittner wrote:
> >>> On Thu, Oct 11, 2007 at 3:04 PM, in message
> <[EMAIL PROTECTED]>, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > This release represents a major leap forward by adding significant new
> > functionality and performance enhancements to
> > PostgreSQL. Many complex idea
>>> On Thu, Oct 11, 2007 at 3:04 PM, in message
<[EMAIL PROTECTED]>, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> This release represents a major leap forward by adding significant new
> functionality and performance enhancements to
> PostgreSQL. Many complex ideas that normally take years
> to im
On Thu, 2007-10-11 at 21:59 +0200, Michael Paesold wrote:
> So in case a vacuum is needed for that very reason, the vacuum should *not*
> be canceled, of course. So we don't really need the information, whether
> the AV worker is doing VACUUM or ANALYZE, but whether it is critical
> against xid
[ BCC to docs and hackers. Sorry this seems like the only logical way
to do this.]
I have added the following introductory paragraph to the release notes:
This release represents a major leap forward by adding significant new
functionality and performance enhancements to
Gregory Stark <[EMAIL PROTECTED]> writes:
> For the record I've been doing some more testing and found one place that
> could be a problem down the road. I'm not sure why it didn't show up
> previously. In selfuncs.c we use VARDATA/VARSIZE on data that is taken from
> parser Const nodes and from th
Simon Riggs wrote:
After some thought, you and Michael have persuaded me that there is
cause to do this for VACUUM as well, but just autovacuum, I think. That
also makes the patch simpler, since we don't need to delve inside the av
worker to see what it is doing.
Alvaro: That means we can just s
Ühel kenal päeval, N, 2007-10-11 kell 18:25, kirjutas Alexey Klyukin:
> Hello,
>
> Hannu Krosing wrote:
> >
> > Here come my questions :
> >
> > >From looking at http://www.commandprompt.com/images/MR_components.jpg it
> > seems that you don't do replication just from WAL logs, but also collect
"Trevor Talbot" <[EMAIL PROTECTED]> writes:
>> 2) Specific moment in time
>>(i.e. stored in UTC which is unaffected by time zone rules)
>>
>> 3) Specified time of day in specified time zone
>>(equivalent to #2 except when the time zone rules change)
>
>> Surely #2 is a must-have. There has
After much thought and discussion, here is my proposal of how to handle
autovacuum workers which block out user-initiated SQL statements.
Autovacuum workers running VACUUM, VACUUM ANALYZE and ANALYZE can give
problems by blocking out other users in various circumstances. There are
good cases for a
andy wrote:
Do I need to worry about sed with window's users?
yes.
Perl is probably more common in Windows, and should be able to do
everything sed can. It's also required for doing Windows/MSVC builds.
cheers
andrew
---(end of broadcast)--
=?ISO-8859-1?Q?Magne_M=E6hre?= <[EMAIL PROTECTED]> writes:
> Correct me if I'm wrong, but IIRC there is no universally accepted
> canonical list of time zone names (labels).
Yeah; we have an agreed-on list of names for the purposes of PG, namely
the names shown by pg_timezone_names, but that list
Tom Lane wrote:
andy <[EMAIL PROTECTED]> writes:
the operator = is not the 'normal =' is it? Its the 'tsearch2 =', right?
That one probably is, but how is your sed script going to distinguish it
from other user-defined '=' operators that might be in the dump?
Do I need to worry about sed wi
andy <[EMAIL PROTECTED]> writes:
> the operator = is not the 'normal =' is it? Its the 'tsearch2 =', right?
That one probably is, but how is your sed script going to distinguish it
from other user-defined '=' operators that might be in the dump?
> Do I need to worry about sed with window's users
Florian G. Pflug wrote:
I'm not really a tsearch user (just played with it a bit once). But I
wondered if you are aware that you can prevent certain objects from
being restored
quite easiy if you use pg_dump and pg_restore together with "custom
format" (-Fc). There is some option to pg_restore
On 10/11/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > "Trevor Talbot" <[EMAIL PROTECTED]> writes:
> >> On 10/11/07, Magne Mæhre <[EMAIL PROTECTED]> wrote:
> >>> Trevor Talbot wrote:
> That situation might sound a bit contrived, but I think the rea
Works perfectly. I did need to artificially create pg_clog segments.
Tom: Thanks for the quick response.
Bob.
On Oct 10, 2007, at 8:46 PM, Tom Lane wrote:
"Robert A. Klahn" <[EMAIL PROTECTED]> writes:
I am interested in increasing the PostgreSQL TransactionID, as part
of testing a (yet
On Thu, 11 Oct 2007 19:10:18 +0300
Alexey Klyukin <[EMAIL PROTECTED]> wrote:
> Marko Kreen wrote:
> > On 10/11/07, Alexey Klyukin <[EMAIL PROTECTED]> wrote:
> > > Hannu Krosing wrote:
> > > > For what use cases do you think your WAL-based approach is
> > > > better than Slony/Skytools trigger-base
Magnus Hagander wrote:
>
> > > The results have nothing to do with whether the process was followed.
> > > We do not ignore process violations just because the outcome was OK.
> >
> > Agreed. But reversing something that came out OK for no other reason
> > than that the process was violated? I kno
On 10/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> > On 10/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> Segfaults? That shouldn't happen. Please show a test case.
>
> > Test case: use old tsearch2.so to register all tsearch2 functions to
> >
Marko Kreen wrote:
> On 10/11/07, Alexey Klyukin <[EMAIL PROTECTED]> wrote:
> > Hannu Krosing wrote:
> > > For what use cases do you think your WAL-based approach is better than
> > > Slony/Skytools trigger-based one ?
> >
> > A pure trigger based approach can only replicate data for the commands
>
On 10/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> > During restoration to 8.3 I've catched segfaults -- during INSERTs
> > into tables with "tsearch2"."tsvector" columns.
>
> Segfaults? That shouldn't happen. Please show a test case.
Test case
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> On 10/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Segfaults? That shouldn't happen. Please show a test case.
> Test case: use old tsearch2.so to register all tsearch2 functions to
> "tsearch2" schema (old fashioned way). Then try:
How did yo
On 10/11/07, Alexey Klyukin <[EMAIL PROTECTED]> wrote:
> Hannu Krosing wrote:
> > For what use cases do you think your WAL-based approach is better than
> > Slony/Skytools trigger-based one ?
>
> A pure trigger based approach can only replicate data for the commands
> which fire triggers. AFAIK Slo
Alexey Klyukin wrote:
>
>
>> For what use cases do you think your WAL-based approach is better than
>> Slony/Skytools trigger-based one ?
>>
>
> A pure trigger based approach can only replicate data for the commands
> which fire triggers. AFAIK Slony is unable to replicate TRUNCATE
> comman
Hello,
Hannu Krosing wrote:
>
> Here come my questions :
>
> >From looking at http://www.commandprompt.com/images/MR_components.jpg it
> seems that you don't do replication just from WAL logs, but also collect
> some extra info inside postgreSQL server. Is this so ?
>
> If it is, then in what wa
I wrote:
> Well, we *have* the sequence's Oid in the regclass constant, the problem
> is the difficulty of digging through the plan tree to find it. I did
> consider having the planner extract it and save it aside somewhere, but
> there doesn't seem to be any very convenient place to do that, shor
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> During restoration to 8.3 I've catched segfaults -- during INSERTs
> into tables with "tsearch2"."tsvector" columns.
Segfaults? That shouldn't happen. Please show a test case.
regards, tom lane
Just in case there is initdb required in beta2, here is patch
that adds txid into core.
Otherwise please register this as submission to 8.4. I'd like to
avoid any process related discussions in the future...
It is syned with the latest patch I sent to -patches.
The docs are minimal, but I think
We wrote a little contrib module, which we'd like to share. It can be
used to generate random datasets as they have been used in
[Borzsonyi2001] and related work. The code is based directly on the
code of the authors, thanks to Donald Kossmann for sharing the
code. Donald Kossmann agrees on sharin
I working on binary compatible library with tsearch2, which should be
usable for all users who has default configuration of tsearch2. I
hope, I send patch before morning
Pavel
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
On 10/11/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
>
> Maybe we could document some regexp, awk script, or similar that strips the
> tsearch stuff from such a table of contents?
Just my .02c for those who will work on migration manual.
In my case, all tsearch2 stuff was kept (before 8.3) in
On Thu, 11 Oct 2007, andy wrote:
Oleg Bartunov wrote:
Andy,
seems you're a right person for writing migration guide.
Oleg
On Wed, 10 Oct 2007, andy wrote:
Where would be an easy place to find all the renamed functions?
My incomplete list:
http://www.sai.msu.su/~megera/wiki/Tsearch2_83_ch
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> Given that sequences are in fact relations is there some way to work around
>> the issue at least in this case by stuffing the sequence's relid someplace
>> which the plan invalldation code can check for it?
Well, we *have* t
andy wrote:
Florian G. Pflug wrote:
Maybe we could document some regexp, awk script, or similar that
strips the tsearch stuff from such a table of contents?
Ahh, I did not know that... I'll try that out and see if I can come up
with something. Thanks!
If you hack the old tsearch2.sql insta
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Trevor Talbot" <[EMAIL PROTECTED]> writes:
>> On 10/11/07, Magne M=E6hre <[EMAIL PROTECTED]> wrote:
>>> Trevor Talbot wrote:
That situation might sound a bit contrived, but I think the real point
is that even for some records of observed times, t
Florian G. Pflug wrote:
andy wrote:
Is there any chance there is an easier way to backup/restore? On one
hand, its not too bad, and it'll only be once (correct?). Now that
fts is in core future backup/restores will work, right? I think it's
analogous to telling someone they are updating fro
andy wrote:
Is there any chance there is an easier way to backup/restore? On one
hand, its not too bad, and it'll only be once (correct?). Now that fts
is in core future backup/restores will work, right? I think it's
analogous to telling someone they are updating from tsearch2 to
tsearch3,
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>
>> Hmm, it looks like the race condition Heikki mentioned is the culprit.
>> We need a way to stop future analyzes from starting. Back to the
>> drawing board ...
>
> A crazy idea I just had -- what if yo
"Trevor Talbot" <[EMAIL PROTECTED]> writes:
> On 10/11/07, Magne M=E6hre <[EMAIL PROTECTED]> wrote:
>> Trevor Talbot wrote:
>>> That situation might sound a bit contrived, but I think the real point
>>> is that even for some records of observed times, the local time is the
>>> authoritative one, no
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
>> (It might be interesting to make textin produce a packed result when
>> possible, just to see what breaks; but I would be afraid to try to do
>> that for production...)
>
> Reassuringly all checks pass with a
Oleg Bartunov wrote:
Andy,
seems you're a right person for writing migration guide.
Oleg
On Wed, 10 Oct 2007, andy wrote:
Where would be an easy place to find all the renamed functions?
My experience with fts is limited to one project, and I just used all
the default dictionaries, so I've
On 10/11/07, Magne Mæhre <[EMAIL PROTECTED]> wrote:
> Trevor Talbot wrote:
> > Thinking that it might have had out of date zone rules brings up an
> > interesting scenario though. Consider a closed (no networking or
> > global interest) filing system in a local organization's office, where
> > it'
Tom Lane wrote:
As an example, timestamptz '2007-01-01 00:00 -05' + interval '6 months'
must yield 2007-07-01 00:00 -05 according to the spec, AFAICS; but most
people living in the EST5EDT zone would prefer to get midnight -04.
There are probably some folk in South America who'd prefer midnight
Trevor Talbot wrote:
Thinking that it might have had out of date zone rules brings up an
interesting scenario though. Consider a closed (no networking or
global interest) filing system in a local organization's office, where
it's used to record the minutes of meetings and such via human input.
I
>
> btw, can you publicly discuss how CommandPrompts WAL-based
> replication works ?
It's my company, if course I am ;)... but not in this thread. If you
are interested feel free to email me directly or start a new thread.
Good :)
Here come my questions :
>From looking at http://www.commandp
On 10/10/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Trevor Talbot" <[EMAIL PROTECTED]> writes:
> > Actually, what I meant at least (not sure if others meant it), is
> > storing the value in the timezone it was entered, along with what zone
> > that was. That makes the value stable with respect to
Gregory Stark wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
There doesn't seem to be any very nice way to fix this. There is
not any existing support mechanism (comparable to query_tree_walker)
for scanning whole plan trees, which means that searching a cached plan
for regclass Consts is going
Gokulakannan Somasundaram wrote:
> As explained, if we are going to include the snapshot with indexes, Vacuum
> will be done on the index independent of the table, so Vacuum will not
> depend on immutability. We need to goto the index from the table, when we
> want to update the snapshot info. The
"Tom Lane" <[EMAIL PROTECTED]> writes:
> There doesn't seem to be any very nice way to fix this. There is
> not any existing support mechanism (comparable to query_tree_walker)
> for scanning whole plan trees, which means that searching a cached plan
> for regclass Consts is going to involve a ch
On 10/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Well, it's clearly useful in INSERT and UPDATE. For WHERE cases, you
> might or might not be able to use it, but I note that quote_nullable()
> would work much more like what happens if you use a parameter symbol
> and then bind NULL as the actual
Tom Lane wrote:
> ... We might want to do that someday --- in particular,
> if we ever try to extend the plan inval mechanism to react to
> redefinitions of non-table objects, we'd likely need some such thing
> anyway. I'm disinclined to try to do it for 8.3 though. The use-case
> for temp sequen
On 10/10/07, Marko Kreen <[EMAIL PROTECTED]> wrote:
> On 10/10/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > * Why is txid_current_snapshot() excluding subtransaction XIDs? That
> > might be all right for the current uses in Slony/Skytools, but it seems
> > darn close to a bug for any other use.
>
>
74 matches
Mail list logo
