On 22.09.2012 20:00, Andres Freund wrote:
[[basic-schema]]
.Architecture Schema
[ditaa]
--
Traditional Stuff
+-+-+-+-++
| Backend | Backend | Backend | Autovac | ...|
On 10/11/2012 04:31 AM, Tom Lane wrote:
Greg Stark st...@mit.edu writes:
On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Isn't there an even more serious problem, namely that this assumes
*all* transactions are serializable? What happens when they aren't?
Or even just that
On 10/11/2012 03:10 AM, Robert Haas wrote:
On Wed, Oct 10, 2012 at 7:02 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
The purpose of ApplyCache/transaction reassembly is to reassemble
interlaced records, and organise them by XID, so that the consumer
client code sees only streams (well,
On 11 October 2012 01:43, Tom Lane t...@sss.pgh.pa.us wrote:
I think we have to revert and go back to the drawing board on this.
Given that change was also sold on the basis of higher performance, I
suggest we retest performance to check there is a gain. If there is
still a gain, I suggest we
Hi Hanada-san,
Please examine attached v2 patch (note that is should be applied onto
latest dblink_fdw_validator patch).
I've reviewed your patch quickly. I noticed that the patch has been created in
a slightly different way from the guidelines:
Heikki Linnakangas hlinnakan...@vmware.com writes:
Now that we support include-directories in postgresql.conf, you could put a
mylib.conf file in the include directory that contains the above line, if
you want to enable/disable a module just by moving things around in the
filesystem (after
On 10/09/2012 10:04 PM, Robert Haas wrote:
- if a table is not yet or no more visible, because of search_path
modification
I don't think I understand the case you are describing here.
Here's a sample :
begin;
set search_path = foo, public;
create table c ( … ) ;
commit;
begin;
set
On 10/09/2012 04:06 PM, Tom Lane wrote:
Second, to my mind the point of a multi-table TRUNCATE is to ensure that
all the referenced tables get reset to empty *together*. With something
like this, you'd have no such guarantee. Consider a timeline like this:
Session 1
On Wednesday, October 10, 2012 9:15 PM Heikki Linnakangas wrote:
On 04.10.2012 13:12, Amit kapila wrote:
Following changes are done to support replication timeout in sender as
well as receiver:
1. One new configuration parameter wal_receiver_timeout is added to
detect timeout at
Do you intend to follow through with this, Jeff?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Oct 02, 2012 at 01:58:40PM -0400, Noah Misch wrote:
On Mon, Aug 27, 2012 at 7:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There's also the big-picture question of whether we should just get rid
of fuzzy comparisons in the geometric types instead of trying to hack
indexes to work
2012/10/11 Dimitri Fontaine dimi...@2ndquadrant.fr:
Heikki Linnakangas hlinnakan...@vmware.com writes:
I've wanted to allow writing i/o functions in non-C languages for a long
time as well, but never got around to do anything about it. Custom datatypes
are really powerful, but as soon as you
On Wed, Oct 10, 2012 at 12:19:17PM -0300, Alvaro Herrera wrote:
Many of those patches waiting on authors have been in such state for a
rather long time. I feel inclined to mark them returned with
feedback, and have them posted again for the next commitfest.
+1
--
Sent via pgsql-hackers
On Thursday, October 11, 2012 09:15:47 AM Heikki Linnakangas wrote:
On 22.09.2012 20:00, Andres Freund wrote:
[[basic-schema]]
.Architecture Schema
[ditaa]
-
-
Traditional Stuff
The flex and bison make rules refactoring I just did broke the Windows
build. I think the fixes should look like the patch below. Could
someone please verify and/or commit that?
diff --git a/src/tools/msvc/pgbison.pl b/src/tools/msvc/pgbison.pl
index d6f2444..15db921 100644
---
Alvaro Herrera escribió:
I also included two new functions in that patch, dlisti_push_head and
dlisti_push_tail. These functions are identical to dlist_push_head and
dlist_push_tail, except that they do not accept non-circular lists.
What this means is that callers that find the
On Thursday, October 11, 2012 03:23:12 PM Alvaro Herrera wrote:
Alvaro Herrera escribió:
I also included two new functions in that patch, dlisti_push_head and
dlisti_push_tail. These functions are identical to dlist_push_head and
dlist_push_tail, except that they do not accept non-circular
On 11.10.2012 13:17, Amit Kapila wrote:
How does this look now?
The Patch is fine and test results are also fine.
Ok, thanks. Committed.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Friday, August 31, 2012 06:59:51 AM Alvaro Herrera wrote:
v21 is merged to latest master.
Ok, I am starting to look at this.
(working with a git merge of alvherre/fklocks into todays master)
In a very first pass as somebody who hasn't followed the discussions in the
past I took notice of
On Thursday, October 11, 2012 8:22 PM Heikki Linnakangas wrote:
On 11.10.2012 13:17, Amit Kapila wrote:
How does this look now?
The Patch is fine and test results are also fine.
Ok, thanks. Committed.
Thank you very much.
With Regards,
Amit Kapila.
--
Sent via pgsql-hackers mailing
Andres Freund wrote:
On Friday, August 31, 2012 06:59:51 AM Alvaro Herrera wrote:
v21 is merged to latest master.
Ok, I am starting to look at this.
(working with a git merge of alvherre/fklocks into todays master)
In a very first pass as somebody who hasn't followed the discussions in
On Thursday, October 11, 2012 03:27:17 PM Andres Freund wrote:
On Thursday, October 11, 2012 03:23:12 PM Alvaro Herrera wrote:
Alvaro Herrera escribió:
I also included two new functions in that patch, dlisti_push_head and
dlisti_push_tail. These functions are identical to dlist_push_head
On 10/11/2012 09:05 AM, Peter Eisentraut wrote:
The flex and bison make rules refactoring I just did broke the Windows
build. I think the fixes should look like the patch below. Could
someone please verify and/or commit that?
Close, but not quite. I have made it work and committed it.
On 10 October 2012 14:56, Pavel Stehule pavel.steh...@gmail.com wrote:
(eelog3.diff)
This looks better.
You need a better comment here:
+ * relerror.c
+ * relation error loging functions
+ *
I'm still not satisfied with the lack of firm guarantees about what
errcodes one can assume
On 11 October 2012 17:53, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 11 October 2012 01:43, Tom Lane t...@sss.pgh.pa.us wrote:
I think we have to revert and go back to the drawing board on this.
Given that change was also sold on the basis of higher
Simon Riggs si...@2ndquadrant.com writes:
On 11 October 2012 17:53, Tom Lane t...@sss.pgh.pa.us wrote:
Maybe what we really need is to find a way to make taking a snapshot a
lot cheaper, such that the whole need for this patch goes away. We're
not going to get far with the idea of making
For starters, the use-case hasn't been explained to my satisfaction.
In what situation is it actually helpful to TRUNCATE a table that's
not there yet? Aren't you going to have to do a CREATE IF NOT EXISTS
to keep from failing later in the script? If so, why not just do that
first?
There
On Wed, Oct 10, 2012 at 6:17 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
IIRC, the parallel pg_dump one is said to need review by a Windows
expert, which is not me, so I've not looked at it.
Andrew? Magnus?
There's,
On 11 October 2012 18:22, Tom Lane t...@sss.pgh.pa.us wrote:
I suggested a way to automatically trigger a second snapshot. I think
that would be acceptable to backpatch.
If it worked, I might be amenable to that, but it doesn't. You can't
trigger taking a new snapshot off whether we waited
On Thu, Oct 11, 2012 at 2:23 PM, Simon Riggs si...@2ndquadrant.com wrote:
So where's the race?
AFAICS it either waits or it doesn't - the code isn't vague on that
point. If we wait we set the flag.
The point is that lock waits are pretty rare since most locks are
compatible, so triggering a
Simon Riggs si...@2ndquadrant.com writes:
On 11 October 2012 18:22, Tom Lane t...@sss.pgh.pa.us wrote:
If it worked, I might be amenable to that, but it doesn't. You can't
trigger taking a new snapshot off whether we waited for a lock; that
still has race conditions, just ones that are not so
On 10/11/2012 02:22 PM, Magnus Hagander wrote:
On Wed, Oct 10, 2012 at 6:17 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
IIRC, the parallel pg_dump one is said to need review by a Windows
expert, which is not me, so I've
On 11 October 2012 19:36, Robert Haas robertmh...@gmail.com wrote:
On Thu, Oct 11, 2012 at 2:23 PM, Simon Riggs si...@2ndquadrant.com wrote:
So where's the race?
AFAICS it either waits or it doesn't - the code isn't vague on that
point. If we wait we set the flag.
The point is that lock
On 11 October 2012 19:41, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 11 October 2012 18:22, Tom Lane t...@sss.pgh.pa.us wrote:
If it worked, I might be amenable to that, but it doesn't. You can't
trigger taking a new snapshot off whether we waited for a
On Wed, Oct 10, 2012 at 3:32 AM, Simon Riggs si...@2ndquadrant.com wrote:
2) Clearly, rollout scripts benefit from not throwing errors.
Personally I would prefer setting SET ddl_abort_on_missing_object =
false; at the top of a script than having to go through every SQL
statement and add extra
I looked into the complaint in bug #7598,
http://archives.postgresql.org/pgsql-bugs/2012-10/msg00090.php
The core of the problem is in an inner sub-select that's written
like
outercol IN (SELECT varcharcol FROM ... WHERE varcharcol = anothercol ...
The = operator is actually texteq, since
On 11 October 2012 19:59, Robert Haas robertmh...@gmail.com wrote:
On Wed, Oct 10, 2012 at 3:32 AM, Simon Riggs si...@2ndquadrant.com wrote:
2) Clearly, rollout scripts benefit from not throwing errors.
Personally I would prefer setting SET ddl_abort_on_missing_object =
false; at the top of a
On Thu, Oct 11, 2012 at 2:48 PM, Simon Riggs si...@2ndquadrant.com wrote:
Hmm, so now the patch author thinks his patch is not just broken with
respect to lock waits, but in all cases? Surely the above race
condition is obvious, now and before. Why is it suddenly unacceptable?
(If you believe
Not many RULE-lovers out there, once you've tried to use them.
Allowing RULEs complicates various things and can make security more difficult.
For 9.3, I suggest we create a DDL trigger by default which prevents
RULEs and throws an ERROR that explains they are now deprecated.
Anybody that
On Thu, Oct 11, 2012 at 2:42 PM, Andrew Dunstan and...@dunslane.net wrote:
I have a quietish few days starting on Saturday, will be looking at this
then. Is it only the Windows aspect that needs reviewing? Are we more or
less happy with the rest?
I think the Windows issues were the biggest
On 11 October 2012 20:25, Robert Haas robertmh...@gmail.com wrote:
On Thu, Oct 11, 2012 at 2:48 PM, Simon Riggs si...@2ndquadrant.com wrote:
Hmm, so now the patch author thinks his patch is not just broken with
respect to lock waits, but in all cases? Surely the above race
condition is
On 11 October 2012 20:30, Robert Haas robertmh...@gmail.com wrote:
On Thu, Oct 11, 2012 at 2:42 PM, Andrew Dunstan and...@dunslane.net wrote:
I have a quietish few days starting on Saturday, will be looking at this
then. Is it only the Windows aspect that needs reviewing? Are we more or
less
Robert Haas robertmh...@gmail.com writes:
So we have to take the snapshot before you begin execution, but it
seems that to avoid surprising behavior we also have to take it after
acquiring locks. And it looks like locking is intertwined with a
bunch of other parse analysis tasks that might
On 11 October 2012 20:43, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So we have to take the snapshot before you begin execution, but it
seems that to avoid surprising behavior we also have to take it after
acquiring locks. And it looks like locking is
Simon Riggs si...@2ndquadrant.com writes:
Not many RULE-lovers out there, once you've tried to use them.
Allowing RULEs complicates various things and can make security more
difficult.
For 9.3, I suggest we create a DDL trigger by default which prevents
RULEs and throws an ERROR that
Hi,
I stumbled across a minor issue in xlog.c:1030: the WAL_DEBUG code block
there passes rdata-data to the rm_desc() methode. However, that's only
the first XLogRecData struct, not the entire XLog record. So the
rm_desc() method effectively reports spurious data for any subsequent part.
Take a
Tom Lane t...@sss.pgh.pa.us writes:
This is utter nonsense. We can't deprecate them until we have a
substitute that is better. If you want to get rid of rules, build the
replacement; don't just try to be a pain in the ass to users.
My understanding is that the main reason why RULEs are bad™
I wrote:
What I'm thinking about is modifying eval_const_expressions so that
one of its responsibilities is to force CoercionForm fields to
COERCE_DONTCARE in the output;
I fooled around with that approach for awhile and didn't like the
results, mainly because it caused EXPLAIN output to
Markus Wanner mar...@bluegap.ch writes:
I stumbled across a minor issue in xlog.c:1030: the WAL_DEBUG code block
there passes rdata-data to the rm_desc() methode. However, that's only
the first XLogRecData struct, not the entire XLog record. So the
rm_desc() method effectively reports spurious
On 10/10/12 9:37 PM, Aaron Sheldon wrote:
I have begun sketching these ideas in off the shelf pgSQL using composite
types and constructor functions; but am far from tackling anything like
building external C extensions to handle the data types. I can set-up a
GitHub repository if anyone is
On 11 October 2012 20:50, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Not many RULE-lovers out there, once you've tried to use them.
Allowing RULEs complicates various things and can make security more
difficult.
For 9.3, I suggest we create a DDL trigger by
On 10/10/12 7:26 PM, Bruce Momjian wrote:
How does Slony write its changes without causing serialization replay
conflicts?
Since nobody from the Slony team answered this:
a) Slony replicates *rows*, not *statements*
b) Slony uses serializable mode internally for row replication
c) it's
On Thu, Oct 11, 2012 at 6:25 PM, Simon Riggs si...@2ndquadrant.com wrote:
Anyway, lets start with a discussion of what rules give us that SQL
standard features do not?
The somewhat broader question that this elicits is How would we go
about deprecating a feature that seems to be troublesome? I
On 11 October 2012 23:28, Josh Berkus j...@agliodbs.com wrote:
For 9.3, I suggest we create a DDL trigger by default which prevents
RULEs and throws an ERROR that explains they are now deprecated.
Well, even if we were considering this, the sequence would need to be:
1. Announce in 9.3 that
Tom,
On 10/11/2012 03:11 PM, Tom Lane wrote:
The original design intention was that rm_desc should not attempt to
print any such data, but obviously some folks didn't get the word.
FWIW: in case the source code contains comments explaining that
intention, I certainly missed them so far.
On Wed, Oct 10, 2012 at 10:26 PM, Bruce Momjian br...@momjian.us wrote:
How does Slony write its changes without causing serialization replay
conflicts?
It uses a sequence to break any ordering conflicts at the time that
data is inserted into its log tables.
If there are two transactions, A
On 11 October 2012 03:16, Greg Stark st...@mit.edu wrote:
On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think I've mentioned it before, but in the interest of not being
seen to critique the bikeshed only after it's been painted: this
design gives up something very
On Thu, Oct 11, 2012 at 3:39 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 11 October 2012 23:28, Josh Berkus j...@agliodbs.com wrote:
For 9.3, I suggest we create a DDL trigger by default which prevents
RULEs and throws an ERROR that explains they are now deprecated.
Well, even if we were
For 9.3, I suggest we create a DDL trigger by default which prevents
RULEs and throws an ERROR that explains they are now deprecated.
Well, even if we were considering this, the sequence would need to be:
1. Announce in 9.3 that RULES will be going away RSN.
2. In 9.4, send a warning every
On 12-10-11 06:27 PM, Josh Berkus wrote:
On 10/10/12 7:26 PM, Bruce Momjian wrote:
How does Slony write its changes without causing serialization replay
conflicts?
Since nobody from the Slony team answered this:
a) Slony replicates *rows*, not *statements*
True, but the proposed logical
With the DDL trigger, we're able to do that faster. The idea is you
can still delete it if you need compatibility, so we get the message
across without an extra release and without an annoying GUC (etc).
You're seeing these things as bugs. I see them as features. And we
don't need a GUC if
Markus Wanner mar...@bluegap.ch writes:
On 10/11/2012 03:11 PM, Tom Lane wrote:
The original design intention was that rm_desc should not attempt to
print any such data, but obviously some folks didn't get the word.
FWIW: in case the source code contains comments explaining that
intention, I
On 10/11/2012 04:06 PM, Tom Lane wrote:
Yeah, if we decide to stick with the limitation, some documentation
would be called for. I remember having run into this and having removed
functionality from an rm_desc function rather than question the premise.
But maybe the extra functionality is
On Thu, Oct 11, 2012 at 3:59 PM, Josh Berkus j...@agliodbs.com wrote:
With the DDL trigger, we're able to do that faster. The idea is you
can still delete it if you need compatibility, so we get the message
across without an extra release and without an annoying GUC (etc).
You're seeing
On 11 October 2012 20:28, Simon Riggs si...@2ndquadrant.com wrote:
Not many RULE-lovers out there, once you've tried to use them.
Allowing RULEs complicates various things and can make security more
difficult.
What exactly do they make more difficult? Are you particularly
concerned with the
On 10/11/2012 03:59 PM, Josh Berkus wrote:
I'm also not real keen on the idea that someone could dump a 9.2
database and be unable to load it into 9.3 because of the DDL trigger,
especially if they might not encounter it until halfway through a
restore. That seems rather user-hostile to me.
On Thu, Oct 11, 2012 at 5:07 PM, Joshua D. Drake j...@commandprompt.com wrote:
On 10/11/2012 03:59 PM, Josh Berkus wrote:
I'm also not real keen on the idea that someone could dump a 9.2
database and be unable to load it into 9.3 because of the DDL trigger,
especially if they might not
On 10/11/2012 08:20 PM, Daniel Farina wrote:
On Thu, Oct 11, 2012 at 5:07 PM, Joshua D. Drake j...@commandprompt.com wrote:
On 10/11/2012 03:59 PM, Josh Berkus wrote:
I'm also not real keen on the idea that someone could dump a 9.2
database and be unable to load it into 9.3 because of the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom and Simon wrote:
If you want to get rid of rules, build the
replacement; don't just try to be a pain in the ass to users.
Supporting broken and non-standard features *is* a pain in the ass to
users, since they are sometimes persuaded
FWIW I thought the stuff in commit 092d7ded2 might be pretty useful
generally.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Andrew Dunstan
Sent: Thursday, October 11, 2012 8:52 PM
To: Daniel Farina
Cc: Joshua D. Drake; Josh Berkus; Simon Riggs;
pgsql-hackers@postgresql.org
Subject: Re:
Josh Berkus wrote:
For 9.3, I suggest we create a DDL trigger by default which prevents
RULEs and throws an ERROR that explains they are now deprecated.
Well, even if we were considering this, the sequence would need to be:
1. Announce in 9.3 that RULES will be going away RSN.
2. In 9.4, send
What's the deal with the line type?
It's installed in the catalogs and listed in the documentation,
varyingly as not implemented or not fully implemented, but all the
support functions throw an error. Is there any known list of things
that would need to be done to make it fully implemented? Or
Thanks for looking at this.
Attached is a rebased patch using new OIDs.
On 11 October 2012 02:39, Peter Eisentraut pete...@gmx.net wrote:
Compiler warning needs to be fixed:
rewriteHandler.c: In function 'RewriteQuery':
rewriteHandler.c:2153:29: error: 'view_rte' may be used uninitialized in
74 matches
Mail list logo