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.
>
>
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
"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
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
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
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
>
> 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
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
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
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'
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
"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
"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:
> "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
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,
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
"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
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
"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
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
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
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
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
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?
"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
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
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
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
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
"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, 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
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
>
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
> >
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
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 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
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
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
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
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
Ü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
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
[ 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
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
>>> 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
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, 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
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
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 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
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
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 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
"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 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
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 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 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
"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
"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
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
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 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
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
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,
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
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
74 matches
Mail list logo
