schrieb Andrew Dunstan:
Hmm, I missed that you had done this. Here are two replacement perl
scripts I knocked up, but haven't yet tested. One of the things about
them is that they remove knowledge of particular .l and .y files. and
instead get the required invocation options from the relevant
On 05.07.2011 00:42, Florian Pflug wrote:
On Jul4, 2011, at 23:11 , Peter Geoghegan wrote:
On 4 July 2011 17:36, Florian Pflugf...@phlo.org wrote:
Btw, with the death-watch / life-sign / whatever infrastructure in place,
shouldn't PostmasterIsAlive() be using that instead of getppid() /
On Mon, Jul 4, 2011 at 23:30, Andrew Dunstan and...@dunslane.net wrote:
On 07/03/2011 05:14 PM, Brar Piening wrote:
schrieb Magnus Hagander:
I think you've stumbled on just about all the bits of the MSVC build
system we haven't perlized. Maybe we should complete that task, and turn
What about using backupStartPoint to check whether this recovery
started from the backup or not?
No, postgres can check whether this recovery started from the backup
or not, but can not check whether standby server or master (got backup
from).
Once recovery started, backupStartPoint is
On 5 July 2011 07:49, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Good point, and testing shows that that is exactly what happens at least on
Linux (see attached test program). So, as the code stands, the children will
go into a busy loop until the grandparent calls waitpid().
2011/7/5 Jun Ishiduka ishizuka@po.ntts.co.jp:
What about using backupStartPoint to check whether this recovery
started from the backup or not?
No, postgres can check whether this recovery started from the backup
or not, but can not check whether standby server or master (got backup
On Thu, Jun 30, 2011 at 1:34 AM, Josh Berkus j...@agliodbs.com wrote:
My preference would be to have:
# REPLICATION
# - Master Settings -
# these settings affect the master role in replication
# they will be ignored on the standby
... settings ...
# - Standby Settings -
# these
On Tue, Jul 5, 2011 at 4:34 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Jul 4, 2011 at 6:24 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Jun 14, 2011 at 6:08 AM, Fujii Masao masao.fu...@gmail.com wrote:
The standby must not accept replication connection from that standby
Hello Hitosh, list,
Attached is revised version.
I failed to attached the patch. I'm trying again.
I'm currently unable to test, since on holiday. I'm happy to continue
testing once returned but it may not be within the bounds of the current
commitfest, sorry.
5) Regression tests are
2011/7/5 Yeb Havinga yebhavi...@gmail.com:
Hello Hitosh, list,
Attached is revised version.
I failed to attached the patch. I'm trying again.
I'm currently unable to test, since on holiday. I'm happy to continue
testing once returned but it may not be within the bounds of the current
Hi all
I've got through a review of the VS 2010 support patches. Between work
being busy and some interesting issues getting my 64-bit build
environment set up it took longer than anticipated. Sorry.
It looks good so far. I haven't had any reply to my email to Brar, so
there are a few
On Mon, Jul 4, 2011 at 12:47 PM, Radosław Smogura
rsmog...@softperience.eu wrote:
I asked about crash reports becaus of at this time there was thread about
crashing in live system.
Yeah, I thought this was the result of that effort:
commit dcb09b595f88a3bca6097a6acc17bf2ec935d55f
Author:
On Tue, Jul 5, 2011 at 15:02, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 4, 2011 at 12:47 PM, Radosław Smogura
rsmog...@softperience.eu wrote:
I asked about crash reports becaus of at this time there was thread about
crashing in live system.
Yeah, I thought this was the result of
On Mon, Jul 4, 2011 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Steve Haslam araq...@googlemail.com writes:
... Apparently, the data read from \copy
is incrementing the script line number counter?
Yeah, so it is. That is correct behavior for COPY FROM STDIN,
but not so much for copying
On Tue, Jul 5, 2011 at 9:05 AM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Jul 5, 2011 at 15:02, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 4, 2011 at 12:47 PM, Radosław Smogura
rsmog...@softperience.eu wrote:
I asked about crash reports becaus of at this time there was
On Fri, Jul 1, 2011 at 6:06 PM, Josh Berkus j...@agliodbs.com wrote:
That sounds reasonable to me. I'll be on vacation then, but (1) I'm
not really involved in pushing the release out the door and (2) I
should have Internet access if push comes to shove.
We seem to still have some blockers
On Fri, Jul 1, 2011 at 3:15 AM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
In fdwhandler.sgml, chapter fdwhandler has only one subsection
(fdw-routines).
If there is only one subsection, no table of contents is generated in
the chapter.
That means that people who navigate to the chapter
2011/7/1 Shigeru Hanada shigeru.han...@gmail.com:
2011/6/30 Alvaro Herrera alvhe...@commandprompt.com:
Excerpts from 花田 茂's message of jue jun 30 06:00:23 -0400 2011:
I attached a patch which fixes file_fdw to check required option
(filename) in its validator function. I think that such
On Fri, Jul 1, 2011 at 2:09 AM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2011-06-30 at 12:28 +0200, Florian Pflug wrote:
Well, arrays are containers, and we need two values to construct a range,
What about empty ranges? What about infinite ranges?
It seems quite a bit more awkward to
On Tue, Jun 21, 2011 at 3:55 PM, Merlin Moncure mmonc...@gmail.com wrote:
For update, it's a bit more complex - we don't have a replace into
operator...
Actually, we do. 9.1 supports data modifying CTE around which it's
possible to rig a perfectly reasonable upsert...barring that, you
could
On Sun, Jun 19, 2011 at 7:17 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Heikki Linnakangas wrote:
* The oldserxid code is broken for non-default BLCKSZ.
o The warning will come either too early or too late
o There is no safeguard against actually wrapping around the
SLRU, just the
On Mon, Jun 13, 2011 at 2:33 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/6/13 Robert Haas robertmh...@gmail.com:
On Mon, Jun 13, 2011 at 1:40 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/6/13 Robert Haas robertmh...@gmail.com:
On Mon, Jun 13, 2011 at 12:24 PM, Kohei KaiGai
On Wed, Jun 15, 2011 at 7:43 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello Heikki,
probably I found a bug in patch:
CREATE FUNCTION fx(i integer) RETURNS integer
LANGUAGE plpgsql
AS $$begin raise notice '%', i; return i; end;$$;
CREATE FUNCTION fx1(integer) RETURNS text
On Fri, Jun 17, 2011 at 6:32 AM, Thom Brown t...@linux.com wrote:
On 15 June 2011 12:16, Dave Page dp...@pgadmin.org wrote:
On Wed, Jun 15, 2011 at 10:53 AM, Ahmed Shinwari
ahmed.shinw...@gmail.com wrote:
Hi All,
I faced a bug on Windows while connecting via SSPI authentication. I was
able
Robert Haas wrote:
I attached a patch which fixes file_fdw to check required option
(filename) in its validator function. I think that such requirement
should be checked again in PlanForeignScan(), as it had been so far.
Note that this patch requires fdw.patch has been applied.
Do we want
Excerpts from Robert Haas's message of mar jul 05 10:19:18 -0400 2011:
Hmm, OK. I guess what I'm not sure about is - how much should we
worry about the fact that this creates several more shared (and
therefore nailed?) system catalogs? Anyone have an opinion on that?
Several? That would
Robert Haas robertmh...@gmail.com wrote:
On Sun, Jun 19, 2011 at 7:17 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Heikki Linnakangas wrote:
* The oldserxid code is broken for non-default BLCKSZ.
o The warning will come either too early or too late
o There is no safeguard against
Hello.
System: PostgreSQL v9.0 Windows XP SP3
SQL: COPY tablename TO STDOUT WITH (FORMAT binary)
ERROR: syntax error at or near binary
LINE 1: ...OPY tablename TO STDOUT WITH (FORMAT binary)
^
** Error **
ERROR: syntax error at
On Tue, Jul 5, 2011 at 10:49 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar jul 05 10:19:18 -0400 2011:
Hmm, OK. I guess what I'm not sure about is - how much should we
worry about the fact that this creates several more shared (and
therefore
Excerpts from Tom Lane's message of mar jul 05 10:47:03 -0400 2011:
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
Move Trigger and TriggerDesc structs out of rel.h into a new reltrigger.h
This lets us stop including rel.h into execnodes.h, which is a widely
used header.
I'm confused why
Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011:
Hello.
System: PostgreSQL v9.0 Windows XP SP3
SQL: COPY tablename TO STDOUT WITH (FORMAT binary)
ERROR: syntax error at or near binary
LINE 1: ...OPY tablename TO STDOUT WITH (FORMAT binary)
On Tue, Jul 5, 2011 at 10:51 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Is this still an open item?
Yes, although I'm not clear on whether people feel it is one which
needs to be fixed for 9.1 or left for 9.2.
On a build with a BLCKSZ less than 8KB we would not get a warning
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of mar jul 05 10:47:03 -0400 2011:
I'm confused why this patch added pg_am.h to predtest.c?
...
(Of course, the reason this didn't fail previously is because rel.h
includes pg_am.h).
Oh, duh. Nevermind.
On Tue, 2011-07-05 at 10:06 -0400, Robert Haas wrote:
But if it's actually better, we should do it. If an intermediate type
seems to be problematic, or if people think it's strange to require
casting, then I think this is reasonable.
I don't understand how the bespoke syntax avoids the
Hello, Alvaro.
You wrote:
AH Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011:
Hello.
System: PostgreSQL v9.0 Windows XP SP3
SQL: COPY tablename TO STDOUT WITH (FORMAT binary)
ERROR: syntax error at or near binary
LINE 1: ...OPY tablename TO STDOUT WITH (FORMAT
On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011:
Hello.
System: PostgreSQL v9.0 Windows XP SP3
SQL: COPY tablename TO STDOUT WITH (FORMAT binary)
ERROR: syntax error at or near binary
On 07/05/2011 02:30 AM, Brar Piening wrote:
schrieb Andrew Dunstan:
Hmm, I missed that you had done this. Here are two replacement perl
scripts I knocked up, but haven't yet tested. One of the things about
them is that they remove knowledge of particular .l and .y files. and
instead get the
On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-07-05 at 10:06 -0400, Robert Haas wrote:
But if it's actually better, we should do it. If an intermediate type
seems to be problematic, or if people think it's strange to require
casting, then I think this is
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I assume it's not in unreserved_keyword because it would cause a
shift/reduce conflict elsewhere.
Yeah. In particular, it conflicts with the ancient copy syntax which
On Sat, Jun 11, 2011 at 12:38 PM, Greg Smith g...@2ndquadrant.com wrote:
Peter Eisentraut wrote:
For the directory name, I'd prefer either src/extensions (since there is
more than one), or if you want to go for short somehow, src/ext. (Hmm,
I guess the installation subdirectory is also called
On 07/05/2011 11:23 AM, Robert Haas wrote:
Yeah. In particular, it conflicts with the ancient copy syntax which
we still support for backwards compatibility with versions 7.3. We
can fix the immediate problem with something like the attached.
(a) Should we do that?
yes.
(b) Should we
On Tue, Jul 5, 2011 at 11:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I assume it's not in unreserved_keyword because it would cause a
shift/reduce conflict elsewhere.
Hello, Robert.
You wrote:
RH On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
RH alvhe...@commandprompt.com wrote:
Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011:
Hello.
System: PostgreSQL v9.0 Windows XP SP3
SQL: COPY tablename TO STDOUT WITH (FORMAT binary)
ERROR:
On Tue, Jul 5, 2011 at 11:37 AM, Pavel Golub pa...@microolap.com wrote:
RH Yeah. In particular, it conflicts with the ancient copy syntax which
RH we still support for backwards compatibility with versions 7.3. We
RH can fix the immediate problem with something like the attached.
This
On Jul5, 2011, at 17:11 , Jeff Davis wrote:
I'm OK with the intermediate type, but Florian seems skeptical of that
idea.
I'm starting to get used to it, though ;-) I do now believe that it can
be made safe against accidental miss-use, it seem that I was overly
anxious there.
What I still don't
Is there any way to get the regression tests to write a core dump file
somewhere that I can get at it? I tried ulimit -c unlimited but
can't find any core file lying around after I reproduce the crash.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas robertmh...@gmail.com writes:
... However, if we don't do what I've proposed here,
then I think 8.4 and 9.0 and probably 9.1 are going to need to stay as
they are, because...
RH (c) Should we consider removing compatibility with the ancient copy
RH syntax in 9.2, and de-reserving
2011/7/5 Robert Haas robertmh...@gmail.com:
On Wed, Jun 15, 2011 at 7:43 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello Heikki,
probably I found a bug in patch:
CREATE FUNCTION fx(i integer) RETURNS integer
LANGUAGE plpgsql
AS $$begin raise notice '%', i; return i; end;$$;
On Jul5, 2011, at 17:49 , Robert Haas wrote:
Is there any way to get the regression tests to write a core dump file
somewhere that I can get at it? I tried ulimit -c unlimited but
can't find any core file lying around after I reproduce the crash.
In case you're on OSX, the core dumps there
Robert Haas robertmh...@gmail.com wrote:
Well, as long as we can verify that OLDSERXID_MAX_PAGE has the
same value for BLCKSZ=8K before and after this patch, I don't see
any real downside to applying it. If, hypothetically, it's buggy,
it's only going to break things for non-default block
Excerpts from Robert Haas's message of mar jul 05 11:49:48 -0400 2011:
Is there any way to get the regression tests to write a core dump file
somewhere that I can get at it? I tried ulimit -c unlimited but
can't find any core file lying around after I reproduce the crash.
Are you using a temp
Hello, Robert.
You wrote:
RH On Tue, Jul 5, 2011 at 11:37 AM, Pavel Golub pa...@microolap.com wrote:
RH Yeah. In particular, it conflicts with the ancient copy syntax which
RH we still support for backwards compatibility with versions 7.3. We
RH can fix the immediate problem with something
On Tue, Jul 5, 2011 at 11:57 AM, Florian Pflug f...@phlo.org wrote:
On Jul5, 2011, at 17:49 , Robert Haas wrote:
Is there any way to get the regression tests to write a core dump file
somewhere that I can get at it? I tried ulimit -c unlimited but
can't find any core file lying around after I
On Tue, Jul 5, 2011 at 10:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-07-05 at 10:06 -0400, Robert Haas wrote:
But if it's actually better, we should do it. If an intermediate type
seems to be problematic,
On Tue, Jul 5, 2011 at 12:23 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Jul 5, 2011 at 10:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-07-05 at 10:06 -0400, Robert Haas wrote:
But if it's actually
In the 9.0 version of exclusion constraints, we added an extra check to
ensure that, when searching for a conflict, a tuple at least found
itself as a conflict. This extra check is not present in 9.1+.
It was designed to help diagnose certain types of problems, and is fine
for most use cases. A
Hi:
On Tue, Jul 5, 2011 at 11:26 AM, Jeff Davis pg...@j-davis.com wrote:
In the 9.0 version of exclusion constraints, we added an extra check to
ensure that, when searching for a conflict, a tuple at least found
itself as a conflict. This extra check is not present in 9.1+.
It was designed
On Thu, Jun 30, 2011 at 3:42 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Thu, Jun 30, 2011 at 11:44 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 30, 2011 at 11:18 AM, Merlin Moncure mmonc...@gmail.com wrote:
I think the basic problem is that the cache pages are so large. It's
On Tue, 2011-07-05 at 11:26 -0400, Robert Haas wrote:
How about the idea of creating a family of four constructor functions
for each new range type? The functions would be named after the range
type, with _cc, _co, _oc, and _oo appended. So, then, instead
of writing:
In reviewing the 2PC changes mentioned in a separate post, both Dan
and I realized that these were dependent on the assumption that
SSI's commitSeqNo is assigned in the order in which the transactions
became visible. There is a race condition such that this is not
necessarily true. It is a very
On Tue, Jul 5, 2011 at 10:49 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar jul 05 10:19:18 -0400 2011:
Hmm, OK. I guess what I'm not sure about is - how much should we
worry about the fact that this creates several more shared (and
On Tue, Jul 5, 2011 at 12:54 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-07-05 at 11:26 -0400, Robert Haas wrote:
How about the idea of creating a family of four constructor functions
for each new range type? The functions would be named after the range
type, with _cc, _co, _oc, and
Here is an updated version of the lazy vxid locks patch [1], which
applies over the latest reduce the overhead of frequent table
locks[2] patch.
[1] https://commitfest.postgresql.org/action/patch_view?id=585
[2] https://commitfest.postgresql.org/action/patch_view?id=572
--
Robert Haas
Robert Haas robertmh...@gmail.com wrote:
Any other reason we can't or shouldn't wrap on the 11th?
There are two new SSI issues which Dan and I spent a lot of time on
over the holiday weekend. I hope they can be pushed before the
11th.
I have added them to the Wiki page.
-Kevin
--
Sent
On Sun, Jul 03, 2011 at 11:33:38AM +0200, Kohei KaiGai wrote:
The attached patches are revised version.
The part-0 provides 'security_barrier' option for view definition, and
performs
as a common basis of part-1 and part-2 patches.
Syntax is extended as follows:
CREATE VIEW view_name
On Tue, Jul 5, 2011 at 1:13 PM, Robert Haas robertmh...@gmail.com wrote:
Here is an updated version of the lazy vxid locks patch [1], which
applies over the latest reduce the overhead of frequent table
locks[2] patch.
[1] https://commitfest.postgresql.org/action/patch_view?id=585
[2]
Excerpts from Kohei Kaigai's message of mar jul 05 11:46:06 -0400 2011:
On Tue, Jul 5, 2011 at 10:49 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar jul 05 10:19:18 -0400 2011:
Hmm, OK. I guess what I'm not sure about is - how much
On 05.07.2011 20:03, Kevin Grittner wrote:
In reviewing the 2PC changes mentioned in a separate post, both Dan
and I realized that these were dependent on the assumption that
SSI's commitSeqNo is assigned in the order in which the transactions
became visible. There is a race condition such that
On 05.07.2011 20:06, Kevin Grittner wrote:
[resending after gzip of test patch]
In reviewing the recent fix to 2PC coverage in SSI, I found some
cases which didn't seem to be covered. Dan bit the bullet and came
up with an additional isolation test to rigorously cover all the
permutations, to
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Hmm, I think it would be simpler to decide that instead of
SerializableXactHashLock, you must hold ProcArrayLock to access
LastSxactCommitSeqNo, and move the assignment of commitSeqNo to
ProcArrayTransaction(). It's probably
Original Message
Subject: Review of VS 2010 support patches
From: Craig Ringer cr...@postnewspapers.com.au
To: PG Hackers pgsql-hackers@postgresql.org, Brar Piening b...@gmx.de
Date: 05.07.2011 14:25
I haven't had any reply to my email to Brar, so there are a few
details
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, I think it would be simpler to decide that instead of
SerializableXactHashLock, you must hold ProcArrayLock to access
LastSxactCommitSeqNo, and move the assignment of commitSeqNo to
ProcArrayTransaction(). It's probably
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Attached is also a patch to fix those, so that all permutations
work.
I think that needs some explanation, why only those
SxactIsCommitted() tests need to be replaced with
SxactIsPrepared()? What about the first
Original Message
Subject: Re: [HACKERS] %'ENV warnings during builds
From: Andrew Dunstan and...@dunslane.net
To: Brar Piening b...@gmx.de
Date: 05.07.2011 17:25
Try attached instead.
I can confirm that this version of pgflex.pl works as expected in my
environment.
Robert Haas robertmh...@gmail.com writes:
2011/7/1 Shigeru Hanada shigeru.han...@gmail.com:
I used ereport for the former check, because maybe such error usually
happens and is visible to users. Â This criteria was taken from the
document Reporting Errors Within the Server.
Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, I think it would be simpler to decide that instead of
SerializableXactHashLock, you must hold ProcArrayLock to access
LastSxactCommitSeqNo, and move the assignment of commitSeqNo to
I wrote:
I think it might be better to keep the convention that an empty options
list is represented by null, and to say that if a validator wants to be
called on such a list, it had better declare itself non-strict. At
least we ought to think about that before redefining the catalog
On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
It'd be better to push some functionality into the procarray code.
That's easily done if we don't mind taking out a ProcArrayLock
during completion of a transaction which has no XID, if only long
enough to
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
That's easily done if we don't mind taking out a ProcArrayLock
during completion of a transaction which has no XID, if only long
enough to increment a uint64 in shared
Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
It'd be better to push some functionality into the procarray
code.
That's easily done if we don't mind taking out a ProcArrayLock
during completion of a transaction
Tom Lane t...@sss.pgh.pa.us wrote:
Isn't SSI *already* forcing a new acquisition of an LWLock during
commits of read-only transactions that aren't using SSI?
During COMMIT PREPARED there is one. We could avoid that by storing
the transaction isolation level in the persistent data for a
On Tue, Jul 05, 2011 at 01:15:13PM -0500, Kevin Grittner wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Hmm, I think it would be simpler to decide that instead of
SerializableXactHashLock, you must hold ProcArrayLock to access
LastSxactCommitSeqNo, and move the
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 1, 2011 at 3:15 AM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
In fdwhandler.sgml, chapter fdwhandler has only one subsection
(fdw-routines).
If there is only one subsection, no table of contents is generated in
the chapter.
That means
Hi,
I'm using the latest head and I created the file_fdw extension, then
attempted to change its schema (ALTER EXTENSION file_fdw SET SCHEMA
new_schema. No error was returned, but it remained in the same schema
(according to pg_extension).
I then dropped the extension and created it again
On Tue, Jul 05, 2011 at 09:14:30PM +0300, Heikki Linnakangas wrote:
I think that needs some explanation, why only those SxactIsCommitted()
tests need to be replaced with SxactIsPrepared()?
Here is the specific problem this patch addresses:
If there's a dangerous structure T0 --- T1 --- T2,
On 5 July 2011 21:27, Thom Brown t...@linux.com wrote:
Hi,
I'm using the latest head and I created the file_fdw extension, then
attempted to change its schema (ALTER EXTENSION file_fdw SET SCHEMA
new_schema. No error was returned, but it remained in the same schema
(according to
From the docs:
Note that unlike most catalogs with a namespace column, extnamespace
is not meant to imply that the extension belongs to that schema.
Extension names are never schema-qualified. Rather, extnamespace
indicates the schema that contains most or all of the extension's
objects. If
Sometime later this week, the community git server
(git.postgresql.org) will be migrated to a new server in the same
datacenter. This does *not* affect the master git server for the
project, just the anonymous mirror and those that run standalone
projects on it, such as pgAdmin.
When this move is
On 5 July 2011 22:31, Peter Geoghegan pe...@2ndquadrant.com wrote:
From the docs:
Note that unlike most catalogs with a namespace column, extnamespace
is not meant to imply that the extension belongs to that schema.
Extension names are never schema-qualified. Rather, extnamespace
indicates
Thom Brown t...@linux.com writes:
Correction, the objects which belong to the extension do switch
schema, but the properties of the extension itself indicate the
extension is in a different schema. So rather than not working at
all, it seems that it's just forgotten to update the pg_extension
On 5 July 2011 23:00, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com writes:
Correction, the objects which belong to the extension do switch
schema, but the properties of the extension itself indicate the
extension is in a different schema. So rather than not working at
all, it
Shigeru Hanada shigeru.han...@gmail.com writes:
Thanks for the comments. Please find attached a patch. Now file_fdw
validates filename in:
* file_fdw_validator(), to catch lack of required option at DDL
* fileGetOptions(), to avoid crash caused by corrupted catalog
Applied with small
I wrote:
Another possibility that just occurred to me is to call the validator
like this:
if (OidIsValid(fdwvalidator))
{
Datumvalarg = result;
/* pass a null options list as an empty array */
if (DatumGetPointer(valarg) == NULL)
valarg =
On 5/07/2011 9:05 PM, Magnus Hagander wrote:
On Tue, Jul 5, 2011 at 15:02, Robert Haasrobertmh...@gmail.com wrote:
On Mon, Jul 4, 2011 at 12:47 PM, Radosław Smogura
rsmog...@softperience.eu wrote:
I asked about crash reports becaus of at this time there was thread about
crashing in live
On Tue, Jul 5, 2011 at 8:08 PM, Simon Riggs si...@2ndquadrant.com wrote:
Now for the rest of the review...
Thanks!
I'd rather not include another chunk of code related to
wal_keep_segments. The existing code in CreateCheckPoint() should be
refactored so that we call the same code from both
Excerpts from Alvaro Herrera's message of lun jul 04 11:12:32 -0400 2011:
Excerpts from Heikki Linnakangas's message of lun jul 04 09:14:11 -0400 2011:
On 04.07.2011 16:07, Peter Geoghegan wrote:
That error message is bogus anyway:
if (!found)
ereport(ERROR,
I just came across this:
alvherre=# select * from pg_class where oid::regclass in ('foo');
ERROR: invalid input syntax for type oid: foo
LÍNEA 1: select * from pg_class where oid::regclass in ('foo');
^
alvherre=# select * from pg_class
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
I am not sure why it would be valid to list two literals in the values
but not one.
The discrepancy seems to be because transformAExprIn uses a different
type resolution method when there's more than one non-Var in the RHS.
Maybe we should apply
On Tue, 2011-07-05 at 13:06 -0400, Robert Haas wrote:
On Tue, Jul 5, 2011 at 12:54 PM, Jeff Davis pg...@j-davis.com wrote:
It would be something like: range_co(1,8)::int8range
(just so we're comparing apples to apples)
The intermediate type proposal doesn't require that we move the c
On Wed, Jul 6, 2011 at 2:13 AM, Fujii Masao masao.fu...@gmail.com wrote:
IMHO it's time to get rid of RECOVERYXLOG as an initial target for
de-archived files. That made sense once, but now we have streaming it
makes more sense for us to de-archive straight onto the correct file
name and let
100 matches
Mail list logo
