On 20 June 2012 11:26, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Simon Riggs si...@2ndquadrant.com wrote:
The proposal is to use WAL to generate the logical change stream.
That has been shown in testing to be around x4 faster than having
a separate
On 20.06.2012 01:27, Kevin Grittner wrote:
Andres Freundand...@2ndquadrant.com wrote:
Yes, thats definitely a valid use-case. But that doesn't preclude
the other - also not uncommon - use-case where you want to have
different master which all contain up2date data.
I agree. I was just
On 20 June 2012 08:35, Robert Haas robertmh...@gmail.com wrote:
I expect it would be fine to have a tool that pulls LCRs out of WAL to
prepare that to be sent to remote locations. Is that what you have in
mind?
Yes. I think it should be possible to generate LCRs from WAL, but I
think that
On 20 June 2012 14:40, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The reason we need an origin id in this scenario is that otherwise this will
happen:
1. A row is updated on node A
2. Node B receives the WAL record from A, and updates the corresponding row
in B. This
On 01.06.2012 03:02, Jeff Janes wrote:
I've attached a new patch which addresses several of your concerns,
and adds the documentation. The description is much longer than the
descriptions of other nearby options, which mostly just give a simple
statement of what they do rather than a
On 20 June 2012 15:32, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 01.06.2012 03:02, Jeff Janes wrote:
I've attached a new patch which addresses several of your concerns,
and adds the documentation. The description is much longer than the
descriptions of other nearby
On 20.06.2012 10:32, Simon Riggs wrote:
On 20 June 2012 14:40, Heikki Linnakangas
And I'm worried
it might not even be enough in more complicated scenarios.
It is not the only required conflict mechanism, and has never been
claimed to be so. It is simply one piece of information needed, at
Currently pgbench -i prints following message every 10k tuples created.
fprintf(stderr, %d tuples done.\n, j);
I think it's long time ago when the frequency of message seemed to be
appropriate because computer is getting so fast these days and every
10k message seems to
On 20 June 2012 15:45, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 10:32, Simon Riggs wrote:
On 20 June 2012 14:40, Heikki Linnakangas
And I'm worried
it might not even be enough in more complicated scenarios.
It is not the only required conflict
On 20.06.2012 11:17, Simon Riggs wrote:
On 20 June 2012 15:45, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 10:32, Simon Riggs wrote:
On 20 June 2012 14:40, Heikki Linnakangas
And I'm worried
it might not even be enough in more complicated scenarios.
It is
Hi list,
The recent 9.2 beta releases have used a slightly different numbering
scheme than all previous releases.
It used to be that tarballs for version $VER were always available at:
http://ftp.postgresql.org/pub/source/v$VER/postgresql-$VER.tar.bz2
However, the new releases now use
On 20 June 2012 16:23, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It's only needed for multi-master replication, where the same table can be
updated from multiple nodes. Just leave that out for now. There's plenty of
functionality and issues left even without that.
Huh?
On 20.06.2012 11:34, Simon Riggs wrote:
On 20 June 2012 16:23, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It's only needed for multi-master replication, where the same table can be
updated from multiple nodes. Just leave that out for now. There's plenty of
functionality and
On 20.06.2012 11:04, Tatsuo Ishii wrote:
Currently pgbench -i prints following message every 10k tuples created.
fprintf(stderr, %d tuples done.\n, j);
I think it's long time ago when the frequency of message seemed to be
appropriate because computer is getting so fast
On Wednesday, June 20, 2012 02:35:59 AM Robert Haas wrote:
On Tue, Jun 19, 2012 at 5:59 PM, Christopher Browne cbbro...@gmail.com
wrote:
On Tue, Jun 19, 2012 at 5:46 PM, Robert Haas robertmh...@gmail.com
wrote:
Btw, what do you mean with conflating the stream? I don't really see
that
On Wed, Jun 20, 2012 at 10:28 AM, Marti Raudsepp ma...@juffo.org wrote:
Hi list,
The recent 9.2 beta releases have used a slightly different numbering
scheme than all previous releases.
It used to be that tarballs for version $VER were always available at:
On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander mag...@hagander.net wrote:
(I do believe that using the v9.2.0beta marker is
*better*, because then it sorts properly. But likely not enough much
better to be inconsistent with previous versions)
Good point. Maybe that's a reason to change the
On 20 June 2012 16:44, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 11:34, Simon Riggs wrote:
On 20 June 2012 16:23, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It's only needed for multi-master replication, where the same table can
be
On sön, 2012-06-17 at 23:58 +0100, Peter Geoghegan wrote:
So if you take the word Aßlar here - that is equivalent to Asslar,
and so strcoll(Aßlar, Asslar) will return 0 if you have the right
LC_COLLATE
This is not actually correct. glibc will sort Asslar before Aßlar, and
that is correct in
Hi Robert, Hi All!
On Wednesday, June 20, 2012 03:08:48 AM Robert Haas wrote:
On Tue, Jun 19, 2012 at 2:23 PM, Andres Freund and...@2ndquadrant.com
wrote:
Well, the words are fuzzy, but I would define logical replication to
be something which is independent of the binary format in which
On Tue, Jun 19, 2012 at 8:06 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 19, 2012 at 10:56 PM, Jeff Janes jeff.ja...@gmail.com wrote:
But in the 9.2 branch, the slow phenotype was re-introduced in
1575fbcb795fc331f4, although perhaps the details of who is locking
what differs. I
Hi KaiGai-san,
Thank you for the review.
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kohei KaiGai
Sent: Wednesday, June 20, 2012 1:26 AM
To: Etsuro Fujita
Cc: Robert Haas; pgsql-hackers@postgresql.org
On 20 June 2012 11:00, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2012-06-17 at 23:58 +0100, Peter Geoghegan wrote:
So if you take the word Aßlar here - that is equivalent to Asslar,
and so strcoll(Aßlar, Asslar) will return 0 if you have the right
LC_COLLATE
This is not actually
On Jun19, 2012, at 17:36 , Robert Haas wrote:
On Mon, Jun 18, 2012 at 1:42 PM, Martijn van Oosterhout
klep...@svana.org wrote:
On Sun, Jun 17, 2012 at 12:29:53PM -0400, Tom Lane wrote:
The fly in the ointment with any of these ideas is that the configure
list is not a list of exact cipher
On Wednesday, June 20, 2012 05:01:16 AM Robert Haas wrote:
On Tue, Jun 19, 2012 at 4:22 PM, Andres Freund and...@2ndquadrant.com
wrote:
1. dllist.h has double the element overhead by having an inline value
pointer (which is not needed when embedding) and a pointer to the list
(which I
On 06/15/2012 05:40 PM, Honza Horak wrote:
I realized the patch has some difficulties -- namely the socket path in the
data dir lock file, which currently uses one port for socket and the same for
interface. So to allow users to use arbitrary port for all unix sockets, we'd
need to add
On Mon, Jun 11, 2012 at 6:06 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jun 12, 2012 at 12:47 AM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jun 11, 2012 at 5:37 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Jun 11, 2012 at 3:24 AM, Magnus Hagander mag...@hagander.net
On Tue, Jun 19, 2012 at 5:57 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 19, 2012 at 4:14 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Well, that was easier than I thought. Attached is a patch to make XLogRecPtr
a uint64, on top of my other WAL format patches.
On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp ma...@juffo.org wrote:
On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander mag...@hagander.net wrote:
(I do believe that using the v9.2.0beta marker is
*better*, because then it sorts properly. But likely not enough much
better to be inconsistent
2012/6/20 Magnus Hagander mag...@hagander.net:
On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp ma...@juffo.org wrote:
On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander mag...@hagander.net
wrote:
(I do believe that using the v9.2.0beta marker is
*better*, because then it sorts properly. But
On 11 June 2012 23:47, Magnus Hagander mag...@hagander.net wrote
You agreed to add something like NOSYNC option into START_REPLICATION
command?
I'm on the fence. I was hoping somebody else would chime in with an
opinion as well.
Why would you add it to synchronous_standby_names and then
On ons, 2012-06-20 at 13:26 +0200, Magnus Hagander wrote:
On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp ma...@juffo.org wrote:
On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander mag...@hagander.net
wrote:
(I do believe that using the v9.2.0beta marker is
*better*, because then it sorts
As I had written in [0], using /usr/bin/install instead of install-sh
can significantly speed up the time to run make install, and hence make
check. Using /usr/bin/install is standard in all autotools-using
projects. PostgreSQL has removed the use of /usr/bin/install because of
the incident
On 19 June 2012 19:44, Peter Geoghegan pe...@2ndquadrant.com wrote:
PostgreSQL supported Unicode before 2005, when the tie-breaker was
introduced. I know at least one Swede who used Postgres95. I just took
a look at the REL6_4 branch, and it looks much the same in 1999 as it
did in 2005, in
Heikki Linnakangas wrote:
I don't like the idea of adding the origin id to the record header.
It's only required in some occasions, and on some record types.
Right.
And I'm worried it might not even be enough in more complicated
scenarios.
Perhaps we need a more generic WAL record
On Wed, Jun 20, 2012 at 6:59 AM, Andres Freund and...@2ndquadrant.com wrote:
My guess is that it wouldn't be too hard to remove some of the extra
pointers. Anyone who is using Dllist as a non-inline list could be
converted to List * instead.
There are only three users of the whole dllist.h.
On Wed, Jun 20, 2012 at 5:15 AM, Andres Freund and...@2ndquadrant.com wrote:
As I said before, I definitely agree that we want to have a separate transport
format once we have decoding nailed down. We still need to ship wal around if
the decoding happens in a different instance, but *after*
On Wednesday, June 20, 2012 02:51:30 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 6:59 AM, Andres Freund and...@2ndquadrant.com
wrote:
Also, the performance-critical things
could be reimplemented as macros.
I question, though, whether we really need both single and doubly linked
On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs si...@2ndquadrant.com wrote:
The idea that logical rep is some kind of useful end goal in itself is
slightly misleading. If the thought is to block multi-master
completely on that basis, that would be a shame. Logical rep is the
mechanism for
On Wednesday, June 20, 2012 03:19:55 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs si...@2ndquadrant.com wrote:
The idea that logical rep is some kind of useful end goal in itself is
slightly misleading. If the thought is to block multi-master
completely on that basis,
I'm almost inclined to suggest that we not get next-LSN from WAL, but
by scanning all the pages in the main data store and computing the max
observed LSN. This is clearly not very attractive from a performance
standpoint, but it would avoid the obvious failure mode where you lost
some
I had trouble finding what operators arrays supported or which ones
had index support or even determining that arrays could be indexed from
the documentation from the array data type. So, patch.
-Ryan Kelly
diff --git a/doc/src/sgml/array.sgml b/doc/src/sgml/array.sgml
index 3508ba3..51d996d
On Wed, Jun 20, 2012 at 9:12 AM, Andres Freund and...@2ndquadrant.com wrote:
Uh. I don't want to just go around and replace anything randomly. Actually I
don't want to change anything for now except whats necessary to get the patch
in. The point I tried to make was just that the relatively
On 20 June 2012 21:19, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs si...@2ndquadrant.com wrote:
The idea that logical rep is some kind of useful end goal in itself is
slightly misleading. If the thought is to block multi-master
completely on that
On Wednesday, June 20, 2012 03:24:58 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 9:12 AM, Andres Freund and...@2ndquadrant.com
wrote:
Uh. I don't want to just go around and replace anything randomly.
Actually I don't want to change anything for now except whats necessary
to get the patch
On Wed, Jun 20, 2012 at 9:21 AM, Amit Kapila amit.kap...@huawei.com wrote:
Example Scenario -
Now assume we have Data files and WAL files intact and only control file is
lost.
Just so I understand correctly, the aim of this is to fix the
situation where out of the thousands of files and
On Wed, Jun 20, 2012 at 9:25 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 20 June 2012 21:19, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs si...@2ndquadrant.com wrote:
The idea that logical rep is some kind of useful end goal in itself is
slightly
On Wednesday, June 20, 2012 03:02:28 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 5:15 AM, Andres Freund and...@2ndquadrant.com
wrote:
One bit is fine if you have only very simple replication topologies. Once
you think about globally distributed databases its a bit different. You
describe
On 20 June 2012 20:37, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Heikki Linnakangas wrote:
I don't like the idea of adding the origin id to the record header.
It's only required in some occasions, and on some record types.
Right.
Wrong, as explained.
And I'm worried it might not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/19/2012 01:47 AM, Christopher Browne wrote:
That numbering scheme gets pretty anti-intuitive fairly quickly,
from whence we took the approach of having a couple digits
indicating data centre followed by a digit indicating which node in
that
On Wed, Jun 20, 2012 at 9:43 AM, Andres Freund and...@2ndquadrant.com wrote:
If you do that, then, yes,
everything that you need to disentangle various network topologies
must be present in WAL. But what I'm saying is: don't do it like
that. Generate the LCRs just ONCE, at the origin node,
On Wednesday, June 20, 2012 03:42:39 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 9:25 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 20 June 2012 21:19, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs si...@2ndquadrant.com
wrote:
The idea that
On Wednesday, June 20, 2012 03:54:43 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 9:43 AM, Andres Freund and...@2ndquadrant.com
wrote:
If you do that, then, yes,
everything that you need to disentangle various network topologies
must be present in WAL. But what I'm saying is: don't do it
On 20 June 2012 21:42, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 20, 2012 at 9:25 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 20 June 2012 21:19, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs si...@2ndquadrant.com wrote:
The idea that
On Sun, Jun 17, 2012 at 9:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The trick for hashing such datatypes is to be able to guarantee that
equal values hash to the same hash code, which is typically possible
as long as you know the equality rules well enough. We could possibly
do that for text
On 20 June 2012 15:10, Greg Stark st...@mit.edu wrote:
On Sun, Jun 17, 2012 at 9:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The trick for hashing such datatypes is to be able to guarantee that
equal values hash to the same hash code, which is typically possible
as long as you know the equality
On Thu, Jun 14, 2012 at 11:41 AM, Alvaro Herrera
alvhe...@alvh.no-ip.org wrote:
Hi,
This is v12 of the foreign key locks patch.
Hi Álvaro,
Just noticed that this patch needs a rebase because of the refactoring
Tom did in ri_triggers.c
--
Jaime Casanova www.2ndQuadrant.com
On 20 June 2012 16:23, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 11:17, Simon Riggs wrote:
On 20 June 2012 15:45, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 10:32, Simon Riggs wrote:
On 20 June 2012 14:40, Heikki
On Wed, Jun 20, 2012 at 3:19 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
It occurs to me that strxfrm would answer this question. If we made
the hash function hash the result of strxfrm then we could make
equality use strcoll and not fall back to strcmp.
What about per-column collations?
Hi,
Any news on this issue? My slave server is not trusted, all the warnings below
are related to
indexes of the main tables:
2012-06-14 11:46:23 BRT [18654]: [34603-1] user=,db= LOG: recovery restart
point at 435/4E899CE8
2012-06-14 11:46:23 BRT [18654]: [34604-1] user=,db= DETAIL: last
Peter Geoghegan pe...@2ndquadrant.com writes:
I think that this change may have made the difference between the
Hungarians getting away with it and not getting away with it. Might it
have been that for text, they were using some operator that wasn't '='
(perhaps one which has no fastpath, and
Folks,
A co-worker filed a bug against file_fdw where the columns in a
FOREIGN TABLE were scrambled on SELECT. It turned out that this comes
from the (yes, it's documented, but since it's documented in a place
not obviously linked to the bug, it's pretty useless) feature of
COPY CSV HEADER
Excerpts from Florian Pflug's message of mié jun 20 06:35:29 -0400 2012:
On Jun19, 2012, at 17:36 , Robert Haas wrote:
On Mon, Jun 18, 2012 at 1:42 PM, Martijn van Oosterhout
klep...@svana.org wrote:
On Sun, Jun 17, 2012 at 12:29:53PM -0400, Tom Lane wrote:
The fly in the ointment with
Amit Kapila amit.kap...@huawei.com writes:
I'm almost inclined to suggest that we not get next-LSN from WAL, but
by scanning all the pages in the main data store and computing the max
observed LSN. This is clearly not very attractive from a performance
standpoint, but it would avoid the
Peter Eisentraut pete...@gmx.net writes:
On ons, 2012-06-20 at 13:26 +0200, Magnus Hagander wrote:
That might actually be a good idea. We can't really change the way we
named the betas, but it's not too late to consider naming the actual
release as 9.2.0...
The final release was always going
On tis, 2012-06-19 at 02:15 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
There might be something to the idea of demoting a few of the things
we've traditionally had as NOTICEs, though. IME, the following two
messages account for a huge percentage of the chatter:
Florian Pflug f...@phlo.org writes:
I wonder though if shouldn't restrict the allowed ciphers list to being
a simple list of supported ciphers. If our goal is to support multiple
SSL libraries transparently then surely having openssl-specific syntax
in the config file isn't exactly great
Simon Riggs si...@2ndquadrant.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Heikki Linnakangas wrote:
I don't like the idea of adding the origin id to the record
header. It's only required in some occasions, and on some record
types.
Right.
Wrong, as explained.
The
On Wed, Jun 20, 2012 at 10:02 AM, Andres Freund and...@2ndquadrant.com wrote:
Were not the only ones here that are performing scope creep though... I think
about all people who have posted in the whole thread except maybe Tom and
Marko are guilty of doing so.
I still think its rather sensible
On Jun20, 2012, at 17:34 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
I wonder though if shouldn't restrict the allowed ciphers list to being
a simple list of supported ciphers. If our goal is to support multiple
SSL libraries transparently then surely having openssl-specific syntax
David Fetter da...@fetter.org writes:
Rather than being totally ignored in the COPY OUT (CSV HEADER) case,
the header line in should be parsed to establish which columns are
where and rearranging the output if needed.
This is not fix a POLA violation. This is a non-backwards-compatible
new
On 06/20/2012 11:02 AM, David Fetter wrote:
Folks,
A co-worker filed a bug against file_fdw where the columns in a
FOREIGN TABLE were scrambled on SELECT. It turned out that this comes
from the (yes, it's documented, but since it's documented in a place
not obviously linked to the bug, it's
Alvaro Herrera alvhe...@commandprompt.com writes:
I looked at the code (apps/ciphers.c) and it looks pretty easy to obtain
the list of ciphers starting from the stringified configuration
parameter and iterate on them.
Do you mean that it will produce an expansion of the set of ciphers
meeting
On Wednesday, June 20, 2012 05:34:42 PM Kevin Grittner wrote:
Simon Riggs si...@2ndquadrant.com wrote:
This is not transaction metadata, it is WAL record metadata
required for multi-master replication, see later point.
We need to add information to every WAL record that is used as the
On Wed, Jun 20, 2012 at 10:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
But I think getting even
single-master logical replication working well in a single release
cycle is going to be a job and a half.
OK, so your estimate is 1.5 people to do that. And if we have more
people, should they
On 20 June 2012 15:55, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan pe...@2ndquadrant.com writes:
I think that this change may have made the difference between the
Hungarians getting away with it and not getting away with it. Might it
have been that for text, they were using some
On Wed, Jun 20, 2012 at 12:40 PM, Amit Kapila amit.kap...@huawei.com wrote:
I believe if WAL files are proper as mentioned in Alvaro's mail, the
purposed logic should generate
correct values.
Do you see any problem in logic purposed in my original mail.
Can I resume my work on this feature?
On Wed, Jun 20, 2012 at 11:47:14AM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Rather than being totally ignored in the COPY OUT (CSV HEADER)
case, the header line in should be parsed to establish which
columns are where and rearranging the output if needed.
This is not
David Fetter da...@fetter.org writes:
OK, new proposal:
COPY FROM (Thanks, Andrew! Must not post while asleep...) should have
an option which requires that HEADER be enabled and mandates that the
column names in the header match the columns coming in.
Has someone got a better name for this
---
Problem I'm trying to solve:
For partitioned tables, make it possible to use RETURNING clause on INSERT
INTO
together with DO INSTEAD rule
[ Note - wherever I say INSERT I also mean UPDATE and DELETE ]
---
Excerpts from Tom Lane's message of mié jun 20 11:49:51 -0400 2012:
Alvaro Herrera alvhe...@commandprompt.com writes:
I looked at the code (apps/ciphers.c) and it looks pretty easy to obtain
the list of ciphers starting from the stringified configuration
parameter and iterate on them.
Peter Geoghegan pe...@2ndquadrant.com writes:
No, I'm suggesting it would probably be at least a bit of a win here
to cache the constant, and only have to do a strxfrm() + strcmp() per
comparison.
Um, have you got any hard evidence to support that notion? The
traditional advice is that
On Wed, Jun 20, 2012 at 12:35 PM, Florian Pflug f...@phlo.org wrote:
On Jun19, 2012, at 17:36 , Robert Haas wrote:
On Mon, Jun 18, 2012 at 1:42 PM, Martijn van Oosterhout
klep...@svana.org wrote:
On Sun, Jun 17, 2012 at 12:29:53PM -0400, Tom Lane wrote:
The fly in the ointment with any of
On Wed, Jun 20, 2012 at 12:18:45PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
OK, new proposal:
COPY FROM (Thanks, Andrew! Must not post while asleep...) should have
an option which requires that HEADER be enabled and mandates that the
column names in the header match
Excerpts from David Fetter's message of mié jun 20 12:43:31 -0400 2012:
On Wed, Jun 20, 2012 at 12:18:45PM -0400, Tom Lane wrote:
In your original proposal, I was rather wondering what should happen
if the incoming file didn't have the same set of columns called out
in the COPY command's
Hi,
On Wednesday, June 20, 2012 05:44:09 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 10:02 AM, Andres Freund and...@2ndquadrant.com
wrote:
Were not the only ones here that are performing scope creep though... I
think about all people who have posted in the whole thread except maybe
Tom
Jaime Casanova ja...@2ndquadrant.com writes:
On Thu, Jun 14, 2012 at 11:41 AM, Alvaro Herrera
alvhe...@alvh.no-ip.org wrote:
This is v12 of the foreign key locks patch.
Just noticed that this patch needs a rebase because of the refactoring
Tom did in ri_triggers.c
Hold on a bit before you
On 06/20/2012 12:18 PM, Tom Lane wrote:
David Fetterda...@fetter.org writes:
OK, new proposal:
COPY FROM (Thanks, Andrew! Must not post while asleep...) should have
an option which requires that HEADER be enabled and mandates that the
column names in the header match the columns coming in.
On 06/20/2012 12:50 PM, Alvaro Herrera wrote:
Another related case: you have a file with headers and columns (n, t,
x, y, z) but your table only has n and t. How would you tell COPY to
discard the junk columns? Currently it just complains that they are
there.
That's one of the main use
On 20 June 2012 23:34, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Simon Riggs si...@2ndquadrant.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Heikki Linnakangas wrote:
I don't like the idea of adding the origin id to the record
header. It's only required in some
In the past people have asked me to have copy use the CSV header line in
place of supplying a column list in the COPY command. I can certainly
see some utility in that, and I think it might achieve what David wants.
Using that scenario it would be an error to supply an explicit column
list
On Wed, Jun 20, 2012 at 11:50 AM, Andres Freund and...@2ndquadrant.com wrote:
On Wednesday, June 20, 2012 05:34:42 PM Kevin Grittner wrote:
Simon Riggs si...@2ndquadrant.com wrote:
This is not transaction metadata, it is WAL record metadata
required for multi-master replication, see later
On Wed, Jun 20, 2012 at 12:53 PM, Andres Freund and...@2ndquadrant.com wrote:
I would prefer the event trigger way because that seems to be the most
extensible/reusable. It would allow a fully replicated databases and catalog
only instances.
I think we need to design event triggers in a way
On Wed, Jun 20, 2012 at 12:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The fact is that this is likely to be a fairly significant
performance win, because strxfrm() is quite simply the way you're
supposed to do collation-aware sorting, and is documented as such. For
that reason, C standard
-Ursprüngliche Nachricht-
Von: pgsql-hackers-ow...@postgresql.org im Auftrag von Josh Berkus
Gesendet: Mi 6/20/2012 7:06
An: pgsql-hackers@postgresql.org
Betreff: Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER
...
(1) is valuable
for backwards
On 20 June 2012 17:41, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan pe...@2ndquadrant.com writes:
No, I'm suggesting it would probably be at least a bit of a win here
to cache the constant, and only have to do a strxfrm() + strcmp() per
comparison.
Um, have you got any hard evidence to
4) MAP_HEADER ('column 1'- 'col_1', 'Date' - 'input_date' ...)
to cover the case when column names do not match.
Personally, I think that's going way beyond what we want to do with
COPY. At that point, check out the CSV-array FDW.
Of course, if someone writes a WIP patch which implements
On Wednesday, June 20, 2012 07:17:57 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 12:53 PM, Andres Freund and...@2ndquadrant.com
wrote:
I would prefer the event trigger way because that seems to be the most
extensible/reusable. It would allow a fully replicated databases and
catalog only
On Wed, Jun 20, 2012 at 3:48 AM, Simon Riggs si...@2ndquadrant.com wrote:
I'm sure Jeff submitted this because of the need for a standard test,
rather than the wish to actually modify pgbench itself.
Can I suggest that we include a list of standard scripts with pgbench
for this purpose? These
On Wed, Jun 20, 2012 at 8:19 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Jun 19, 2012 at 5:57 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 19, 2012 at 4:14 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Well, that was easier than I thought. Attached is
1 - 100 of 163 matches
Mail list logo
