On 10/25/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> Huh, I hadn't heard of that either. The Debian package patchutils says it was
> downloaded from:
>
> http://cyberelk.net/tim/data/patchutils
>
> What's really cool is that patchutils also appears to have the utility I've
> been looking for for
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
---
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 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:
> >
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 p
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I don't see that in the spec.
> It does say that "if is not specified, then if
> either INSENSITIVE, SCROLL, or ORDER BY is specified, or if QE is not a
> simply updatable table, then an of READ ONLY is
> implicit". It also says "If an of FOR UPD
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`.
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 fin
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 b
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. (
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 j
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 refe
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 some
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 yo
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 there
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
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 wou
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 FETC
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
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 i
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 an
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 wi
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 behavio
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
[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/PostgreS
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
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
* 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
>
"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:
http://cyberelk.net/t
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
> som
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
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:
> 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
>
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,
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 polic
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 FE
-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.
> >
> > http://repo.or.cz/
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" y
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 af
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 CUR
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 unidiff
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 b
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
"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
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,
"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 prefe
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:
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 "con
"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 harde
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
"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 modi
"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
t
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
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
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 rat
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 m
* 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 pa
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`.
>
>
"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
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 se
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 wi
> 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
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 kn
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 comman
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:
http://www.
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 o
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:
> > > http://code.google.co
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.
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 values(3,300);
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
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
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
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 ac
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
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, an
> 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
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 hav
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
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 ro
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
80 matches
Mail list logo
