On 20 June 2012 14:40, Heikki Linnakangas
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 generates a new WAL record.
> 3. N
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 description
On 20 June 2012 15:32, Heikki Linnakangas
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 options, which mostly just giv
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
var
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
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 mechanism, and has nev
On 20.06.2012 11:17, Simon Riggs wrote:
On 20 June 2012 15:45, Heikki Linnakangas
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 mecha
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 "v9.2.0b
On 20 June 2012 16:23, Heikki Linnakangas
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? Multi-master replication is what is
On 20.06.2012 11:34, Simon Riggs wrote:
On 20 June 2012 16:23, Heikki Linnakangas
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.
Hu
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
wrote:
> > On Tue, Jun 19, 2012 at 5:46 PM, Robert Haas
wrote:
> >>> Btw, what do you mean with "conflating" the stream? I don't really see
> >>> that being proposed.
> >>
> >> It s
On Wed, Jun 20, 2012 at 10:28 AM, Marti Raudsepp 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:
> http://ftp.postgresql.org/pub/source/v$VER
On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander 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 versioning scheme
On 20 June 2012 16:44, Heikki Linnakangas
wrote:
> On 20.06.2012 11:34, Simon Riggs wrote:
>>
>> On 20 June 2012 16:23, Heikki Linnakangas
>> 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.
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 co
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
wrote:
> >> Well, the words are fuzzy, but I would define logical replication to
> >> be something which is independent of the binary format in which stuff
> >> gets sto
On Tue, Jun 19, 2012 at 8:06 PM, Robert Haas wrote:
> On Tue, Jun 19, 2012 at 10:56 PM, Jeff Janes 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 haven't yet sorted that out.
>
> It
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
> S
On 20 June 2012 11:00, Peter Eisentraut 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 corre
On Jun19, 2012, at 17:36 , Robert Haas wrote:
> On Mon, Jun 18, 2012 at 1:42 PM, Martijn van Oosterhout
> 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 names, as
On Wednesday, June 20, 2012 05:01:16 AM Robert Haas wrote:
> On Tue, Jun 19, 2012 at 4:22 PM, Andres Freund
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 have a hard
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 another
On Mon, Jun 11, 2012 at 6:06 PM, Fujii Masao wrote:
> On Tue, Jun 12, 2012 at 12:47 AM, Magnus Hagander wrote:
>> On Mon, Jun 11, 2012 at 5:37 PM, Fujii Masao wrote:
>>> On Mon, Jun 11, 2012 at 3:24 AM, Magnus Hagander
>>> wrote:
On Sun, Jun 10, 2012 at 6:08 PM, Fujii Masao wrote:
>
On Tue, Jun 19, 2012 at 5:57 PM, Robert Haas wrote:
> On Tue, Jun 19, 2012 at 4:14 AM, Heikki Linnakangas
> 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. I think we should go ahead
>> with this.
>
> +1.
>
On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp wrote:
> On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander 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)
>
>
2012/6/20 Magnus Hagander :
> On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp wrote:
>> On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander
>> 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 inc
On 11 June 2012 23:47, Magnus Hagander 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 explicitly igno
On ons, 2012-06-20 at 13:26 +0200, Magnus Hagander wrote:
> On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp wrote:
> > On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander
> > wrote:
> >> (I do believe that using the v9.2.0beta marker is
> >> *better*, because then it sorts properly. But likely no
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 descr
On 19 June 2012 19:44, Peter Geoghegan 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 that there is no tie
> 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 rec
On Wed, Jun 20, 2012 at 6:59 AM, Andres Freund 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. Catcache, autovac
On Wed, Jun 20, 2012 at 5:15 AM, Andres Freund 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* that it can be
> shippe
On Wednesday, June 20, 2012 02:51:30 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 6:59 AM, Andres Freund
wrote:
> >> Also, the performance-critical things
> >> could be reimplemented as macros.
> >>
> >> I question, though, whether we really need both single and doubly linked
> >> lists. Tha
On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs 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 implementing multi-maste
On Wednesday, June 20, 2012 03:19:55 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs 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
> 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 r
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 10064
On Wed, Jun 20, 2012 at 9:12 AM, Andres Freund 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 widespread usage of
> si
On 20 June 2012 21:19, Robert Haas wrote:
> On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs 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
On Wednesday, June 20, 2012 03:24:58 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 9:12 AM, Andres Freund
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
On Wed, Jun 20, 2012 at 9:21 AM, Amit Kapila 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 100s of GB of data
i
On Wed, Jun 20, 2012 at 9:25 AM, Simon Riggs wrote:
> On 20 June 2012 21:19, Robert Haas wrote:
>> On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs 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
>>> c
On Wednesday, June 20, 2012 03:02:28 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 5:15 AM, Andres Freund
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 some of that be
On 20 June 2012 20:37, Kevin Grittner 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 even be enough in
-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
> th
On Wed, Jun 20, 2012 at 9:43 AM, Andres Freund 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, and then pass
>>
On Wednesday, June 20, 2012 03:42:39 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 9:25 AM, Simon Riggs wrote:
> > On 20 June 2012 21:19, Robert Haas wrote:
> >> On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs
wrote:
> >>> The idea that logical rep is some kind of useful end goal in itself is
>
On Wednesday, June 20, 2012 03:54:43 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 9:43 AM, Andres Freund
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
> >> th
On 20 June 2012 21:42, Robert Haas wrote:
> On Wed, Jun 20, 2012 at 9:25 AM, Simon Riggs wrote:
>> On 20 June 2012 21:19, Robert Haas wrote:
>>> On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs wrote:
The idea that logical rep is some kind of useful end goal in itself is
slightly misleadi
On Sun, Jun 17, 2012 at 9:26 PM, Tom Lane 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 with pure-str
On 20 June 2012 15:10, Greg Stark wrote:
> On Sun, Jun 17, 2012 at 9:26 PM, Tom Lane 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
On Thu, Jun 14, 2012 at 11:41 AM, Alvaro Herrera
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
Professional PostgreSQL: Sopo
On 20 June 2012 16:23, Heikki Linnakangas
wrote:
> On 20.06.2012 11:17, Simon Riggs wrote:
>>
>> On 20 June 2012 15:45, Heikki Linnakangas
>> wrote:
>>>
>>> On 20.06.2012 10:32, Simon Riggs wrote:
On 20 June 2012 14:40, Heikki Linnakangas
>
>
> And I'm worried
> it
On Wed, Jun 20, 2012 at 3:19 PM, Peter Geoghegan 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?
Well collati
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
comple
Peter Geoghegan 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 thus correctly mad
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 wher
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
> > wrote:
> >> On Sun, Jun 17, 2012 at 12:29:53PM -0400, Tom Lane wrote:
> >>> The fly in the ointment with any of
Amit Kapila 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 obvious failure mode
Peter Eisentraut 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 to be c
On tis, 2012-06-19 at 02:15 -0400, Tom Lane wrote:
> Robert Haas 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:
>
> > NOTICE: CREAT
Florian Pflug 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 anyway...
No,
Simon Riggs wrote:
> Kevin Grittner 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 point is not wrong; you are sim
On Wed, Jun 20, 2012 at 10:02 AM, Andres Freund 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 to focus on exact
On Jun20, 2012, at 17:34 , Tom Lane wrote:
> Florian Pflug 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 th
David Fetter 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 feature, which
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 p
Alvaro Herrera 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 criteria like "!aNULL"?
On Wednesday, June 20, 2012 05:34:42 PM Kevin Grittner wrote:
> Simon Riggs 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
> > source for gene
On Wed, Jun 20, 2012 at 10:08 AM, Simon Riggs 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 wrote:
> Peter Geoghegan 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
On Wed, Jun 20, 2012 at 12:40 PM, Amit Kapila 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?
>
>> Maybe
On Wed, Jun 20, 2012 at 11:47:14AM -0400, Tom Lane wrote:
> David Fetter 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 P
David Fetter 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 option than
---
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 ]
---
Cu
Excerpts from Tom Lane's message of mié jun 20 11:49:51 -0400 2012:
>
> Alvaro Herrera 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
Peter Geoghegan 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 strcoll is faster than us
On Wed, Jun 20, 2012 at 12:35 PM, Florian Pflug wrote:
> On Jun19, 2012, at 17:36 , Robert Haas wrote:
>> On Mon, Jun 18, 2012 at 1:42 PM, Martijn van Oosterhout
>> 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 th
On Wed, Jun 20, 2012 at 12:18:45PM -0400, Tom Lane wrote:
> David Fetter 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 co
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 comm
Hi,
On Wednesday, June 20, 2012 05:44:09 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 10:02 AM, Andres Freund
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 gu
Jaime Casanova writes:
> On Thu, Jun 14, 2012 at 11:41 AM, Alvaro Herrera
> 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 work on that code --- I've got one more
On 06/20/2012 12:18 PM, Tom Lane wrote:
David Fetter 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
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 ca
On 20 June 2012 23:34, Kevin Grittner wrote:
> Simon Riggs wrote:
>> Kevin Grittner 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.
>>
>> W
> 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
> li
On Wed, Jun 20, 2012 at 11:50 AM, Andres Freund wrote:
> On Wednesday, June 20, 2012 05:34:42 PM Kevin Grittner wrote:
>> Simon Riggs wrote:
>> > This is not transaction metadata, it is WAL record metadata
>> > required for multi-master replication, see later point.
>
>> > We need to add informat
On Wed, Jun 20, 2012 at 12:53 PM, Andres Freund 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 you cannot simply cir
On Wed, Jun 20, 2012 at 12:41 PM, Tom Lane 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 library implemen
> -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 com
On 20 June 2012 17:41, Tom Lane wrote:
> Peter Geoghegan 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
> tr
>
> 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 imple
On Wednesday, June 20, 2012 07:17:57 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 12:53 PM, Andres Freund
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
On Wed, Jun 20, 2012 at 3:48 AM, Simon Riggs 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 can then be copi
On Wed, Jun 20, 2012 at 8:19 PM, Magnus Hagander wrote:
> On Tue, Jun 19, 2012 at 5:57 PM, Robert Haas wrote:
>> On Tue, Jun 19, 2012 at 4:14 AM, Heikki Linnakangas
>> wrote:
>>> Well, that was easier than I thought. Attached is a patch to make XLogRecPtr
>>> a uint64, on top of my other WAL for
On 20 June 2012 23:56, Robert Haas wrote:
> On Wed, Jun 20, 2012 at 10:08 AM, Simon Riggs 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
On Wed, Jun 20, 2012 at 1:40 PM, Andres Freund wrote:
>> I realized a problem with that idea this morning: it might work for
>> reading things, but if anyone attempts to write data you've got big
>> problems. Maybe we could get away with forbidding that, not sure.
> Hm, why is writing a problem?
On 21 June 2012 01:40, Andres Freund wrote:
>> I think extraction is a very sensible place to start; actually, I
>> think it's the best possible place to start. But this particular
>> thread is about adding origin_ids to WAL, which I think is definitely
>> not the best place to start.
> Yep. I
1 - 100 of 160 matches
Mail list logo
