On 19 December 2012 06:10, Magnus Hagander mag...@hagander.net wrote:
This sounds like my previous suggestion of returning the primary conninfo
value, but with just ip. That one came with a pretty bad patch, and was
later postponed until we folded recovery.conf into the main configuration
2012/12/19 Shigeru Hanada shigeru.han...@gmail.com:
On Tue, Dec 18, 2012 at 2:52 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Attached updated patch
Seems fine. I'll mark this as ready for committer.
Nice work!
thank you very much
Regards
Pavel
--
Shigeru HANADA
--
Sent via
On 19 December 2012 06:34, Magnus Hagander mag...@hagander.net wrote:
Granting executability on pg_read_xyz is pretty darn close to granting
superuser, without explicitly asking for it. Well, you get read only
superuser. If we want to make that step as easy as just GRANT, we
really need to
On 12/18/2012 11:57 PM, Simon Riggs wrote:
On 19 December 2012 03:03, Josh Berkus j...@agliodbs.com wrote:
So, my question is:
1. should we detect for replication cycles? *Can* we?
2. should we warn the user, or refuse to start up?
Why not just monitor the config you just created?
On 19 December 2012 08:11, Joshua D. Drake j...@commandprompt.com wrote:
On 12/18/2012 11:57 PM, Simon Riggs wrote:
On 19 December 2012 03:03, Josh Berkus j...@agliodbs.com wrote:
So, my question is:
1. should we detect for replication cycles? *Can* we?
2. should we warn the user, or
Can you post the full definition of the table on this public email list?
Also, why did the error think this was in the public schema? Any idea?
---
18.12.2012, 19:38, Bruce Momjian br...@momjian.us:
On Mon, Dec 17,
Re: Tom Lane 2012-12-18 8705.1355845...@sss.pgh.pa.us
The correct fix, IMO/IIRC, is to add LDFLAGS=-Wl,--as-needed before
running most of the configure checks, instead of after.
Meh. It's not clear to me at all that that fixes the issue here,
or at least that it does so in any way that's
On Wed, Dec 12, 2012 at 12:06 AM, Bruce Momjian br...@momjian.us wrote:
On Sat, Dec 8, 2012 at 08:59:00AM -0500, Phil Sorber wrote:
On Sat, Dec 8, 2012 at 7:50 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Bruce mentionned that pg_isready could be used directly by pg_ctl -w.
On Wed, Dec 19, 2012 at 12:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 17, 2012 at 1:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This is definitely not per make's contract, either. I think maybe the
Don't rebuild the list if only the OBJS have
On 19.12.2012 04:57, Josh Berkus wrote:
Heikki,
I ran into an unexpected issue while testing. I just wanted to fire up
a chain of 5 replicas to see if I could connect them in a loop.
However, I ran into a weird issue when starting up r3: it refused to
come out of the database is starting up
On Tue, Dec 18, 2012 at 10:33:12AM +0100, Dimitri Fontaine wrote:
Robert Haas robertmh...@gmail.com writes:
And on the other hand, if you could get a clean split between the two
grammars, then regardless of exactly what the split was, it might seem
a win. But it seemed to me when I looked
On Tue, Dec 18, 2012 at 5:05 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Sorry for the malformed and duplicate post. I was not trying to be
emphatic; I was testing out gmail offline. Clearly the test didn't go
too well.
Jeff
--
Sent via pgsql-hackers mailing list
Hello.
I've noticed that, when implementing a FDW, it is difficult to use a plan
which
best path is a parameterized path. This comes from the fact that the
parameterized clause is not easily available at plan time.
This is what I understood from how it works:
- The clauses coming from the
On Sat, Dec 15, 2012 at 4:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On the other hand, the HOT prune operation itself is worthless when
we're running a SELECT. The only reason we do it that way is that we
have to prune before the query starts to use the page, else pruning
might invalidate
While playing with LDAP authentication, I discovered
two documentation bugs.
First, user and password for the first step in the
two-step authentication mode are ldapbinddn and
ldapbindpasswd, not ldapbinduser and ldapbinddn.
This bug has been there since 8.4.
The second one is new in 9.3 with
On 19.12.2012 15:55, Heikki Linnakangas wrote:
On 19.12.2012 04:57, Josh Berkus wrote:
Heikki,
I ran into an unexpected issue while testing. I just wanted to fire up
a chain of 5 replicas to see if I could connect them in a loop.
However, I ran into a weird issue when starting up r3: it
On 19.12.2012 17:27, Heikki Linnakangas wrote:
On 19.12.2012 15:55, Heikki Linnakangas wrote:
On 19.12.2012 04:57, Josh Berkus wrote:
Heikki,
I ran into an unexpected issue while testing. I just wanted to fire up
a chain of 5 replicas to see if I could connect them in a loop.
However, I ran
Hello again,
well, still everything is working.
What information do you need to get into this issue?
Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some
more or less changed enum_add and enum_del (Which are appended at the
end) to be able to change enums within
On 2012-12-19 16:51:32 +0100, Bernhard Schrader wrote:
Hello again,
well, still everything is working.
What information do you need to get into this issue?
Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some more
or less changed enum_add and enum_del (Which are appended
On Wed, Dec 19, 2012 at 8:32 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Dec 15, 2012 at 4:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On the other hand, the HOT prune operation itself is worthless when
we're running a SELECT. The only reason we do it that way is that we
have to prune
In both checkpointer.c and bgwriter.c, we do this before entering the
main loop:
/*
* Use the recovery target timeline ID during recovery
*/
if (RecoveryInProgress())
ThisTimeLineID = GetRecoveryTargetTLI();
That seems reasonable. However, since
On 12/19/2012 10:56 AM, Andres Freund wrote:
On 2012-12-19 16:51:32 +0100, Bernhard Schrader wrote:
Hello again,
well, still everything is working.
What information do you need to get into this issue?
Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some more
or less changed
Robert Haas robertmh...@gmail.com writes:
On Sat, Dec 15, 2012 at 4:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Maybe it's time to look at what it'd take for the low-level scan
operations to know whether they're scanning the target relation of
an UPDATE query, so that we could skip pruning
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-19 16:51:32 +0100, Bernhard Schrader wrote:
Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some more
or less changed enum_add and enum_del (Which are appended at the end) to be
able to change enums within transactions.
On Wed, Dec 19, 2012 at 9:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we start generating a lot of useless WAL activity and I/O as
a result of thrashing the all-visible bit, it won't be so tolerable
anymore.
What if we wrap that into the WAL generated by HOT prune itself ?
Would that address
On 12/19/2012 11:31 AM, Tom Lane wrote:
enum_add is all right as long as you are careful to commit its
transaction before inserting the new value anywhere.
It's not really all right for post-9.0 versions. For example, this is wrong:
--postgres 9.2 or higher
On 12/19/2012 12:34 AM, Simon Riggs wrote:
My logic is that if you make a 1 minute test you will notice your
mistake, which is glaringly obvious. That is sufficient to prevent
that mistake, IMHO.
If you don't test your config and don't monitor either, good luck with HA.
I am not arguing
On Wed, Dec 19, 2012 at 11:49 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Also, if extra WAL-logging is really worrisome, may be we should again
seriously reconsider my idea of *not* clearing the bit at HOT update.
My apologies for repeating myself. But that seems very important in a
Andrew Dunstan and...@dunslane.net writes:
what is even worse is that this procedure doesn't take any care at all
of the ordering rule for even numbered enum oids.
Good point. You really should use ALTER TYPE ADD VALUE, on versions
where that's available.
regards, tom
On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
postgres= INSERT INTO t1 VALUES (4,'ddd');
INSERT 0 1
postgres= INSERT INTO t1 VALUES (5,'eee');
ERROR: new row for relation t1 violates row-secirity
DETAIL: Failing row contains (5, eee).
I've argued against this
On Wed, Dec 19, 2012 at 10:40 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 19, 2012 at 11:49 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Also, if extra WAL-logging is really worrisome, may be we should again
seriously reconsider my idea of *not* clearing the bit at HOT
Heikki,
The problem goes away after some time, after the 1st standby has
streamed the contents of 00020003 and written it to
disk, and the cascaded standby reconnects. But it would be nice to
avoid
that situation. I'm not sure how to do that yet, we might need to
track
the
On 19 December 2012 16:21, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Dec 15, 2012 at 4:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Maybe it's time to look at what it'd take for the low-level scan
operations to know whether they're scanning the target
Heikki,
The next time I get the issue, and I'm not paying for 5 cloud servers by the
hour, I'll give you a login.
--Josh
- Original Message -
On 19.12.2012 17:27, Heikki Linnakangas wrote:
On 19.12.2012 15:55, Heikki Linnakangas wrote:
On 19.12.2012 04:57, Josh Berkus wrote:
On 19 December 2012 17:25, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
postgres= INSERT INTO t1 VALUES (4,'ddd');
INSERT 0 1
postgres= INSERT INTO t1 VALUES (5,'eee');
ERROR: new row for relation t1 violates row-secirity
Groshev Andrey wrote:
Mismatch of relation names: database database, old rel
public.lob.ВерсияВнешнегоДокумента$Документ_pkey, new rel
public.plob.ВерсияВнешнегоДокумента$Документ
There is a limit on identifiers of 63 *bytes* (not characters)
after which the name is truncated. In UTF8
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
postgres= INSERT INTO t1 VALUES (4,'ddd');
INSERT 0 1
postgres= INSERT INTO t1 VALUES (5,'eee');
ERROR: new row for relation t1 violates row-secirity
DETAIL: Failing row
Kevin Grittner kgri...@mail.com writes:
Groshev Andrey wrote:
 Mismatch of relation names: database database, old rel
public.lob.ÐеÑÑиÑÐнеÑнегоÐокÑменÑа$ÐокÑменÑ_pkey,
new rel
public.plob.ÐеÑÑиÑÐнеÑнегоÐокÑменÑа$ÐокÑменÑ
Pavan Deolasee pavan.deola...@gmail.com writes:
On Wed, Dec 19, 2012 at 9:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we start generating a lot of useless WAL activity and I/O as
a result of thrashing the all-visible bit, it won't be so tolerable
anymore.
What if we wrap that into the WAL
On 19 December 2012 18:40, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
postgres= INSERT INTO t1 VALUES (4,'ddd');
INSERT 0 1
postgres= INSERT INTO t1 VALUES (5,'eee');
ERROR: new row
Ronan Dunklau rdunk...@gmail.com writes:
I've noticed that, when implementing a FDW, it is difficult to use a plan
which
best path is a parameterized path. This comes from the fact that the
parameterized clause is not easily available at plan time.
This is what I understood from how it
Simon Riggs wrote:
This is security, not spec compliance. By default, we need full
security.
But you are arguing that users should not be able to make something
secure if they, and everyone with the same permissions, could not
later access it. I thought about situations where I've seen a need
On 19 December 2012 19:46, Kevin Grittner kgri...@mail.com wrote:
But you are arguing that users should not be able to make something
secure if they, and everyone with the same permissions, could not
later access it.
Not exactly, no.
I've argued that row security should apply to ALL commands
On 2012-12-19 14:46:18 -0500, Kevin Grittner wrote:
Simon Riggs wrote:
This is security, not spec compliance. By default, we need full
security.
But you are arguing that users should not be able to make something
secure if they, and everyone with the same permissions, could not
later
Simon Riggs wrote:
I've argued that row security should apply to ALL commands by default.
Which is exactly the same default as Oracle, as well as being the
obvious common sense understanding of row security, which does not
cause a POLA violation.
I have no objection to an option to allow
Andres Freund wrote:
I don't think it is that simple. Allowing inserts without regard for row
level restrictions makes it far easier to probe for data. E.g. by
inserting rows and checking for unique violations.
Unless you want to go to a military-style security level system
where people at
On 19 December 2012 20:23, Kevin Grittner kgri...@mail.com wrote:
I hope we can leave the syntax for this feature open to such
specification, even if the initial implementation only supports
limiting reads.
Well, I hope the opposite: that we can support simple full security by
default, while
The more secure behavior is to allow entry of data which will not be
visible by the person doing the entry.
I don't think it is that simple. Allowing inserts without regard for row
level
restrictions makes it far easier to probe for data. E.g. by inserting rows
and
checking for unique
On 19 December 2012 20:37, Kevin Grittner kgri...@mail.com wrote:
Andres Freund wrote:
I don't think it is that simple. Allowing inserts without regard for row
level restrictions makes it far easier to probe for data. E.g. by
inserting rows and checking for unique violations.
Unless you
On 19.12.2012 06:30, Jeevan Chalke wrote:
On Mon, Dec 17, 2012 at 5:37 AM, Tomas Vondra t...@fuzzy.cz
mailto:t...@fuzzy.cz wrote:
Hi,
attached is a new version of the patch that
(a) converts the 'log_step_seconds' variable to a constant (and does
not allow
On 19.12.2012 07:34, Magnus Hagander wrote:
On Wed, Dec 19, 2012 at 1:58 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 18.12.2012 18:38, Pavel Stehule wrote:
2012/12/18 Peter Eisentraut pete...@gmx.net:
There are some system administration functions that have hardcoded
superuser checks,
Simon Riggs wrote:
Kevin Grittner kgri...@mail.com wrote:
I hope we can leave the syntax for this feature open to such
specification, even if the initial implementation only supports
limiting reads.
Well, I hope the opposite: that we can support simple full security by
default, while
On 2012-12-19 18:25, Robert Haas wrote:
On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
postgres= INSERT INTO t1 VALUES (4,'ddd');
INSERT 0 1
postgres= INSERT INTO t1 VALUES (5,'eee');
ERROR: new row for relation t1 violates row-secirity
DETAIL: Failing row contains
Hi,
one of our local users reported he's getting OOM errors on 9.2, although
on 9.1 the code worked fine. Attached is a simple test-case that should
give you an OOM error almost immediately.
What it does:
1) creates a simple table called test with one text column.
2) creates a plpgsql function
Simon,
My logic is that if you make a 1 minute test you will notice your
mistake, which is glaringly obvious. That is sufficient to prevent
that mistake, IMHO.
What would such a test look like? It's not obvious to me that there's any
rapid way for a user to detect this situation, without
It stalled because the patch author decided not to implement the
request to detect recovery.conf in data directory, which allows
backwards compatibility.
Well, I don't think we had agreement on how important backwards compatibility
for recovery.conf was, particularly not on the whole
This sounds like my previous suggestion of returning the primary
conninfo value, but with just ip. That one came with a pretty bad
patch, and was later postponed until we folded recovery.conf into
the main configuration file parsing. I'm not really sure what
happened to that project? (the
On 19 December 2012 22:19, Joshua Berkus j...@agliodbs.com wrote:
It stalled because the patch author decided not to implement the
request to detect recovery.conf in data directory, which allows
backwards compatibility.
Well, I don't think we had agreement on how important backwards
On Tue, 2012-12-04 at 01:03 -0800, Jeff Davis wrote:
4. We need some general performance testing to show whether this is
insane or not.
I ran a few tests.
Test 1 - find worst-case overhead for the checksum calculation on write:
fsync = off
bgwriter_lru_maxpages = 0
shared_buffers =
On 19 December 2012 17:26, Pavan Deolasee pavan.deola...@gmail.com wrote:
We definitely
made great progress by having HOT
Yes, definitely. Great work. That is not for debate.
But I think generally HOT made great difference to the
system as a whole, may be at a cost of slowdown for some
On Thu, Dec 20, 2012 at 12:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
What if we wrap that into the WAL generated by HOT prune itself ?
What WAL? The case we're worried about here is that there's nothing
else for HOT prune to do.
Does such a
On Thu, Dec 20, 2012 at 5:05 AM, Simon Riggs si...@2ndquadrant.com wrote:
And those last things are being debated hotly. We definitely need to
ask whether the way things are now can be tweaked to be better. The
major mechanics need not be reviewed, but the tradeoffs and balances?
Definitely.
Tomas Vondra t...@fuzzy.cz writes:
On 19.12.2012 07:34, Magnus Hagander wrote:
Granting executability on pg_read_xyz is pretty darn close to granting
superuser, without explicitly asking for it. Well, you get read only
superuser. If we want to make that step as easy as just GRANT, we
really
On Tue, Dec 18, 2012 at 7:03 PM, Josh Berkus j...@agliodbs.com wrote:
2. should we warn the user, or refuse to start up?
One nice property of allowing cyclicity is that it's easier to
syndicate application of WAL to a series of standbys before promotion
of exactly one to act as a primary
On Wed, Dec 19, 2012 at 12:54 PM, Simon Riggs si...@2ndquadrant.com wrote:
I can see a use case for not having security apply for users who have
*only* INSERT privilege. This would allow people to run bulk loads of
data into a table with row security. We should add that. That is not
the common
On Wed, Dec 19, 2012 at 1:58 PM, Simon Riggs si...@2ndquadrant.com wrote:
If we don't enforce rules on INSERT the user has to specifically add a
trigger, which makes things noticeably slower. There is more
maintenance work for the average user, less performance and more
mistakes to make.
On Wed, Dec 19, 2012 at 5:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
As ever, we spent much energy on debating backwards compatibility
rather than just solving the problem it posed, which is fairly easy to
solve.
I'm still of the opinion (as were a lot of people on the previous
thread,
On Wed, Dec 19, 2012 at 12:26 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
This can be handled by breaking 1-to-1 mapping on VM bit and
PD_ALL_VISIBLE bit. So seq scans will only look at PD_ALL_VISIBLE. It
was proposed by Andres up thread, but shot down by Tom and Simon. But
I still feel
On Wed, Dec 19, 2012 at 12:39 PM, Simon Riggs si...@2ndquadrant.com wrote:
The benefit of saying that only UPDATEs clean the block is that this
penalises only the workload making the mess, rather than everybody
cleaning up repeatedly over one messy guy.
Right, but there are plenty of
Bug #7758 seems to be a rediscovery of the behavior that Itagaki-san
complained of a couple years ago:
http://archives.postgresql.org/pgsql-hackers/2010-09/msg02035.php
While reconsidering the various not-too-satisfactory fixes we thought of
back then, I had a sudden thought. Instead of having a
Tomas Vondra t...@fuzzy.cz writes:
What it does:
1) creates a simple table called test with one text column.
2) creates a plpgsql function with one parameter, and all that function
does is passing the parameter to EXECUTE
3) calls the function with a string containing many INSERTs into
On 19.12.2012 02:18, Andres Freund wrote:
On 2012-12-17 00:31:00 +0100, Tomas Vondra wrote:
I think except of the temp buffer issue mentioned below its ready.
-DropRelFileNodeAllBuffers(RelFileNodeBackend rnode)
+DropRelFileNodeAllBuffers(RelFileNodeBackend * rnodes, int nnodes)
{
-
I recently came across a scenario like this (tested on git head):
CREATE TABLE test (id int);
CREATE INDEX test_idx1 ON test (id);
CREATE INDEX test_idx2 ON test (id);
CREATE TABLE test_copycat (LIKE test INCLUDING ALL);
\d test_copycat
Why do we end up with only one index on
On 20.12.2012 02:29, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
What it does:
1) creates a simple table called test with one text column.
2) creates a plpgsql function with one parameter, and all that function
does is passing the parameter to EXECUTE
3) calls the function
On Tue, Dec 18, 2012 at 10:44 PM, Robert Haas robertmh...@gmail.com wrote:
Yeah, that's why I don't know how to make it work. It feels like this
is partly artifact of the tool, though. I mean, suppose we haven't
read anything yet. Then, the next token can't be an IDENT, so if we
see an
On Wed, Dec 19, 2012 at 01:51:08PM +0400, Groshev Andrey wrote:
Can you post the full definition of the table on this public email list?
Also, why did the error think this was in the public schema? Any idea?
---
Greg Stark st...@mit.edu writes:
But I'm not entirely convinced any of this is actually useful. Just
becuase the transition table is large doesn't mean it's inefficient.
That's a fair point. However, I've often noticed base_yyparse() showing
up rather high on profiles --- higher than seemed
On Wed, Dec 19, 2012 at 12:56:05PM -0500, Kevin Grittner wrote:
Groshev Andrey wrote:
Mismatch of relation names: database database, old rel
public.lob.ВерсияВнешнегоДокумента$Документ_pkey, new rel
public.plob.ВерсияВнешнегоДокумента$Документ
There is a limit on identifiers of
On Wed, Dec 19, 2012 at 01:51:08PM +0400, Groshev Andrey wrote:
Can you post the full definition of the table on this public email list?
Also, why did the error think this was in the public schema? Any idea?
---
On Thu, Dec 20, 2012 at 6:12 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 19, 2012 at 12:26 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
This can be handled by breaking 1-to-1 mapping on VM bit and
PD_ALL_VISIBLE bit. So seq scans will only look at PD_ALL_VISIBLE. It
was
On Wed, Dec 19, 2012 at 10:35:11PM -0500, Bruce Momjian wrote:
There is another table ВерсияВнешнегоДокумента$Документ (without ^lob.)
It is referenced by a foreign key
(rlob.ВерсияВнешнегоДокумента$Документ-@Файл)
But as I understand it, the problem with the primary key.
Does the old
On Thursday, December 20, 2012 3:50 AM Joshua Berkus wrote:
It stalled because the patch author decided not to implement the
request to detect recovery.conf in data directory, which allows
backwards compatibility.
Well, I don't think we had agreement on how important backwards
No, old database not use table plob..
only primary key
--
-- Name: plob.ВерсияВнешнегоДокумента$Документ; Type: CONSTRAINT; Schema:
public; Owner: postgres; Tablespace:
--
-- For binary upgrade, must preserve pg_class oids
SELECT
On Thursday, December 20, 2012 6:14 AM Robert Haas wrote:
On Wed, Dec 19, 2012 at 12:39 PM, Simon Riggs si...@2ndquadrant.com
wrote:
The benefit of saying that only UPDATEs clean the block is that this
penalises only the workload making the mess, rather than everybody
cleaning up
No, people can confuse writing, but it makes a computer.
Unfortunately, I have not found developer this database, but I understand the
logic was:
plob - primary key (lob ~ BLOB)
rlob - reference key (lob ~ BLOB)
Maybe if I describe the task, this part of the database, the problem is clear.
We
I'm initialize data dir with use ru_RU.UTF8, but this databse use CP1251, ie
one byte per character.
19.12.2012, 21:47, Tom Lane t...@sss.pgh.pa.us:
Kevin Grittner kgri...@mail.com writes:
Groshev Andrey wrote:
Mismatch of relation names: database database, old rel
I intentionally did the nestloop_params substitution after calling
GetForeignPlan not before. It's not apparent to me why it would be
useful to do it before, because the FDW is going to have no idea what
those params represent. (Note that they represent values coming from
some other,
On 20 December 2012 11:51, Tom Lane t...@sss.pgh.pa.us wrote:
While reconsidering the various not-too-satisfactory fixes we thought of
back then, I had a sudden thought. Instead of having a COMMUTATOR or
NEGATOR forward reference create a shell operator and link to it,
why not simply
88 matches
Mail list logo
