On Mon, Apr 6, 2015 at 10:01 PM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>> On Mon, Apr 6, 2015 at 5:33 PM, Michael Paquier
>> wrote:
>> > On Mon, Apr 6, 2015 at 1:41 PM, Michael Paquier wrote:
>> >> I guess that you are working on a patch? If not, you are looking for one?
>> >
>> > Code-speak
On Tue, Apr 7, 2015 at 11:59 AM, Michael Paquier
wrote:
> On Mon, Apr 6, 2015 at 9:10 PM, Fujii Masao wrote:
>> I'm not familiar with native language support (sorry), but don't we need to
>> add the shortcut of gettext into every calls of pg_log and pg_fatal, e.g.,
>> change pg_fatal("xxx") to pg
On Tue, Apr 7, 2015 at 4:16 PM, Fujii Masao wrote:
> On Mon, Apr 6, 2015 at 10:01 PM, Alvaro Herrera
> wrote:
>> Fujii Masao wrote:
>>> On Mon, Apr 6, 2015 at 5:33 PM, Michael Paquier
>>> wrote:
>>> > On Mon, Apr 6, 2015 at 1:41 PM, Michael Paquier wrote:
>>> >> I guess that you are working on a
On Tue, Apr 7, 2015 at 4:33 PM, Fujii Masao wrote:
> Isn't the term "PostgreSQL superuser" confusing? I'm afraid that a user might
> confuse "PostgreSQL superuser" with a database superuser. I see you just
> borrowed that term from pg_resetxlog.c, though. BTW, initdb and pg_ctl also
> have the same
On 11 February 2015 at 08:51, Heikki Linnakangas
wrote:
>
>
> The new xmin tracking code assumes that if a snapshots's regd_count > 0,
> it has already been pushed to the RegisteredSnapshots heap. That assumption
> doesn't hold because the logical decoding stuff creates its own snapshots
> and set
On Tue, Apr 7, 2015 at 9:32 AM, Fabrízio de Royes Mello
wrote:
>
> On Mon, Apr 6, 2015 at 10:21 AM, Sawada Masahiko
> wrote:
>>
>> On Fri, Mar 13, 2015 at 5:10 PM, Kyotaro HORIGUCHI
>> wrote:
>> > Hello, I have some trivial comments about the latest patch.
>> >
>> > At Thu, 12 Mar 2015 21:15:14
The attached patch adds a 'pid' column to pg_replication_slots, so it's
possible to associate an active slot with the pg_stat_replication entry
that describes the walsender using the slot.
If a user backend (or bgworker) is using the slot over the SQL interface,
the 'pid' column will correspond to
When attempting to insert a row that violates a row security policy that
applies to writes, the error message emitted references WITH CHECK OPTION,
even though (as far as the user knows) there's no such thing involved.
If you understand the internals you'd know that row security re-uses the
same lo
On 2015-04-07 17:22:12 +0800, Craig Ringer wrote:
> It might be a good idea to apply this if nothing better is forthcoming.
> Logical decoding in WALsenders is broken at the moment.
Yes.
> Otherwise it needs to go on the 9.5 blockers list.
>
> But could we get rid of those active_count manipulat
Hi,
On 2015-04-07 18:41:59 +0800, Craig Ringer wrote:
> The attached patch adds a 'pid' column to pg_replication_slots, so it's
> possible to associate an active slot with the pg_stat_replication entry
> that describes the walsender using the slot.
This really should have been done that way from
On Tue, Apr 7, 2015 at 7:22 AM, Sawada Masahiko
wrote:
>
> Thank you for your reviewing.
> I modified the patch and attached latest version patch(v7).
> Please have a look it.
>
Looks good to me. Attached patch (v8) just fix a tab indentation in gram.y.
Regards,
--
Fabrízio de Royes Mello
Consu
On Sun, Apr 5, 2015 at 12:16 PM, Tom Lane wrote:
> A newbie error that we see *constantly* is misunderstanding identifier
> case-folding rules. ISTM that commit e529cd4ff missed a chance to help
> with that. You do get a hint for this:
>
> regression=# create table t1 (foo int, "Bar" int);
> CRE
On 7 Apr 2015 09:37, "Robert Haas" wrote:
>
> On Sun, Apr 5, 2015 at 12:16 PM, Tom Lane wrote:
> > A newbie error that we see *constantly* is misunderstanding identifier
> > case-folding rules.
> > I think this hint might be a lot more useful if its comparison mechanism
> > were case-insensitive
On 2015-03-28 23:50:20 +0100, Petr Jelinek wrote:
> And finally I have issue with how the new identifiers are allocated.
> Currently, if you create identifier 'foo', remove identifier 'foo' and
> create identifier 'bar', the identifier 'bar' will have same id as the old
> 'foo' identifier. This can
On 2015-04-07 16:30:25 +0200, Andres Freund wrote:
> And with temp tables (or much more extremely WITH OID tables)
> and such it's not that hard to reach that point.
Oh, and obviously toast data. A couple tables with toasted columns is
also a good way to rapidly consume oids.
Greetings,
Andres F
On 2015-03-24 23:11:26 -0400, Robert Haas wrote:
> On Mon, Feb 16, 2015 at 4:46 AM, Andres Freund wrote:
> >> At a quick glance, this basic design seems workable. I would suggest
> >> expanding the replication IDs to regular 4 byte oids. Two extra bytes is a
> >> small price to pay, to make it wor
Craig,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> When attempting to insert a row that violates a row security policy that
> applies to writes, the error message emitted references WITH CHECK OPTION,
> even though (as far as the user knows) there's no such thing involved.
> If you understand
On 4/7/15 9:30 AM, Andres Freund wrote:
On 2015-03-28 23:50:20 +0100, Petr Jelinek wrote:
And finally I have issue with how the new identifiers are allocated.
Currently, if you create identifier 'foo', remove identifier 'foo' and
create identifier 'bar', the identifier 'bar' will have same id as
> Why not just create a sequence? I suspect it may not be as fast to assign as
> an OID, but it's not like you'd be doing this all the time.
What does that have to do with the thread?
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
On Tue, Apr 7, 2015 at 10:12 PM, Fabrízio de Royes Mello
wrote:
>
> On Tue, Apr 7, 2015 at 7:22 AM, Sawada Masahiko
> wrote:
>>
>> Thank you for your reviewing.
>> I modified the patch and attached latest version patch(v7).
>> Please have a look it.
>>
>
> Looks good to me. Attached patch (v8) ju
On Tue, Apr 7, 2015 at 1:04 PM, Sawada Masahiko
wrote:
>
> On Tue, Apr 7, 2015 at 10:12 PM, Fabrízio de Royes Mello
> wrote:
> >
> > On Tue, Apr 7, 2015 at 7:22 AM, Sawada Masahiko
> > wrote:
> >>
> >> Thank you for your reviewing.
> >> I modified the patch and attached latest version patch(v7).
Atri Sharma writes:
> Please find attached latest version of UPDATE (*) patch.The patch
> implements review comments and Tom's gripe about touching
> transformTargetList is addressed now. I have added regression tests and
> simplified parser representation a bit.
I spent a fair amount of time cle
On Wed, Apr 8, 2015 at 1:11 AM, Fabrízio de Royes Mello
wrote:
>
> On Tue, Apr 7, 2015 at 1:04 PM, Sawada Masahiko
> wrote:
>>
>> On Tue, Apr 7, 2015 at 10:12 PM, Fabrízio de Royes Mello
>> wrote:
>> >
>> > On Tue, Apr 7, 2015 at 7:22 AM, Sawada Masahiko
>> > wrote:
>> >>
>> >> Thank you for yo
I am playing git tip on windows 7/32 bits, with the backend compiled
with visual studio 2005 (I know, it is very old :-( ).
I encountered avl shutdown slowness twice, last night and this
morning: after a ctrl_c is hit, wait for another 60 seconds, server
shuts down. Here is one log:
D:\pgsql\bin>
I wrote:
> So I'm feeling that this may not be a good idea, or at least not a good
> implementation of the idea. I'm inclined to reject the patch rather than
> lock us into something that is not standard and doesn't really do what
> people would be likely to want.
BTW, a potentially workable fix
Tom Lane wrote:
> I spent a fair amount of time cleaning this patch up to get it into
> committable shape, but as I was working on the documentation I started
> to lose enthusiasm for it, because I was having a hard time coming up
> with compelling examples. The originally proposed motivation was
On Tue, Apr 7, 2015 at 11:19 AM, Tom Lane wrote:
> If we were to go in this direction, it would be nice to at the same time
> add a similar whole-record syntax for INSERT. I'm not sure exactly what
> that should look like though. Also, again, we ought to be paying
> attention to how this would m
On Tue, Apr 7, 2015 at 12:01 PM, Peter Geoghegan wrote:
> I still don't like the idea of
> supporting this, though. I'm not aware of any other system allowing
> something like this for either MERGE or a non-standard UPSERT.
That includes MySQL, BTW. Only their REPLACE statement (which is a
disast
Peter Geoghegan writes:
> On Tue, Apr 7, 2015 at 11:19 AM, Tom Lane wrote:
>> If we were to go in this direction, it would be nice to at the same time
>> add a similar whole-record syntax for INSERT. I'm not sure exactly what
>> that should look like though. Also, again, we ought to be paying
>
On 4/7/15 3:33 PM, Tom Lane wrote:
> I tried to mark the "UPDATE SET (*)" patch as "returned with feedback",
> but the CF app informed me that if I did that the patch would
> automatically be moved to the next commitfest. That seems completely
> stupid. There is no need to reconsider it unless a
I tried to mark the "UPDATE SET (*)" patch as "returned with feedback",
but the CF app informed me that if I did that the patch would
automatically be moved to the next commitfest. That seems completely
stupid. There is no need to reconsider it unless a new version of the
patch is forthcoming (wh
On 4/6/15 5:03 PM, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
>> The present version can trigger an audit trail event for a statement,
>> without tracking the object that was being audited. This prevents you
>> from searching for "all SQL that touches table X", i.e. we know the
>> statements wer
On Tue, Apr 7, 2015 at 5:11 AM, Craig Ringer wrote:
> postgres=> INSERT INTO clients (account_name, account_manager) VALUES
> ('peters', 'peter'), ('johannas', 'johanna');
> ERROR: 44000: new row violates WITH CHECK OPTION for "clients"
> DETAIL: Failing row contains (7, johannas, johanna).
> LO
On 3/31/15 11:01 PM, Craig Ringer wrote:
> Following on from this -bugs post:
>
> http://www.postgresql.org/message-id/camsr+ygj50tvtvk4dbp66gajeoc0kap6kxfehaom+neqmhv...@mail.gmail.com
>
> this patch adds support for views, foreign tables, and materialised
> views to the pg_restore -t flag.
I t
David Rowley wrote:
> If we attempt to do this parallel stuff at plan time, and we
> happen to plan at some quiet period, or perhaps worse, some
> application's start-up process happens to PREPARE a load of
> queries when the database is nice and quite, then quite possibly
> we'll end up with som
Executive summary:
There is now a CommandDeparse_hook;
deparse_utility_command is provided as an extension, intended for 9.6;
rest of patch would be pushed to 9.5.
Long version:
I've made command deparsing hookable. Attached there are three patches:
the first patch contains changes to core tha
Peter Eisentraut writes:
> On 3/31/15 11:01 PM, Craig Ringer wrote:
>> this patch adds support for views, foreign tables, and materialised
>> views to the pg_restore -t flag.
> I think this is a good change. Any concerns?
Are we happy with pg_dump/pg_restore not distinguishing these objects
by
On 04/07/2015 05:59 AM, Michael Paquier wrote:
On Mon, Apr 6, 2015 at 9:10 PM, Fujii Masao wrote:
I eliminated a bunch of newlines in the log messages that seemed
really unnecessary to me, simplifying a bit the whole.
So the patch removed the newlines from the error messages, and added the
n
Heikki Linnakangas wrote:
> On 04/07/2015 05:59 AM, Michael Paquier wrote:
> >Fix inconsistent handling of logs in pg_rewind
> >
> >pg_rewind was handling a couple of things differently compared to the
> >other src/bin utilities:
> >- Logging output needs to be flushed on stderr, not stdout
>
> A
On Tue, Apr 7, 2015 at 1:33 PM, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 3/31/15 11:01 PM, Craig Ringer wrote:
> >> this patch adds support for views, foreign tables, and materialised
> >> views to the pg_restore -t flag.
>
> > I think this is a good change. Any concerns?
>
> Are we ha
I got another repro with the shutdown slowness (DEBUG5 with verbosed
log are attached).
It gives a finer picture of what's going on:
1. Avl ereport("autovacuum launcher shutting down");
2. At the end of errfinish(), it honors a pending SIGINT;
3. SIGINT handler longjmp to the start of avl error h
Qingqing Zhou writes:
> I got another repro with the shutdown slowness (DEBUG5 with verbosed
> log are attached).
> It gives a finer picture of what's going on:
> 1. Avl ereport("autovacuum launcher shutting down");
> 2. At the end of errfinish(), it honors a pending SIGINT;
> 3. SIGINT handler
Alvaro Herrera writes:
> Tom Lane wrote:
>> I think changing the outer "for(;;)" to "while (!got_SIGTERM)" would
>> be a much safer fix.
> Ah, yeah. I was thinking in changing PG_exception_stack once shutdown
> was requested, but this is much simpler.
Your proposed patch seems to be doing both
On 4/7/15 2:00 PM, Alvaro Herrera wrote:
Tom Lane wrote:
I spent a fair amount of time cleaning this patch up to get it into
committable shape, but as I was working on the documentation I started
to lose enthusiasm for it, because I was having a hard time coming up
with compelling examples. Th
On 4/7/15 10:58 AM, Andres Freund wrote:
Why not just create a sequence? I suspect it may not be as fast to assign as
an OID, but it's not like you'd be doing this all the time.
What does that have to do with the thread?
The original bit was...
And finally I have issue with how the new iden
On 11/28/14 11:41 PM, Michael Paquier wrote:
Hi all,
When pg_event_trigger_dropped_objects is run in a context that is not
the one of an event trigger, currently the error code
ERRCODE_FEATURE_NOT_SUPPORTED is returned. Wouldn't it be better to
have an error to define an out-of-context instead?
Etsuro Fujita writes:
> To support ROW_MARK_REFERENCE on (postgres_fdw) foreign tables, I'd like
> to propose the following FDW APIs:
> RowMarkType
> GetForeignRowMarkType(Oid relid,
>LockClauseStrength strength);
> Decide which rowmark type to use for a foreign table (t
On Tue, Apr 7, 2015 at 2:32 PM, Tom Lane wrote:
> That seems like (a) a hack, and (b) not likely to solve the problem
> completely, unless you leave interrupts held throughout proc_exit(),
> which would create all sorts of opportunities for corner case bugs
> during on_proc_exit hooks.
>
Hmm, loo
Qingqing Zhou writes:
> I do feel that we have too many functions instructing how to handle
> interrupts and they are subtle - I just found a new friend
> HOLD_CANCEL_INTERRUPTS :-(
Indeed, which is why I think a patch for this issue should not introduce
a new mode/context in which proc_exit() is
On Tue, Apr 7, 2015 at 4:01 PM, Tom Lane wrote:
>
> Indeed, which is why I think a patch for this issue should not introduce
> a new mode/context in which proc_exit() is executed.
Agree. Along this line, we can add an on_proc_exit hook simply
ereport("we are exiting") there. In this way, we reuse
On Mon, Apr 6, 2015 at 12:53 AM, Alvaro Herrera
wrote:
>
> Fabrízio de Royes Mello wrote:
>
> > Ok guys. The attached patch refactor the reloptions adding a new field
> > "lockmode" in "relopt_gen" struct and a new method to determine the
> > required lock level from an option list.
> >
> > We nee
My understanding is that all subtransactions get their own unique XID
(assuming they need one), and that CommandId can't move backwards within
a transaction. If that's correct, then shouldn't we be able to prune
tuples where XMIN and XMAX match our *exact* XID (not all the extra
stuff that Tran
On Tue, Apr 7, 2015 at 5:59 PM, Jim Nasby wrote:
> My understanding is that all subtransactions get their own unique XID
> (assuming they need one), and that CommandId can't move backwards within a
> transaction. If that's correct, then shouldn't we be able to prune tuples
> where XMIN and XMAX ma
Fabrízio de Royes Mello wrote:
> On Mon, Apr 6, 2015 at 12:53 AM, Alvaro Herrera
> wrote:
> >
> > Fabrízio de Royes Mello wrote:
> >
> > > Ok guys. The attached patch refactor the reloptions adding a new field
> > > "lockmode" in "relopt_gen" struct and a new method to determine the
> > > required
Jim Nasby wrote:
> On 11/28/14 11:41 PM, Michael Paquier wrote:
> >Hi all,
> >
> >When pg_event_trigger_dropped_objects is run in a context that is not
> >the one of an event trigger, currently the error code
> >ERRCODE_FEATURE_NOT_SUPPORTED is returned. Wouldn't it be better to
> >have an error to
On 2/13/15 11:20 PM, Michael Paquier wrote:
On Sat, Feb 14, 2015 at 6:24 AM, Andrew Dunstan wrote:
On 12/18/2014 06:05 PM, Andrew Dunstan wrote:
On 12/18/2014 03:02 AM, Michael Paquier wrote:
On Fri, Dec 12, 2014 at 10:45 PM, Alvaro Herrera
wrote:
Another thing in that patch was that I
On 4/7/15 8:11 PM, Peter Geoghegan wrote:
You're not the first to consider trying something like this in
specific scenarios, but my work on UPSERT leads me to believe it isn't
workable.
Yeah, every time I get into the really nitty-gritty details of this
stuff it gets scary. That's why I didn't
On Tue, Apr 7, 2015 at 10:15 PM, Alvaro Herrera
wrote:
>
> Fabrízio de Royes Mello wrote:
> > On Mon, Apr 6, 2015 at 12:53 AM, Alvaro Herrera <
alvhe...@2ndquadrant.com>
> > wrote:
> > >
> > > Fabrízio de Royes Mello wrote:
> > >
> > > > Ok guys. The attached patch refactor the reloptions adding a
On Wed, Apr 8, 2015 at 10:28 AM, Jim Nasby wrote:
> Just so this doesn't get lost... did something make it into a CommitFest on
> this?
Peter's patch has been committed as 64cdbbc, while the idea to create
sql/ by pg_regress if it is not present did not gather much interest
in this CF:
https://com
On Wed, Apr 8, 2015 at 5:53 AM, Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
>> On 04/07/2015 05:59 AM, Michael Paquier wrote:
>
>> >Fix inconsistent handling of logs in pg_rewind
>> >
>> >pg_rewind was handling a couple of things differently compared to the
>> >other src/bin utilities:
>> >-
On Tue, Apr 7, 2015 at 6:11 PM, Peter Geoghegan wrote:
> No. For one thing, unique index enforcement still requires the tuples
> to be treated as a conflict while the other transaction is running
> IMV.
>
Not sure if I understand correctly: in uniqueness check, we see all
possible tuples with a d
On Tue, Apr 7, 2015 at 7:16 PM, Qingqing Zhou wrote:
> If another transaction T2 coming later than T1, and if we prune early,
> then T1 can suddenly hang on insertion waiting for T2 to complete. But
> does this violate any isolation rule?
Well, it means that you don't lock a row that you delete (
On Sat, Apr 4, 2015 at 5:19 AM, David Rowley wrote:
> Going over the previous emails in this thread I see that it has been a long
> time since anyone discussed anything around how we might decide at planning
> time how many workers should be used for the query, and from the emails I
> don't recall
On Mon, Mar 30, 2015 at 9:20 AM, Peter Geoghegan wrote:
>> * The code uses LockTupleExclusive to lock rows. That means the fkey key
>> locking doesn't work; That's annoying. This means that using upsert
>> will potentially cause deadlocks in other sessions :(. I think you'll
>> have to deter
On Sun, Apr 5, 2015 at 3:59 PM, Peter Geoghegan wrote:
> Attached patch makes trace_sort control abbreviation debug output for
> the text opclass, which makes it consistent with the numeric opclass.
> This seems better than relying on someone going to the trouble of
> building Postgres themselves
On Tue, Apr 7, 2015 at 7:46 PM, Robert Haas wrote:
> Done.
Thank you.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Apr 6, 2015 at 1:51 PM, Jim Nasby wrote:
> In any case, I don't think it would be terribly difficult to allow a bit
> more than 1GB in a StringInfo. Might need to tweak palloc too; ISTR there's
> some 1GB limits there too.
The point is, those limits are there on purpose. Changing things
On Tue, Apr 7, 2015 at 3:35 PM, Peter Eisentraut wrote:
> On 4/7/15 3:33 PM, Tom Lane wrote:
>> I tried to mark the "UPDATE SET (*)" patch as "returned with feedback",
>> but the CF app informed me that if I did that the patch would
>> automatically be moved to the next commitfest. That seems com
On 4/3/15 7:44 AM, Jan Urbański wrote:
> To reiterate: I recognise that not handling the callbacks is not the right
> answer. But not stomping on callbacks others might have set sounds like a
> minimal and safe improvement.
I think your patch is okay in that it is not a good idea to overwrite or
u
On Wed, Apr 8, 2015 at 11:57 AM, Robert Haas wrote:
> On Tue, Apr 7, 2015 at 3:35 PM, Peter Eisentraut wrote:
>> On 4/7/15 3:33 PM, Tom Lane wrote:
>>> I tried to mark the "UPDATE SET (*)" patch as "returned with feedback",
>>> but the CF app informed me that if I did that the patch would
>>> aut
On Wed, Apr 8, 2015 at 11:53 AM, Robert Haas wrote:
> On Mon, Apr 6, 2015 at 1:51 PM, Jim Nasby wrote:
>> In any case, I don't think it would be terribly difficult to allow a bit
>> more than 1GB in a StringInfo. Might need to tweak palloc too; ISTR there's
>> some 1GB limits there too.
>
> The p
On Wed, Apr 8, 2015 at 1:53 AM, Kevin Grittner wrote:
>
> David Rowley wrote:
>
> > If we attempt to do this parallel stuff at plan time, and we
> > happen to plan at some quiet period, or perhaps worse, some
> > application's start-up process happens to PREPARE a load of
> > queries when the dat
Hi,
Ya you are right, ext4 allows more directory entries(more than 32000)
but we limited the number of files insides the directory to 32000 to get
better performance. Sorry i'm not mentioned that in my post.
That the reason we plan to use tablespace. The problem we faced in
tablespace is, t
On Wed, Apr 8, 2015 at 7:54 AM, Robert Haas wrote:
>
> I agree that this is an area that needs more thought. I don't
> (currently, anyway) agree that the planner shouldn't know anything
> about parallelism. The problem with that is that there's lots of
> relevant stuff that can only be known at
On Wed, Apr 8, 2015 at 1:57 AM, Sawada Masahiko wrote:
> On Wed, Apr 8, 2015 at 1:11 AM, Fabrízio de Royes Mello
> wrote:
>>
>> On Tue, Apr 7, 2015 at 1:04 PM, Sawada Masahiko
>> wrote:
>>>
>>> On Tue, Apr 7, 2015 at 10:12 PM, Fabrízio de Royes Mello
>>> wrote:
>>> >
>>> > On Tue, Apr 7, 2015 a
Hi,
While reviewing the REINDEX VERBOSE patch, I felt inclined to remove FORCE
option support from REINDEX command. It has been marked "obsolete" since
very old version 7.4. I think that it's no longer worth keeping supporting it.
Thought?
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers ma
Em quarta-feira, 8 de abril de 2015, Fujii Masao
escreveu:
> Hi,
>
> While reviewing the REINDEX VERBOSE patch, I felt inclined to remove FORCE
> option support from REINDEX command. It has been marked "obsolete" since
> very old version 7.4. I think that it's no longer worth keeping supporting
>
On 2/15/15 7:16 PM, Tomas Vondra wrote:
Hi,
On 16.2.2015 00:50, Andrew Gierth wrote:
"Tom" == Tom Lane writes:
I've now tried the attached patch to correct the bucketsize
estimates, and it does indeed stop the planner from considering the
offending path (in this case it just does the join th
On Tue, Apr 7, 2015 at 11:37 PM, Andres Freund wrote:
> On 2015-04-07 16:30:25 +0200, Andres Freund wrote:
>> And with temp tables (or much more extremely WITH OID tables)
>> and such it's not that hard to reach that point.
>
> Oh, and obviously toast data. A couple tables with toasted columns is
On 4/7/15 10:29 PM, Michael Paquier wrote:
On Wed, Apr 8, 2015 at 11:53 AM, Robert Haas wrote:
On Mon, Apr 6, 2015 at 1:51 PM, Jim Nasby wrote:
In any case, I don't think it would be terribly difficult to allow a bit
more than 1GB in a StringInfo. Might need to tweak palloc too; ISTR there's
On 4/7/15 10:49 PM, sudalai wrote:
Ya you are right, ext4 allows more directory entries(more than 32000)
but we limited the number of files insides the directory to 32000 to get
better performance. Sorry i'm not mentioned that in my post.
That the reason we plan to use tablespace. The pro
On Wed, Apr 8, 2015 at 10:21 AM, Alvaro Herrera
wrote:
> Jim Nasby wrote:
>> On 11/28/14 11:41 PM, Michael Paquier wrote:
>> >Hi all,
>> >
>> >When pg_event_trigger_dropped_objects is run in a context that is not
>> >the one of an event trigger, currently the error code
>> >ERRCODE_FEATURE_NOT_SUP
On Sat, Mar 21, 2015 at 2:06 AM, Max Filippov wrote:
> On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov wrote:
>> Ok, one more attempt: maybe instead of checking that stderr is empty
>> we could check that stderr has changed in the presence of the option
>> that we test?
>
> The patch:
> http://www.
Hi Andres,
Following commit (related to this discussion),
added a bug when we use BKI_FORCE_NULL.
commit eb68379c38202180bc8e33fb9987284e314b7fc8
Author: Andres Freund
Date: Sat Feb 21 22:25:49 2015 +0100
Allow forcing nullness of columns during bootstrap.
Bootstrap determines whethe
84 matches
Mail list logo
