On 10/11/07, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
Could you describe bit more? The is_visible_txid() works
on data returned by txid_current_snapshot()? How can there
be any subtrans id's if txid_current_snapshot() wont return
them?
Ah, I see:
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.
In queue
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 sequences
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 chunk of
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 to
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 the zone it
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
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.
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's used to
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 hack like that
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, not UTC.
...and
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 you roll this into
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
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, the local time is the
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
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* the
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:
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
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
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
---(end
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 way does
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
command
It could
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, short
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 Slony is
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 you get 8.3 to
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: use old
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
which fire
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 know you don't,
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
tsearch2 schema
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-based one ?
A
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 real point
is that even for
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
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
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
=?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
some extra
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 to be a data
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
[ 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 the
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
productnamePostgreSQL/. Many complex ideas that normally take years
to
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
productnamePostgreSQL/. Many complex ideas
On Thu, 11 Oct 2007 16:34:14 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Kevin Grittner wrote:
productnamePostgreSQL/. 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
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
productnamePostgreSQL/. Many
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
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
functionality and performance
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 time. Birth
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 entire
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. Even
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 unfortunate, but
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,
No, we
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
productnamePostgreSQL/. Many complex ideas that normally take
years to implement were added
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
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 change.
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 to get from
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 justification for
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, the
69 matches
Mail list logo
