On Mon, Jul 4, 2011 at 23:30, Andrew Dunstan 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
>>> clean.b
> 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 rec
On 5 July 2011 07:49, Heikki Linnakangas
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(). That's not good.
>
> In that lig
2011/7/5 Jun Ishiduka :
>
>> 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).
Oh, right. We
On Thu, Jun 30, 2011 at 1:34 AM, Josh Berkus 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 settings affe
On Tue, Jul 5, 2011 at 4:34 AM, Fujii Masao wrote:
> On Mon, Jul 4, 2011 at 6:24 PM, Simon Riggs wrote:
>> On Tue, Jun 14, 2011 at 6:08 AM, Fujii Masao wrote:
>>
The standby must not accept replication connection from that standby
itself.
Otherwise, since any new WAL data would n
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 te
2011/7/5 Yeb Havinga :
> 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
> commi
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 detail
On Mon, Jul 4, 2011 at 12:47 PM, Radosław Smogura
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: Magnus Hagander
Date: Sun
On Tue, Jul 5, 2011 at 15:02, Robert Haas wrote:
> On Mon, Jul 4, 2011 at 12:47 PM, Radosław Smogura
> 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 dcb09b595f88a3b
On Mon, Jul 4, 2011 at 12:02 PM, Tom Lane wrote:
> "Steve Haslam" 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 from a separate file.
>
> The a
On Tue, Jul 5, 2011 at 9:05 AM, Magnus Hagander wrote:
> On Tue, Jul 5, 2011 at 15:02, Robert Haas wrote:
>> On Mon, Jul 4, 2011 at 12:47 PM, Radosław Smogura
>> wrote:
>>> I asked about crash reports becaus of at this time there was thread about
>>> crashing in live system.
>>
>> Yeah, I though
On Fri, Jul 1, 2011 at 6:06 PM, Josh Berkus 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 ...
I'm on
On Fri, Jul 1, 2011 at 3:15 AM, Albe Laurenz 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 from the main table
>
2011/7/1 Shigeru Hanada :
> 2011/6/30 Alvaro Herrera :
>> 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 requirement
>>> should be checked again in P
On Fri, Jul 1, 2011 at 2:09 AM, Jeff Davis 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 shoehorn ranges
On Tue, Jun 21, 2011 at 3:55 PM, Merlin Moncure 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 triviall
On Sun, Jun 19, 2011 at 7:17 PM, Kevin Grittner
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 warning
>> o I'm
On Mon, Jun 13, 2011 at 2:33 PM, Kohei KaiGai wrote:
> 2011/6/13 Robert Haas :
>> On Mon, Jun 13, 2011 at 1:40 PM, Kohei KaiGai wrote:
>>> 2011/6/13 Robert Haas :
On Mon, Jun 13, 2011 at 12:24 PM, Kohei KaiGai wrote:
> The attached patch is an update revision of security label support
>
On Wed, Jun 15, 2011 at 7:43 AM, Pavel Stehule 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
> LANGUAGE
On Fri, Jun 17, 2011 at 6:32 AM, Thom Brown wrote:
> On 15 June 2011 12:16, Dave Page wrote:
>> On Wed, Jun 15, 2011 at 10:53 AM, Ahmed Shinwari
>> wrote:
>>> Hi All,
>>>
>>> I faced a bug on Windows while connecting via SSPI authentication. I was
>>> able to find the bug and have attached the p
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.
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 woul
Robert Haas wrote:
> On Sun, Jun 19, 2011 at 7:17 PM, Kevin Grittner
> 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
>>> S
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 erro
On Tue, Jul 5, 2011 at 10:49 AM, Alvaro Herrera
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 nailed?) system cat
Excerpts from Tom Lane's message of mar jul 05 10:47:03 -0400 2011:
> Alvaro Herrera 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 this patch add
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
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
> before problems occurred
Alvaro Herrera 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
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
On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
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"
>> LINE 1: ...O
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 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 reasonab
Robert Haas writes:
> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
> 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
> we still support for backwards compatib
On Sat, Jun 11, 2011 at 12:38 PM, Greg Smith 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 "extension".
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 wrote:
> Robert Haas writes:
>> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
>> 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 c
Hello, Robert.
You wrote:
RH> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
RH> 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
On Tue, Jul 5, 2011 at 11:37 AM, Pavel Golub 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 patch is ugly.
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'
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 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 that keyword
2011/7/5 Robert Haas :
> On Wed, Jun 15, 2011 at 7:43 AM, Pavel Stehule
> 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
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 ther
Robert Haas 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 sizes which
> are,
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
Hello, Robert.
You wrote:
RH> On Tue, Jul 5, 2011 at 11:37 AM, Pavel Golub 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
On Tue, Jul 5, 2011 at 11:57 AM, Florian Pflug 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 repr
On Tue, Jul 5, 2011 at 10:26 AM, Robert Haas wrote:
> On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis 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 stra
On Tue, Jul 5, 2011 at 12:23 PM, Merlin Moncure wrote:
> On Tue, Jul 5, 2011 at 10:26 AM, Robert Haas wrote:
>> On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis 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 typ
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 va
Hi:
On Tue, Jul 5, 2011 at 11:26 AM, Jeff Davis 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 to help diagno
On Thu, Jun 30, 2011 at 3:42 PM, Merlin Moncure wrote:
> On Thu, Jun 30, 2011 at 11:44 AM, Robert Haas wrote:
>> On Thu, Jun 30, 2011 at 11:18 AM, Merlin Moncure wrote:
I think the basic problem is that the cache pages are so large. It's
hard to make them smaller because that increase
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:
>
> RANGE(1,
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 n
> On Tue, Jul 5, 2011 at 10:49 AM, Alvaro Herrera
> 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 naile
On Tue, Jul 5, 2011 at 12:54 PM, Jeff Davis 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 "_oo"
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
Enterp
Robert Haas 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 via pgsql-hackers mai
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 vie
On Tue, Jul 5, 2011 at 1:13 PM, Robert Haas 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] https://commitfest.
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
> > 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
> > >>
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 f
Heikki Linnakangas 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 easiest to move
> LastSxactCommit
Original Message
Subject: Review of VS 2010 support patches
From: Craig Ringer
To: PG Hackers , Brar Piening
Date: 05.07.2011 14:25
I haven't had any reply to my email to Brar, so there are a few
details (like whether x64 builds were tested and how x64 required
libraries we
Heikki Linnakangas 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 easiest to move
> LastSxactCommitS
Heikki Linnakangas 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 SxactIsCommitted() test in
> OnConflict_Che
Original Message
Subject: Re: [HACKERS] %'ENV warnings during builds
From: Andrew Dunstan
To: Brar Piening
Date: 05.07.2011 17:25
Try attached instead.
I can confirm that this version of pgflex.pl works as expected in my
environment.
Regards,
Brar
--
Sent via pgsql-
Robert Haas writes:
> 2011/7/1 Shigeru Hanada :
>> 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".
>> http://developer.postgresql.org/pgdocs/postgres/error
Tom Lane wrote:
> Heikki Linnakangas 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 easiest to m
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
> sem
On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner
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 increment a uint64 in share
Robert Haas writes:
> On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner
> 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 memory, and then stash the
>> value -- som
Robert Haas wrote:
> On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner
> 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
>> enou
Tom Lane 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
prepared statement, b
On Tue, Jul 05, 2011 at 01:15:13PM -0500, Kevin Grittner wrote:
> Heikki Linnakangas 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
Robert Haas writes:
> On Fri, Jul 1, 2011 at 3:15 AM, Albe Laurenz 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
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 specif
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 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 pg_extension).
>
> I
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 extr
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 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 the schema that
Thom Brown 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
> catalog
On 5 July 2011 23:00, Tom Lane wrote:
> Thom Brown 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 fo
Shigeru Hanada 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 adjustments.
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)
>
On 5/07/2011 9:05 PM, Magnus Hagander wrote:
On Tue, Jul 5, 2011 at 15:02, Robert Haas wrote:
On Mon, Jul 4, 2011 at 12:47 PM, Radosław Smogura
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 t
On Tue, Jul 5, 2011 at 8:08 PM, Simon Riggs 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 CreateCheckPoint()
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 wh
Alvaro Herrera 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 select_common_type even
On Tue, 2011-07-05 at 13:06 -0400, Robert Haas wrote:
> On Tue, Jul 5, 2011 at 12:54 PM, Jeff Davis 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" and
> >
On Wed, Jul 6, 2011 at 2:13 AM, Fujii Masao 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 the file be cle
98 matches
Mail list logo
