On Tue, Oct 23, 2007 at 07:24:21PM -0400, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Mind you, I'm in favor of one. A new SCM would make some other
development tasks easier. However, I'm reluctant to open the
can-of-worms which is the what SCM should we use discussion
again,
On Tue, 2007-10-23 at 16:19 -0700, Josh Berkus wrote:
Maybe. I'm looking for ways to increase the amount of development time
we have compared with time releasing. If we release twice as often, we
won't get twice the beta test contribution from everybody, so our code
will be less robust,
On Tue, 2007-10-23 at 19:42 -0400, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Plus, for the developers and other people who really need to be
bleeding-edge, this new plan would result in less-unstable snapshots every
2 months with defined feature sets which someone who wanted
VACUUM in 8.3dev always makes all pages dirty even if there are no jobs.
In 8.2.5, VACUUM produces no dirty pages in the same workload. Therefore,
VACUUM on 8.3 takes longer time than 8.2. I doubt some bugs in the
HOT-related codes here, but I cannot point out the actual position yet...
Do you
The main problem with using Git on a much larger scale is that there's
still limited ability to use it on Win32. Google is working on that:
http://code.google.com/p/msysgit/ but it's not quite there yet; there's
also a partial MinGW port.
IIRC the official word from the git people is
On 10/24/07, Tom Lane [EMAIL PROTECTED] wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Mind you, I'm in favor of one. A new SCM would make some other development
tasks easier. However, I'm reluctant to open the can-of-worms which is the
what SCM should we use discussion again, and complicate
On 10/24/07, Magnus Hagander [EMAIL PROTECTED] wrote:
The main problem with using Git on a much larger scale is that there's
still limited ability to use it on Win32. Google is working on that:
http://code.google.com/p/msysgit/ but it's not quite there yet; there's
also a partial MinGW
ITAGAKI Takahiro wrote:
VACUUM in 8.3dev always makes all pages dirty even if there are no jobs.
In 8.2.5, VACUUM produces no dirty pages in the same workload. Therefore,
VACUUM on 8.3 takes longer time than 8.2. I doubt some bugs in the
HOT-related codes here, but I cannot point out the
On 10/24/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Yeah, it's definitely a HOT-introdued thing. Vacuum calls
heap_page_prune on every page, and this in heap_page_prune is dirtying
the buffer:
else
{
/*
* If we didn't prune anything, we
Machine: Sun Microsystems Ultra 5 (SPARC IIi).
OS: FreeBSD 6.2/SPARC64
Compiler: gcc v.3.4.6
PostgreSQL 8.3 Beta builds on my system with no trouble.
Matthew Alton
I construct a postmaster.pid file and then set the pid to be one of existing
process id(not postgres, e.g vim), then I run postgres. This may happen if
postgres crashed last time and left a postmaster.pid file, and last postgres
id is reused by another process which is not postgres now.
What I
Hi,
If i do update and delete operations on a row pointed by cursor's current
then only first operation succeeds, second operation fails.
Ex.
DROP TABLE IF EXISTS tab;
create table tab (num int,num2 int );
insert into tab values(1,100);
insert into tab values(2,200);
insert into tab
On 10/24/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
I am looking at it. We must not call SetBufferCommitInfoNeedsSave unless
we make any state changes to the page.
The attached patch should fix this. We mark the buffer dirty only if there
is any state change in the page header.
Thanks,
On Wed, Oct 24, 2007 at 11:04:34AM +0300, Marko Kreen wrote:
On 10/24/07, Magnus Hagander [EMAIL PROTECTED] wrote:
The main problem with using Git on a much larger scale is that there's
still limited ability to use it on Win32. Google is working on that:
On 10/24/07, Magnus Hagander [EMAIL PROTECTED] wrote:
On Wed, Oct 24, 2007 at 11:04:34AM +0300, Marko Kreen wrote:
On 10/24/07, Magnus Hagander [EMAIL PROTECTED] wrote:
The main problem with using Git on a much larger scale is that there's
still limited ability to use it on Win32.
David Fetter wrote:
I'm not picking a DSCM. I'm saying we already have tools in place for
a DSCM *without* having a flag day. If Mercurial has a similar
migration/legacy support path, then by all means, let's try that out,
too. :)
There's at least on Mercurial repo, here:
Marko Kreen escribió:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted. Both leading DSCMs - GIT and Mercurial
do not support it.
Hmm, in Subversion you can specify a separate diff command
Josh Tolley escribió:
On 10/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
i am new in this, and i need help with catalog system of postgresql, i need
know
how are the relationship between the tables of the system catalog, and how
work
each table, if anybody know about this
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted. Both leading DSCMs - GIT and Mercurial
do not support it.
Really? I just started playing around with git, and the output from
git diff
Brendan Jurd escribió:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted. Both leading DSCMs - GIT and Mercurial
do not support it.
Really? I just started playing around with git, and
Alvaro Herrera write:
Marko Kreen escribió:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted. Both leading DSCMs - GIT and Mercurial
do not support it.
Hmm, in Subversion you can specify a
Richard Wang [EMAIL PROTECTED] writes:
I construct a postmaster.pid file and then set the pid to be one of existing
process id(not postgres, e.g vim), then I run postgres. This may happen if
postgres crashed last time and left a postmaster.pid file, and last postgres
id is reused by another
On 10/24/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Brendan Jurd escribió:
Really? I just started playing around with git, and the output from
git diff produced the same kind of diff file I would normally get from
`svn di`
... which is a unified diff.
or `cvs di -c`.
Huh, strange.
* Brendan Jurd [EMAIL PROTECTED] [071024 01:41]:
How up to date is the Git repos? Does it pull individual commits from
CVS, or does it resync the whole history periodically? If so, what's
the lag?
It's updated hourly, which is the same rate the public CVS is updated.
An important part of
On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
The one below is already available, so we don't have to do a flag
day with it.
http://repo.or.cz/w/PostgreSQL.git
As someone who hasn't used GIT: if I have a modified CVS tree from some time
back (1 year) can I use this to manage
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Brendan Jurd [EMAIL PROTECTED] [071024 01:41]:
How up to date is the Git repos? Does it pull individual commits from
CVS, or does it resync the whole history periodically? If so, what's
the lag?
It's updated hourly, which is the same rate the
On Wed, 2007-10-24 at 08:33 -0300, Alvaro Herrera wrote:
David Fetter wrote:
I'm not picking a DSCM. I'm saying we already have tools in place for
a DSCM *without* having a flag day. If Mercurial has a similar
migration/legacy support path, then by all means, let's try that out,
too.
Josh Berkus wrote:
Folks,
You are way ahead of us here. And my vote *still* goes to Mercurial, if
we're picking SCMs.
Will a new SCM actually make this easier, or are people just using it as an
excuse?
We use mercurial here at work, having switched to it recently, and while
I
Pavan Deolasee [EMAIL PROTECTED] writes:
The attached patch should fix this. We mark the buffer dirty only if there
is any state change in the page header.
Applied, with minor additional tweak to avoid duplicate calls to
SetBufferCommitInfoNeedsSave --- that seems (just) expensive enough
to be
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
The one below is already available, so we don't have to do a flag
day with it.
http://repo.or.cz/w/PostgreSQL.git
As someone who hasn't used GIT: if I have a modified CVS tree
On Tue, 2007-10-23 at 19:24 -0400, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Mind you, I'm in favor of one. A new SCM would make some other development
tasks easier. However, I'm reluctant to open the can-of-worms which is the
what SCM should we use discussion again, and
Marko Kreen [EMAIL PROTECTED] writes:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted.
Well, that's not a hard-and-fast rule, just a preference. At least for
me, unidiff is vastly harder to
On Wed, Oct 24, 2007 at 09:24:47AM -0400, Tom Lane wrote:
I don't recall that we've rejected any patches lately just because they
were unidiffs. But I'd be sad if a large fraction of incoming patches
started to be unidiffs.
We bounce them back to the author pretty m uch every time with
On Wed, 2007-10-24 at 14:32 +0200, Martijn van Oosterhout wrote:
On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
The one below is already available, so we don't have to do a flag
day with it.
http://repo.or.cz/w/PostgreSQL.git
As someone who hasn't used GIT: if I have a
Tom Lane [EMAIL PROTECTED] writes:
Marko Kreen [EMAIL PROTECTED] writes:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted.
Well, that's not a hard-and-fast rule, just a preference. At least
On 10/24/07, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted.
Well, that's not a hard-and-fast rule, just a
Dharmendra Goyal [EMAIL PROTECTED] writes:
If i do update and delete operations on a row pointed by cursor's current
then only first operation succeeds, second operation fails.
Hm, by fails you mean does nothing, right?
The reason for this is that WHERE CURRENT OF is implemented as if it
were
Marko Kreen wrote:
On 10/24/07, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted.
Well, that's not a
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 24, 2007 at 09:24:47AM -0400, Tom Lane wrote:
I don't recall that we've rejected any patches lately just because they
were unidiffs. But I'd be sad if a large fraction of incoming patches
started to be unidiffs.
We bounce them back to
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 24, 2007 at 09:24:47AM -0400, Tom Lane wrote:
I don't recall that we've rejected any patches lately just because they
were unidiffs. But I'd be sad if a large fraction of incoming patches
started to be unidiffs.
We
Tom Lane wrote:
Dharmendra Goyal [EMAIL PROTECTED] writes:
If i do update and delete operations on a row pointed by cursor's current
then only first operation succeeds, second operation fails.
Hm, by fails you mean does nothing, right?
The reason for this is that WHERE CURRENT OF is
Heikki Linnakangas [EMAIL PROTECTED] writes:
That would solve the problem with two updates of the same row, but not this:
UPDATE .. WHERE CURRENT OF...
FETCH RELATIVE 0
At the moment, that returns the next row, not the one that was updated.
Same problem with FETCH NEXT + FETCH PRIOR after
On Wed, 2007-10-24 at 15:50 +0100, Heikki Linnakangas wrote:
Tom Lane wrote:
Dharmendra Goyal [EMAIL PROTECTED] writes:
If i do update and delete operations on a row pointed by cursor's current
then only first operation succeeds, second operation fails.
Hm, by fails you mean does
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Oct 24, 2007 at 02:32:13PM +0200, Martijn van Oosterhout wrote:
On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
The one below is already available, so we don't have to do a flag
day with it.
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
That would solve the problem with two updates of the same row, but not this:
UPDATE .. WHERE CURRENT OF...
FETCH RELATIVE 0
At the moment, that returns the next row, not the one that was updated.
Same problem with FETCH NEXT +
Heikki Linnakangas [EMAIL PROTECTED] writes:
You can use filterdiff -v --format=context.
Cool, I'll have to get a copy of that.
Because it's easy to convert from one to another, I think the unified
vs. context diff issue is a non-issue.
Fair enough then; we should just change the policy.
Marko Kreen wrote:
On 10/24/07, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted.
Well, that's not a
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm fairly resistant to putting less-than-ready code in the tree, I must
say.
Me too, at least if less than ready means unstable. The committed
code has to always be solid enough to let everybody continue working on
their own
Simon Riggs [EMAIL PROTECTED] writes:
Tom Lane wrote:
While I've not tried this, I think we could fix it by having nodeTidscan
use SnapshotAny instead of the query snapshot when fetching a tuple for
CurrentOf (but not otherwise, so as to not change the behavior of WHERE
tid = something).
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Anyway, is there anyone who thinks the cycle the queue every 6 weeks or 2
months or suitable short period is a *bad* idea? It might be hard to
pull
off, but we won't know until we try.
It seems worth a try --- we can certainly
Tom Lane wrote:
[ chewing on this a bit... ] The curious thing about that is that
despite this being designed to be a short release cycle, we ended up
landing a bunch of major patches that weren't on the radar screen at
all at the start of the cycle. This suggests to me that there's
Tom Lane [EMAIL PROTECTED] writes:
Heikki Linnakangas [EMAIL PROTECTED] writes:
You can use filterdiff -v --format=context.
Cool, I'll have to get a copy of that.
Huh, I hadn't heard of that either. The Debian package patchutils says it was
downloaded from:
* Tom Lane [EMAIL PROTECTED] [071024 08:45]:
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Brendan Jurd [EMAIL PROTECTED] [071024 01:41]:
How up to date is the Git repos? Does it pull individual commits from
CVS, or does it resync the whole history periodically? If so, what's
the lag?
This has been saved for consideration for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Gokulakannan Somasundaram wrote:
Hi,
I would like to present the first patch. It currently
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm, what I'm seeing is that it returns the original (unmodified) row;
is that what you meant to say?
I do get the original unmodified tuple (2) if I leave out the FOR UPDATE.
Ah, I was testing without FOR UPDATE. I traced through
[EMAIL PROTECTED] wrote:
On Wed, Oct 24, 2007 at 02:32:13PM +0200, Martijn van Oosterhout wrote:
On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
The one below is already available, so we don't have to do a flag
day with it.
http://repo.or.cz/w/PostgreSQL.git
As
On Wed, Oct 24, 2007 at 02:18:42PM -0300, Alvaro Herrera wrote:
[EMAIL PROTECTED] wrote:
On Wed, Oct 24, 2007 at 02:32:13PM +0200, Martijn van Oosterhout wrote:
On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
The one below is already available, so we don't have to do a flag
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Tom Lane wrote:
While I've not tried this, I think we could fix it by having nodeTidscan
use SnapshotAny instead of the query snapshot when fetching a tuple for
CurrentOf (but not otherwise, so as to not change the behavior of WHERE
tid =
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm, what I'm seeing is that it returns the original (unmodified) row;
is that what you meant to say?
I do get the original unmodified tuple (2) if I leave out the FOR UPDATE.
Ah, I was testing without FOR
Heikki Linnakangas [EMAIL PROTECTED] writes:
Our FOR UPDATE cursors aren't exactly INSENSITIVE right now.
Yeah, after re-absorbing the code I realized my earlier comment was out
of date. I think the true state of affairs is (or should be) that a
cursor declared with FOR UPDATE is sensitive and
On Wed, 2007-10-24 at 18:29 +0100, Heikki Linnakangas wrote:
FETCH RELATIVE 0 re-fetches the current row according to the
manual.
The question is what's the current row, remembering that we've
always
defined our cursors as INSENSITIVE.
I tried to find an answer to that in the spec.
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Another question: if you do DELETE WHERE CURRENT OF, what would you
expect to happen to the cursor position?
According to the spec: before the next row.
AFAICS we cannot really support that without some fairly major revisions
Heikki Linnakangas [EMAIL PROTECTED] writes:
Yes, re-fetching row you just deleted is supposed to raise an error.
That doesn't seem very hard to implement. If an UPDATE/DELETE CURRENT OF
doesn't find the tuple to update/delete, raise an error.
Uh, no, the error would have to come from FETCH
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Yes, re-fetching row you just deleted is supposed to raise an error.
That doesn't seem very hard to implement. If an UPDATE/DELETE CURRENT OF
doesn't find the tuple to update/delete, raise an error.
Uh, no, the error would have to
On Wed, 2007-10-24 at 19:47 +0100, Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Yes, re-fetching row you just deleted is supposed to raise an error.
That doesn't seem very hard to implement. If an UPDATE/DELETE CURRENT OF
doesn't find the tuple to
Hi,
Is initdb supposed to pick up reasonable TS configurations in general?
If so, it's failing for me:
initdb: could not find suitable text search configuration for locale fr_CA.UTF-8
The default text search configuration will be set to simple.
It fails for es_CL as well.
... oh, I see
Also, please set pgAdmin to 'Debug' log level (under File-Options),
create a new log of you recreating the crash (using direct debugging,
not a global breakpoint) and then send me the logfile.
Done
Doesn't shed any light though unfortunately. Do you have a firewall on
that box? If so, can
I've tried on the win2000 virtual machine (running on virtualpc 2007)...
same error!
So, or I make something wrong (but I really don't understand what), or is
that particular pc,
or maybe uninstalling 8.2 left something dirty for 8.3. I need a clean vm
for testing
third option, but requires
I looked into the problem reported by Jakub Ouhrabka here:
http://archives.postgresql.org/pgsql-bugs/2007-10/msg00173.php
There are a couple of things happening in his example. One is a
garden-variety oversight in make_outerjoininfo: it omitted to test
whether an upper LEFT JOIN's join-clause
Alvaro Herrera [EMAIL PROTECTED] writes:
... oh, I see there's a table in initdb.c
Are we supposed to add entries to it, one for each country? I'm
wondering if we should try to match the part before the _ using just the
language, if the complete match fails. (i.e. match es_CL using just
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
... oh, I see there's a table in initdb.c
Are we supposed to add entries to it, one for each country? I'm
wondering if we should try to match the part before the _ using just the
language, if the complete match fails.
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually, looking at the examples so far, I'm thinking we should just
consider the string up to the first _, period.
Can anyone point to a real world example where country by country would
make sense?
For the current set of built-in
Andrew Dunstan wrote:
Tom Lane wrote:
Actually, looking at the examples so far, I'm thinking we should just
consider the string up to the first _, period.
I studied the standards a bit to see if they mandated that the locale
names must be in the form language_COUNTRY, and couldn't find
Brendan Jurd wrote:
On 10/24/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Brendan Jurd escribió:
Really? I just started playing around with git, and the output from git
diff produced the same kind of diff file I would normally get from `svn
di`
... which is a unified diff.
or `cvs di -c`.
Heikki Linnakangas [EMAIL PROTECTED] writes:
I don't see that in the spec.
It does say that if updatability clause is not specified, then if
either INSENSITIVE, SCROLL, or ORDER BY is specified, or if QE is not a
simply updatable table, then an updatability clause of READ ONLY is
implicit.
Alvaro Herrera [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
Can anyone point to a real world example where country by country would
make sense? If we need to distinguish flavors of some languages, I would
not be at all surprised if this was not by country anyway.
pt_BR versus pt_PT.
I am not adding anything from this thread to the patches_hold queue or
the TODO list, right? We are just going to wait to get reports from the
field?
---
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
... oh, I see there's a table in initdb.c
Are we supposed to add entries to it, one for each country? I'm
wondering if we should try to match the part before the _ using just the
language, if the complete match fails. (i.e.
Bruce Momjian [EMAIL PROTECTED] writes:
I am not adding anything from this thread to the patches_hold queue or
the TODO list, right? We are just going to wait to get reports from the
field?
Yeah, I think it's done until somebody complains.
regards, tom lane
79 matches
Mail list logo
