On 21.02.2011 21:33, Joachim Wieland wrote:
Hi,
On Mon, Feb 21, 2011 at 4:56 PM, Alvaro Herrera
wrote:
What's the reason for this restriction?
if (databaseId != MyDatabaseId)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
On 19.02.2011 02:41, Joachim Wieland wrote:
On Fri, Feb 18, 2011 at 8:57 PM, Alvaro Herrera
wrote:
1. why are you using the expansible char array stuff instead of using
the StringInfo facility?
2. is md5 the most appropriate digest for this? If you need a
cryptographically secure hash, do we
2011/2/22 Tom Lane :
> Andrew Dunstan writes:
>> On 02/21/2011 08:59 PM, Itagaki Takahiro wrote:
>>> I think we need to overhaul validators in 9.2 listening to FDW developers'
>>> opinions anyway.
>
>> Ok, I guess. It just seems to me like it will be harder to extend the
>> API later than now, so
On Mon, Feb 21, 2011 at 9:35 PM, Tatsuo Ishii wrote:
> + synchronous_standby_names configuration
> parameter
> +
> +
> +
> + Specifies a list of standby names that can become the sole
> + synchronous standby. Other standby servers connect that are also on
>
On Mon, Feb 21, 2011 at 6:06 PM, Fujii Masao wrote:
> I've read about a tenth of the patch, so I'll submit another comments
> about the rest later.
Here are another comments:
SyncRepReleaseWaiters should be called when walsender exits. Otherwise,
if the standby crashes while a transaction is wai
On Tue, Feb 22, 2011 at 7:55 AM, Daniel Farina wrote:
> I'm taking a look at replication timeout with non-blocking which would
> be "nice" but not required for this patch, in my understanding.
Why do you think so? You think sync_replication_timeout_client is sufficient
for sync rep?
Regards,
--
Andrew Dunstan writes:
> On 02/21/2011 08:59 PM, Itagaki Takahiro wrote:
>> I think we need to overhaul validators in 9.2 listening to FDW developers'
>> opinions anyway.
> Ok, I guess. It just seems to me like it will be harder to extend the
> API later than now, so if we can reasonably foresee
Andrew Dunstan writes:
> On 02/21/2011 06:56 PM, Tom Lane wrote:
>> Huh? The options ought to be orthogonal to the table column info.
>> If they're not, maybe you need to rethink your option definitions.
> Well, let's take a couple of cases.
> 1. My old favorite, file as a text array.
> 2. A hy
On 02/21/2011 08:59 PM, Itagaki Takahiro wrote:
I think we need to overhaul validators in 9.2 listening to FDW developers'
opinions anyway. The text array is an example, but there should be many
other requirements. Personally, I'd like to have a method to list available
options from SQL. We sho
psql \d(+) doesn't show any information about UNLOGGED and TEMP attributes
for the table. So, we cannot know the table is unlogged or not unless
we directly select from pg_class.relpersistence. Is this a TODO item?
The same issue is in TEMP tables, but we can determine them by their
schema; they
On Mon, Feb 21, 2011 at 11:42:36PM +, YAMAMOTO Takashi wrote:
> i tested ede45e90dd1992bfd3e1e61ce87bad494b81f54d + ssi-multi-update-1.patch
> with my application and got the following assertion failure.
>
> #4 0x0827977e in CheckTargetForConflictsIn (targettag=0xbfbfce78)
> at predicate.c
On 02/21/2011 09:33 PM, Bruce Momjian wrote:
Tom Lane wrote:
Andrew Dunstan writes:
I propose that we add the following test for this case:
AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file
is required for Python])])
You'd need to pay attention to python_includespec, but ot
Tom Lane wrote:
> Andrew Dunstan writes:
> > I propose that we add the following test for this case:
>
> > AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file
> > is required for Python])])
>
> You'd need to pay attention to python_includespec, but otherwise seems
> reasonable.
Di
Itagaki Takahiro wrote:
> On Mon, Sep 27, 2010 at 2:19 PM, Josh Berkus wrote:
> > While working on some database maintenance, I was just tripped up by the
> > fact that there is no good way to query reloptions for tables. ?By "no good
> > way" I mean "no way which does not involve UNNEST and regex
On Tue, Feb 22, 2011 at 10:12, Andrew Dunstan wrote:
>>> The API for FDW validators doesn't appear to have any way that the
>>> validator function can check that the defined foreign table shape
>>> matches the FDW options sanely.
>>
>> Huh? The options ought to be orthogonal to the table column i
On 02/21/2011 06:56 PM, Tom Lane wrote:
Andrew Dunstan writes:
The API for FDW validators doesn't appear to have any way that the
validator function can check that the defined foreign table shape
matches the FDW options sanely.
Huh? The options ought to be orthogonal to the table column inf
Alvaro Herrera writes:
> That's true too. So let's discuss the syntax. Maybe
> START TRANSACTION SNAPSHOT '\xdeadbeef';
> This kind of extension seems ugly though; maybe we should consider
> START TRANSACTION (snapshot='\xdeadbeef');
> (like VACUUM, EXPLAIN and COPY) or some such?
Excerpts from Tom Lane's message of lun feb 21 21:00:19 -0300 2011:
> Alvaro Herrera writes:
> > Actually this seems rather difficult to do, because in order to invoke
> > the function that imports the snapshot, you have to call SELECT, which
> > acquires a snapshot beforehand. So when we actuall
Alvaro Herrera writes:
> Actually this seems rather difficult to do, because in order to invoke
> the function that imports the snapshot, you have to call SELECT, which
> acquires a snapshot beforehand. So when we actually import the
> passed-in snapshot, there's already a snapshot set. This is
Andrew Dunstan writes:
> The API for FDW validators doesn't appear to have any way that the
> validator function can check that the defined foreign table shape
> matches the FDW options sanely.
Huh? The options ought to be orthogonal to the table column info.
If they're not, maybe you need to
Excerpts from Kevin Grittner's message of lun feb 21 18:39:26 -0300 2011:
> Alvaro Herrera wrote:
>
> > I think we need a safety net so that the new serializable isolation
> > code doesn't get upset if we change the base snapshot from under
> > it, but I haven't looked at that yet.
>
> Replaci
The API for FDW validators doesn't appear to have any way that the
validator function can check that the defined foreign table shape
matches the FDW options sanely. Maybe it's a chicken and egg problem,
but there seems to be something missing, unless I'm mistaken. We'll have
the info when we co
On Mon, Feb 21, 2011 at 4:35 AM, Tatsuo Ishii wrote:
>> Well, good news all round.
Hello on this thread,
I'm taking a look at replication timeout with non-blocking which would
be "nice" but not required for this patch, in my understanding. But
before that, we're going to put this patch through s
Alvaro Herrera wrote:
> I think we need a safety net so that the new serializable isolation
> code doesn't get upset if we change the base snapshot from under
> it, but I haven't looked at that yet.
Replacing the snapshot for a serializable transaction after it has
acquired its initial snapsho
Joachim Wieland writes:
> On Mon, Feb 21, 2011 at 4:56 PM, Alvaro Herrera
> wrote:
>> Why are we using bytea as the output format instead of text?
> It is bytea because it should be thought of "just some data". It
> should be regarded more as a token than as text and should not be
> inspected/in
On Feb 21, 2011, at 10:11 AM, David E. Wheeler wrote:
> Oops, sorry, make that
>
> https://github.com/pgexperts/explain-table
And now I've renamed it (sorry) and released it on PGXN. New links:
https://github.com/pgexperts/explanation
http://master.pgxn.org/dist/explanation/
Best,
David
Hi,
On Mon, Feb 21, 2011 at 4:56 PM, Alvaro Herrera
wrote:
> What's the reason for this restriction?
> if (databaseId != MyDatabaseId)
> ereport(ERROR,
> (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> errmsg("cannot import snapsho
On Feb 21, 2011, at 10:07 AM, David E. Wheeler wrote:
> See also
>
> https://github.com/theory/explain-table
Oops, sorry, make that
https://github.com/pgexperts/explain-table
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On Feb 21, 2011, at 9:12 AM, Andrew Dunstan wrote:
> my $parser= XML::DOM::Parser->new();
> my $xp = $parser->parsefile($xmlfile);
> my ($provider) = $xp->findvalue("//SERVICE_PROVIDER_CODE");
> my ($invoice_num) = $xp->findvalue("//invoice_num");
>
> Not that hard, is it? No regex matchi
Excerpts from Joachim Wieland's message of dom ene 30 14:36:12 -0300 2011:
> On Thu, Jan 20, 2011 at 1:37 AM, Noah Misch wrote:
> >> > Is it valid to scribble directly on snapshots like this?
> >> I figured that previously executed code still has references pointing
> >> to the snapshots and so
On 02/21/2011 12:28 PM, Tom Lane wrote:
Andrew Dunstan writes:
Regarding your other suggestion, the whole point I have been making is
that if external modules can invent arbitrary nodes then we can't
publish an XSD (or RelaxNG or DTD) spec that is worth anything at all.
Well, sure we can. B
Andrew Dunstan writes:
> Regarding your other suggestion, the whole point I have been making is
> that if external modules can invent arbitrary nodes then we can't
> publish an XSD (or RelaxNG or DTD) spec that is worth anything at all.
Well, sure we can. But if you're using any external FDW,
On 02/21/2011 11:45 AM, Mark Mielke wrote:
On 02/21/2011 11:38 AM, Andrew Dunstan wrote:
On 02/21/2011 11:23 AM, Tom Lane wrote:
Andrew Dunstan writes:
If we allow the invention of new explain states we'll never be able to
publish an authoritative schema definition of the data. That's not
Alvaro Herrera writes:
> Excerpts from Andrew Dunstan's message of lun feb 21 13:11:25 -0300 2011:
>> If we allow the invention of new explain states we'll never be able to
>> publish an authoritative schema definition of the data. That's not
>> necessarily an argument against doing it, just som
On 02/21/2011 11:38 AM, Andrew Dunstan wrote:
On 02/21/2011 11:23 AM, Tom Lane wrote:
Andrew Dunstan writes:
If we allow the invention of new explain states we'll never be able to
publish an authoritative schema definition of the data. That's not
necessarily an argument against doing it, just
Excerpts from Andrew Dunstan's message of lun feb 21 13:11:25 -0300 2011:
> If we allow the invention of new explain states we'll never be able to
> publish an authoritative schema definition of the data. That's not
> necessarily an argument against doing it, just something to be aware of.
> Ma
On 02/21/2011 11:23 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 02/19/2011 11:07 PM, Tom Lane wrote:
However, it occurs to me that as long as we're passing the function the
ExplainState, it has what it needs to add arbitrary EXPLAIN result
fields.
If we allow the invention of new explain
Thom Brown writes:
> Is this right?
> postgres=# \d+ agg_text
> Foreign table "public.agg_text"
> Column | Type | Modifiers | Storage | Description
> +--+---+--+-
> a | smallint | | plain|
> b | text |
Andrew Dunstan writes:
> On 02/19/2011 11:07 PM, Tom Lane wrote:
>> However, it occurs to me that as long as we're passing the function the
>> ExplainState, it has what it needs to add arbitrary EXPLAIN result
>> fields.
> If we allow the invention of new explain states we'll never be able to
>
Is this right?
postgres=# \d+ agg_text
Foreign table "public.agg_text"
Column | Type | Modifiers | Storage | Description
+--+---+--+-
a | smallint | | plain|
b | text | | extended |
Server: file_s
On 02/19/2011 11:07 PM, Tom Lane wrote:
However, it occurs to me that as long as we're passing the function the
ExplainState, it has what it needs to add arbitrary EXPLAIN result
fields. Although it could do this the hard way, we could make it a lot
easier by exporting the ExplainProperty fu
A couple more questions:
What's the reason for this restriction?
if (databaseId != MyDatabaseId)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("cannot import snapshot from a different
database")));
Why ar
Heikki Linnakangas writes:
> I needed something to test the FDW API patch with, and didn't want to
> get involved in the COPY API changes, and also wanted to have something
> that needs real connection management and can push down quals. So I
> updated the postgresql_fdw patch to work with the
> Well, good news all round.
>
> v17 implements what I believe to be the final set of features for sync
> rep. This one I'm actually fairly happy with. It can be enjoyed best at
> DEBUG3.
>
> The patch is very lite touch on a few areas of code, plus a chunk of
> specific code, all on master-side.
On Sat, Feb 19, 2011 at 9:06 AM, Simon Riggs wrote:
>
> Well, good news all round.
>
> v17 implements what I believe to be the final set of features for sync
> rep. This one I'm actually fairly happy with. It can be enjoyed best at
> DEBUG3.
>
> The patch is very lite touch on a few areas of code,
45 matches
Mail list logo
