On Fri, Mar 25, 2011 at 8:32 PM, Alexander Korotkov
wrote:
> I would like to ask you about currency of the work above.
This seems to be a mess of words. Sorry for my bad english. Actually,
I meant that I need a appraisal of my proposal.
With best regards,
Alexander Korotkov.
--
Sent via pg
On Mar 25, 2011, at 11:23 PM, Tom Lane wrote:
> If this were PL/perl, or PL/almost-anything-except-SQL, I could get
> behind such a proposal. But it's not, it's SQL; and SQL doesn't do
> things that way. SQL's idea of disambiguation is qualified names.
>
> And even more to the point: to the ext
Robert Haas writes:
> I think some discussion of which of the things on the open
> item lists need to be done before beta might be helpful, and we ought
> to add any items that are not there but are blockers.
Here's a quick enumeration of some things I think need discussion about
the collations p
Robert Haas wrote:
On Mar 25, 2011, at 9:22 PM, Joshua Berkus wrote:
Tom,
Personally I'd vote for *not* having any such dangerous semantics as
that. We should have learned better by now from plpgsql experience.
I think the best idea is to throw error for ambiguous references,
period.
As a l
Robert Haas writes:
> As I've said before, I believe that the root cause of this problem is
> that using the same syntax for variables and column names is a bad
> idea in the first place. If we used $foo or ?foo or ${foo} or $.foo
> or &&foo!!$#? to mean "the parameter called foo", then this woul
On Mar 25, 2011, at 9:12 PM, Robert Haas wrote:
>
> As I've said before, I believe that the root cause of this problem is
> that using the same syntax for variables and column names is a bad
> idea in the first place. If we used $foo or ?foo or ${foo} or $.foo
> or &&foo!!$#? to mean "the parame
Robert Haas writes:
> On Mar 25, 2011, at 9:22 PM, Joshua Berkus wrote:
>> Also, I don't understand why this would be a dump/reload issue if $1 and $2
>> continue to work.
> Because an identifier that previously referred unambiguously to a column
> might now be ambiguous, if there is a paramet
On Mar 25, 2011, at 9:22 PM, Joshua Berkus wrote:
> Tom,
>
>> Personally I'd vote for *not* having any such dangerous semantics as
>> that. We should have learned better by now from plpgsql experience.
>> I think the best idea is to throw error for ambiguous references,
>> period.
>
> As a like
On Fri, Mar 25, 2011 at 8:33 PM, Tom Lane wrote:
> The correct question is whether we're ready for beta, and I would say
> the answer is clearly no, unless you have a pretty low standard for what
> "ready for beta" means. Perhaps it would be suitable to discuss what
> the standard for that really
On Fri, Mar 25, 2011 at 6:18 PM, Simon Riggs wrote:
> I've never understood why we timebox useful development, yet tweaking
> is allowed to go on without limit. Personally, I don't see the
> rationale to allow developers some kind of priority over their input.
> This tweaking period is essentially
Dne 26.3.2011 02:05, Joshua Berkus napsal(a):
> Tomas,
>
>> I spoke to a teacher from a local university last week, mainly as we
>> were looking for a place where a local PUG could meet regularly. I
>> realized this could be a good opportunity to head-hunt some students
>> to
>> participate in thi
On Wed, Mar 23, 2011 at 6:33 AM, Heikki Linnakangas
wrote:
> On 16.03.2011 11:11, Fujii Masao wrote:
>>
>> On Wed, Mar 16, 2011 at 4:49 PM, Fujii Masao
>> wrote:
>>>
>>> Agreed. I'll change the patch.
>>
>> Done. I attached the updated patch.
>
> I don't much like the API for this. Walsender shou
Tom,
> Personally I'd vote for *not* having any such dangerous semantics as
> that. We should have learned better by now from plpgsql experience.
> I think the best idea is to throw error for ambiguous references,
> period.
As a likely heavy user of this feature, I agree with Tom here. I really
On Fri, Mar 25, 2011 at 8:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mar 25, 2011, at 7:45 PM, Tom Lane wrote:
>>> Well, maybe, but it's not like it's subtle or hard to fix.
>
>> Depends how much of it you have. I've become very skeptical of
>> anything that breaks pg_dump-and-reload-abi
I believe I've figured out why synchronous replication has such
terrible performance with fsync=off: it has a nasty race condition.
It may happen - if the standby responds very quickly - that the
standby acks the commit record and awakens waiters before the
committing backend actually begins to wai
Tomas,
> I spoke to a teacher from a local university last week, mainly as we
> were looking for a place where a local PUG could meet regularly. I
> realized this could be a good opportunity to head-hunt some students
> to
> participate in this GSoC. Are we still interested in new students?
Yes,
Robert Haas writes:
> On Mar 25, 2011, at 7:45 PM, Tom Lane wrote:
>> Well, maybe, but it's not like it's subtle or hard to fix.
> Depends how much of it you have. I've become very skeptical of
> anything that breaks pg_dump-and-reload-ability.
This wouldn't break pg_dump scripts, because they
Dne 8.3.2011 07:44, Selena Deckelmann napsal(a):
> Hi!
>
> PostgreSQL is applying for GSoC again this year. We're looking for:
>
> * Mentors
> * Project ideas
>
> Would you like to mentor? Please let me know! Our application closes
> on Friday, so please contact me *before* Friday.
>
> I've sta
On Mar 25, 2011, at 7:45 PM, Tom Lane wrote:
> Well, maybe, but it's not like it's subtle or hard to fix.
Depends how much of it you have. I've become very skeptical of anything that
breaks pg_dump-and-reload-ability. And doubly so now that such problems also
mean breaking pg_upgrade after the
Simon Riggs writes:
> Judging by the number of new threads about development for 9.2, I
> think its time we declared 9.1 Beta. I just had a conversation with
> some Debian developers about how PostgreSQL 9.0 got pulled out of
> their release because we delayed by 3 weeks. So we missed our slot to
On Thu, Mar 24, 2011 at 11:45 AM, Fujii Masao wrote:
> On Thu, Mar 24, 2011 at 3:22 AM, Robert Haas wrote:
>> On Wed, Mar 23, 2011 at 12:10 PM, Simon Riggs wrote:
Specifically, if we're not going to remove write location, then I
think we need to apply something like the attached.
>>>
>
On Thu, Mar 24, 2011 at 3:22 AM, Robert Haas wrote:
> On Wed, Mar 23, 2011 at 12:10 PM, Simon Riggs wrote:
>>> Specifically, if we're not going to remove write location, then I
>>> think we need to apply something like the attached.
>>
>> The protocol supports different write/fsync values, so the
On Wed, Mar 23, 2011 at 6:22 PM, Robert Haas wrote:
> On Wed, Mar 23, 2011 at 12:10 PM, Simon Riggs wrote:
>>> Specifically, if we're not going to remove write location, then I
>>> think we need to apply something like the attached.
>>
>> The protocol supports different write/fsync values, so the
Robert Haas writes:
> On Mar 25, 2011, at 4:20 PM, Tom Lane wrote:
>> But I don't think that's necessary. Up to now there's been relatively
>> little use for naming the parameters of SQL functions, so I think there
>> will be few conflicts in the field if we just change the behavior.
> Oh wow,
On Mar 25, 2011, at 4:20 PM, Tom Lane wrote:
> GUCs are not tremendously helpful for problems such as this. If we
> actually wanted to preserve full backwards compatibility, we'd need to
> think of a way to mark SQL functions per-function as to what to do.
> But I don't think that's necessary. U
Stefan Huehner writes:
> first i am not sure how the state of the collation work in current git is
> supposed to be with all the discussion going on here... but wanted to get out
> that bug report:
> create table ad_tab (ad_tab_id varchar(32), name varchar(32));
> create function test_trg() R
Judging by the number of new threads about development for 9.2, I
think its time we declared 9.1 Beta. I just had a conversation with
some Debian developers about how PostgreSQL 9.0 got pulled out of
their release because we delayed by 3 weeks. So we missed our slot to
deliver useful new features t
Tom Lane wrote:
Stephen Frost writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Well, basically, you can't have that. Example: you have an existing
table with primary key, and while you're in the middle of doing some
long transaction, somebody else creates a table with a foreign-key
reference to
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Well, basically, you can't have that. Example: you have an existing
>> table with primary key, and while you're in the middle of doing some
>> long transaction, somebody else creates a table with a foreign-key
>> reference to the o
On Fri, Mar 25, 2011 at 08:46:17AM +, Gianni Ciolli wrote:
> On Sun, Mar 20, 2011 at 08:14:21PM -0400, Noah Misch wrote:
> > Agreed. The documentation is suggestive of this limit:
> >
> > # CREATE TABLE n (c numeric(1001,0));
> > ERROR: NUMERIC precision 1001 must be between 1 and 1000
> > L
2011/3/25 Tom Lane :
> Pavel Stehule writes:
>> 2011/3/25 Tom Lane :
>>> I think the best idea is to throw error for ambiguous references,
>>> period.
>
>> There can be GUC for controlling use or don't use a parameter names. I
>> am for GUC, because there will be a bilion conflicts. But a talk abo
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Well, basically, you can't have that. Example: you have an existing
> table with primary key, and while you're in the middle of doing some
> long transaction, somebody else creates a table with a foreign-key
> reference to the one you're about to do a delet
hi,
So, I hit a strange problem with Streaming Replication, that I cannot explain.
Executive summary:
when using hot backup made on straming replication slave, sometimes
(depending on load) generated backup is created in such a way, that while it
can be brough back as standalone Pg, and it can b
On 25.03.2011 22:21, Robert Haas wrote:
On Fri, Mar 25, 2011 at 3:29 PM, Greg Stark wrote:
On Fri, Mar 25, 2011 at 7:06 PM, Robert Haas wrote:
1. The table has been created or truncated in the same transaction
,,,
That's not enough... some other transaction could see the data before
the tran
On Fri, Mar 25, 2011 at 4:06 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 18, 2011 at 5:57 PM, Kevin Grittner
>> wrote:
I'm still looking at whether it's sane to try to issue a warning
when an HTAB exceeds the number of entries declared as its
max_size when it was crea
On Fri, Mar 25, 2011 at 3:29 PM, Greg Stark wrote:
> On Fri, Mar 25, 2011 at 7:06 PM, Robert Haas wrote:
>>> 1. The table has been created or truncated in the same transaction
>>,,,
>> That's not enough... some other transaction could see the data before
>> the transaction commits.
>
> How?
Hmm.
Pavel Stehule writes:
> 2011/3/25 Tom Lane :
>> I think the best idea is to throw error for ambiguous references,
>> period.
> There can be GUC for controlling use or don't use a parameter names. I
> am for GUC, because there will be a bilion conflicts. But a talk about
> priorities - sql identif
On Fri, Mar 25, 2011 at 3:32 PM, Heikki Linnakangas
wrote:
> On 25.03.2011 16:52, Merlin Moncure wrote:
>>
>> Without this bit, the only way to set hint bits going during bufmgr
>> eviction is to do a visibility check on every tuple, which would
>> probably be prohibitively expensive.
>
> I don't
2011/3/25 Tom Lane :
> Matthew Draper writes:
>> Attached is a WIP patch that allows SQL-language functions to reference
>> their parameters by name.
>
>> It uses p_post_columnref_hook, so potentially ambiguous references
>> prefer the column... that seems to make the most sense, both because it
>
Robert Haas writes:
> On Fri, Mar 18, 2011 at 5:57 PM, Kevin Grittner
> wrote:
>>> I'm still looking at whether it's sane to try to issue a warning
>>> when an HTAB exceeds the number of entries declared as its
>>> max_size when it was created.
> I don't think it's too late to commit something l
Vaibhav Kaushal writes:
> So, I think that the function ExecSetParamPlan (as the code suggests
> too) is called _once_ in any plan/expression and that should be mostly
> for a sub-select query.
> Kindly correct me if I am wrong. Since I am not able to understand this
> usecase completely, a samp
Matthew Draper writes:
> Attached is a WIP patch that allows SQL-language functions to reference
> their parameters by name.
> It uses p_post_columnref_hook, so potentially ambiguous references
> prefer the column... that seems to make the most sense, both because it
> avoids a backwards incompat
On Fri, Mar 25, 2011 at 2:32 PM, Heikki Linnakangas
wrote:
> On 25.03.2011 16:52, Merlin Moncure wrote:
>>
>> Without this bit, the only way to set hint bits going during bufmgr
>> eviction is to do a visibility check on every tuple, which would
>> probably be prohibitively expensive.
>
> I don't
Attached is a WIP patch that allows SQL-language functions to reference
their parameters by name.
It uses p_post_columnref_hook, so potentially ambiguous references
prefer the column... that seems to make the most sense, both because it
avoids a backwards incompatibility, and it conforms with SQL
On 25.03.2011 16:52, Merlin Moncure wrote:
Without this bit, the only way to set hint bits going during bufmgr
eviction is to do a visibility check on every tuple, which would
probably be prohibitively expensive.
I don't think the naive approach of scanning all tuples would be too
bad, actuall
On Fri, Mar 25, 2011 at 7:06 PM, Robert Haas wrote:
>> 1. The table has been created or truncated in the same transaction
>,,,
> That's not enough... some other transaction could see the data before
> the transaction commits.
How?
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Fri, Mar 18, 2011 at 4:51 PM, Kevin Grittner
wrote:
> Dan Ports wrote:
>
>> I am surprised to see that error message without SSI's hint about
>> increasing max_predicate_locks_per_xact.
>
> After reviewing this, I think something along the following lines
> might be needed, for a start. I'm n
On Fri, Mar 18, 2011 at 5:57 PM, Kevin Grittner
wrote:
> "Kevin Grittner" wrote:
>
>> I'm still looking at whether it's sane to try to issue a warning
>> when an HTAB exceeds the number of entries declared as its
>> max_size when it was created.
>
> I think this does it.
>
> If nothing else, it m
Thanks for the reply Mr. Tom.
So, I think that the function ExecSetParamPlan (as the code suggests
too) is called _once_ in any plan/expression and that should be mostly
for a sub-select query.
Kindly correct me if I am wrong. Since I am not able to understand this
usecase completely, a sample
On Fri, Mar 25, 2011 at 4:00 AM, Heikki Linnakangas
wrote:
> On 25.03.2011 09:51, Heikki Linnakangas wrote:
>>
>> I don't think we should put the onus on the user to choose the right
>> data loading mode. If we can reliably detect the cases where it's safe
>> do these tricks, we can transparently
Stephen Frost writes:
> Sorry, that obviously didn't come across clearly (I think I've just been
> talking to Kevin far too much).
> I'm not interested in making them serializable. I'd like to not have
> tables randomly appear during a serializable transaction.
Well, basically, you can't have t
Vaibhav Kaushal writes:
> Hello all,
> I was going through the Expression Evaluator and was trying to
> understand how the expressions are formed and evaluated. I was informed
> on the IRC channel that the PARAM nodes are quite important and many
> well written client applications use PARAMs for
On Mar 25, 2011, at 11:58 AM, Jim Nasby wrote:
> Related to that... after talking to Greg Smith at PGEast last night, he felt
> it would be very valuable just to profile how much time is being spent
> waiting/holding the freelist lock in a real environment. I'm going to see if
> we can do that
* Joshua Berkus (j...@agliodbs.com) wrote:
> That seemed unnecessary. Whether or not you approve of Stephen's solution,
> he is dealing with a real issue.
The solution felt, to me at least, to have a lot of parallel to an
index's indcheckxmin. We've dealt with this issue there and have a
preced
> Making DDL serializable is *not* simple, and half-baked hacks won't
> make that situation better ...
That seemed unnecessary. Whether or not you approve of Stephen's solution, he
is dealing with a real issue.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco
--
Sen
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Making DDL serializable is *not* simple, and half-baked hacks won't
> make that situation better ...
Sorry, that obviously didn't come across clearly (I think I've just been
talking to Kevin far too much).
I'm not interested in making them serializable. I
Hackers,
I would like to ask you about currency of the work above. I propose to
develop functionality of GIN and GiST q-gram indexes with following
features:
1) Handle edit distance (e.g. levenshtein distance) and LIKE/ILIKE
queries(using GIN partial match if no full q-grams can be extracted
from
On Fri, Mar 25, 2011 at 10:34 AM, Jim Nasby wrote:
> On Mar 25, 2011, at 9:52 AM, Merlin Moncure wrote:
>> Without this bit, the only way to set hint bits going during bufmgr
>> eviction is to do a visibility check on every tuple, which would
>> probably be prohibitively expensive. Since OLTP env
Hello all,
I was going through the Expression Evaluator and was trying to
understand how the expressions are formed and evaluated. I was informed
on the IRC channel that the PARAM nodes are quite important and many
well written client applications use PARAMs for sending query to the
backend. I fo
On Thu, Mar 24, 2011 at 7:51 PM, Greg Stark wrote:
> On Thu, Mar 24, 2011 at 11:33 PM, Jeff Janes wrote:
>> I tried under the circumstances I thought were mostly likely to show a
>> time difference, and I was unable to detect a reliable difference in
>> timing between free list and clock sweep.
>
Excerpts from aaronenabs's message of vie mar 25 10:43:49 -0300 2011:
> Hi All
>
> I am trying to write a pg_filedump to read dead rows in pgsql, I am
> relatively new to postgresql and have been trying to find out how to write
> and compile a pg_filedump to help display dead rows. Please can anyo
2011/3/25 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of vie mar 25 02:48:49 -0300 2011:
>> 2011/3/24 Robert Haas :
>> > On Wed, Mar 23, 2011 at 4:50 PM, Pavel Stehule
>> > wrote:
>
>> >> can we enhance a detail for table and show more accurate numbers?
>> >>
>> >> table size: xxx
>>
On Mar 25, 2011, at 10:07 AM, Gurjeet Singh wrote:
> On Tue, Mar 22, 2011 at 3:53 PM, Robert Haas wrote:
> On Tue, Mar 22, 2011 at 11:24 AM, Jeff Janes wrote:
> > On Fri, Mar 18, 2011 at 9:19 AM, Robert Haas wrote:
> >> On Fri, Mar 18, 2011 at 11:14 AM, Kevin Grittner
> >> wrote:
> >>> Maybe th
Excerpts from Pavel Stehule's message of vie mar 25 02:48:49 -0300 2011:
> 2011/3/24 Robert Haas :
> > On Wed, Mar 23, 2011 at 4:50 PM, Pavel Stehule
> > wrote:
> >> can we enhance a detail for table and show more accurate numbers?
> >>
> >> table size: xxx
> >> toast size: xxx
> >> indexes size
Stephen Frost writes:
> I don't believe fixing this would be terribly difficult and, I
> believe, would be similar to what we've done else where (eg: with
> indexes)- basically, add a column to pg_class with the 'createdxmin'
> and then compare that against our transaction whenever we're d
On Mar 24, 2011, at 4:42 PM, Greg Stark wrote:
> On Thu, Mar 24, 2011 at 9:39 PM, Greg Stark wrote:
>>
>> We could conceivably deal with that by not setting the frozenxid but
>> setting the hint bit for those tuples and having a documented special
>> case that if the hint bit is set but it's the
Greetings,
We have a curious situation, consider this:
Process 1:
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
CRETE TABLE table1 (i integer);
INSERT INTO table1 VALUES (13);
Process 2:
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
CREATE TABLE table2 (
On Mar 25, 2011, at 9:52 AM, Merlin Moncure wrote:
> Without this bit, the only way to set hint bits going during bufmgr
> eviction is to do a visibility check on every tuple, which would
> probably be prohibitively expensive. Since OLTP environments would
> rarely see this bit, they would not hav
On Fri, Mar 25, 2011 at 5:03 AM, Fujii Masao wrote:
> On Fri, Mar 25, 2011 at 6:11 AM, Robert Haas wrote:
>> On Thu, Mar 24, 2011 at 2:28 PM, Simon Riggs wrote:
>>> The protocol supports sending two values, so two are displayed.
>>>
>>> If you wish to remove one from the display then that only m
Maybe I'm being overly simplistic or incorrect here, but I was
thinking that there might be a route to reducing hint bit impact to
the main sufferers of the feature without adding too much pain in the
general case. I'm unfortunately convinced there is no getting rid of
them -- in fact their utilit
hi,
> YAMAMOTO Takashi wrote:
>
>> thanks for quickly fixing problems.
>
> Thanks for the rigorous testing. :-)
>
>> i tested the later version
>> (a2eb9e0c08ee73208b5419f5a53a6eba55809b92) and only errors i got
>> was "out of shared memory". i'm not sure if it was caused by SSI
>> activi
On Thu, Mar 24, 2011 at 23:47, Stephen Frost wrote:
> I'd be happy with a "data loading mode" that even disallowed
> subtransactions if necessary to achieve the write-once (well, plus WAL
> if you're archiving) operation...
Note that there's already an extension on pgFoundry for a "data
loading m
On Tue, Mar 22, 2011 at 3:53 PM, Robert Haas wrote:
> On Tue, Mar 22, 2011 at 11:24 AM, Jeff Janes wrote:
> > On Fri, Mar 18, 2011 at 9:19 AM, Robert Haas
> wrote:
> >> On Fri, Mar 18, 2011 at 11:14 AM, Kevin Grittner
> >> wrote:
> >>> Maybe the thing to focus on first is the oft-discussed "be
Hi All
I am trying to write a pg_filedump to read dead rows in pgsql, I am
relatively new to postgresql and have been trying to find out how to write
and compile a pg_filedump to help display dead rows. Please can anyone help
me
i) Explain how i can write a pg_filedump to display dead rows or ho
Hi All
I am trying to write a pg_filedump to read dead rows in pgsql, I am
relatively new to postgresql and have been trying to find out how to write
and compile a pg_filedump to help display dead rows. Please can anyone help
me
i) Explain how i can write a pg_filedump to display dead rows or ho
On Sat, Mar 19, 2011 at 4:29 AM, Simon Riggs wrote:
> On Fri, 2011-03-18 at 20:19 +0100, Markus Wanner wrote:
>> Simon,
>>
>> On 03/18/2011 05:19 PM, Simon Riggs wrote:
>> >>> Simon Riggs wrote:
>> In PostgreSQL other users cannot observe the commit until an
>> acknowledgement has been
On Mar 24, 2011, at 9:00 PM, Daniel Farina wrote:
> * Offline WAL application -- I want to be able to bring up a second
> server, perform some amount of point in time recovery, and then stop
> and archive. It would be nice to support read-only queries in this
> case to test the recovered database
On Sat, Mar 19, 2011 at 12:07 AM, Robert Haas wrote:
> On Fri, Mar 18, 2011 at 10:55 AM, Greg Stark wrote:
>> On Thu, Mar 17, 2011 at 5:46 PM, Robert Haas wrote:
>>> What makes more sense to me after having thought about this more
>>> carefully is to simply make a blanket rule that when
>>> sync
* Greg Stark (gsst...@mit.edu) wrote:
> You could have a single global boolean variable to indicate whether
> any tables have been created in this transaction and inserted into
> using this frozenxid hack in this transaction yet.
This was exactly where I was going, and, honestly, I was wondering i
On Fri, Mar 25, 2011 at 8:09 AM, Heikki Linnakangas
wrote:
> The tricky part here is how to check if the table was created in the same
> transaction, within HeapTupleSatisfiesMVCC, with minimal overhead. If you do
> it naively, the check will be executed at every single tuple read in the
> system.
2011/3/24 Jim Nasby :
> On Mar 22, 2011, at 11:46 AM, Cédric Villemain wrote:
>> 2011/3/22 Greg Stark :
>>> On Mon, Mar 21, 2011 at 6:08 PM, Jim Nasby wrote:
Has anyone looked at the overhead of measuring how long IO requests to the
kernel take? If we did that not only could we get an i
On Fri, Mar 25, 2011 at 6:11 AM, Robert Haas wrote:
> On Thu, Mar 24, 2011 at 2:28 PM, Simon Riggs wrote:
>> The protocol supports sending two values, so two are displayed.
>>
>> If you wish to remove one from the display then that only makes sense
>> if you also prevent the protocol from support
On Sun, Mar 20, 2011 at 08:14:21PM -0400, Noah Misch wrote:
> On Fri, Mar 11, 2011 at 11:36:14AM +, Gianni Ciolli wrote:
> > maybe we should change the "1000 digits" here:
> >
> >
> > http://developer.postgresql.org/pgdocs/postgres/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL
> >
> > bec
On 25.03.2011 00:15, Stephen Frost wrote:
At the start of a load, we check if the table was created in the current
transaction. If so, we check if we've already done a load which used
the frozen XID. If we have, then we use the normal mechanics. If we
havn't, then we stuff what the XID would h
On Fri, Mar 25, 2011 at 1:00 AM, Heikki Linnakangas
wrote:
> 1. The table has been created or truncated in the same transaction
> 2. We are not in a subtransaction (or the table was created and truncated in
> the same subtransaction)
> 3. There are no open portals
> 4. Executing the COPY doesn't n
On 25.03.2011 09:51, Heikki Linnakangas wrote:
I don't think we should put the onus on the user to choose the right
data loading mode. If we can reliably detect the cases where it's safe
do these tricks, we can transparently apply them when possible. I would
be cool with tricks that apply only in
On Fri, Mar 25, 2011 at 12:38 AM, Heikki Linnakangas
wrote:
> On 25.03.2011 03:00, Daniel Farina wrote:
>>
>> Here is the mechanism: I want to author a recovery.conf to perform
>> some amount of restore_command or streaming replication based
>> recovery, but I do *not* want to generate a new time
On 24.03.2011 23:54, Stephen Frost wrote:
* Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
The problem is that you still need to track which queries within the
transaction can see the tuples. For example:
Wow, that's a good point wrt cursors. Sounds more and more like we'd
ne
On 25.03.2011 03:00, Daniel Farina wrote:
Here is the mechanism: I want to author a recovery.conf to perform
some amount of restore_command or streaming replication based
recovery, but I do *not* want to generate a new timeline. Rather, I
want to stay in hot standby mode to allow read-only conn
89 matches
Mail list logo
