> I found that this patch breaks --status-interval option of
> pg_receivexlog when -m option which the patch introduced is supplied.
> When -m is set, pg_receivexlog tries to send the feedback message as soon
> as it flushes WAL file even if status interval timeout has not been passed
> yet. If you
On 24 June 2014 11:02 Jeff Wrote,
>I mean that the other commit, the one conflicting with your patch, is still
>not finished. It probably would not have been committed if we realized the
>problem at the time. That other patch runs analyze in stages at
> different settings of default_statistics
On Mon, Jun 23, 2014 at 9:12 PM, Andres Freund
wrote:
> On 2014-06-23 19:59:10 +0530, Amit Kapila wrote:
> > 12.
> > #ifdef LWLOCK_DEBUG
> > lock->owner = MyProc;
> > #endif
> >
> > Shouldn't it be reset in LWLockRelease?
>
> That's actually intentional. It's quite useful to know the last owner
>
On Monday, June 23, 2014, Dilip kumar wrote:
> On 24 June 2014 03:31, Jeff Wrote,
>
> > > Attached the latest updated patch
> > > 1. Rebased the patch to current GIT head.
> > > 2. Doc is updated.
> > > 3. Supported parallel execution for all db option also.
> >
> > This patch needs to be reb
+1 for having an API better than GDB to make a process emit a memory usage
dump. This is my top non-crash cause for use of GDB in production.
On Mon, Jun 23, 2014 at 07:21:22PM +0200, Andres Freund wrote:
> On 2014-06-23 10:07:36 -0700, Tom Lane wrote:
> > Andres Freund writes:
> > > I wonder if
On Mon, Jun 23, 2014 at 10:10 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 06/23/2014 05:38 PM, Amit Kapila wrote:
>>
>> While looking at function LWLockWaitForVar(), espacially below
>> code:
>>
>> TRACE_POSTGRESQL_LWLOCK_ACQUIRE(T_NAME(l), T_ID(l), LW_EXCLUSIVE);
>>
>> I think in
Noah Misch wrote:
> Concerning the problem that started this thread, I would raise one ALTER TABLE
> event per table and not fire an event for the bulk request as a whole.
Yes, that's how it already works. Essentially, ALTER TABLESPACE MOVE
calls AlterTableInternal, and that function calls one A
On 24 June 2014 03:31, Jeff Wrote,
> > Attached the latest updated patch
> > 1. Rebased the patch to current GIT head.
> > 2. Doc is updated.
> > 3. Supported parallel execution for all db option also.
>
> This patch needs to be rebased after the analyze-in-stages patch,
> c92c3d50d7fbe7391b5
On Mon, Jun 23, 2014 at 9:12 PM, Andres Freund
wrote:
> On 2014-06-23 19:59:10 +0530, Amit Kapila wrote:
> > On Tue, Jun 17, 2014 at 8:56 PM, Andres Freund
> > wrote:
> > 2.
> > LWLockAcquireCommon()
> > {
> > ..
> > if (!LWLockDequeueSelf(l))
> > {
> > /*
> > * Somebody else dequeued us and has
On Mon, Jun 23, 2014 at 05:10:02PM -0400, Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > I'm not against changing it- doing operations on a whole tablespace felt
> > like it would make sense under 'ALTER TABLESPACE' to me (hence th
Hi all
Someone recently mentioned that there's no generate_series(numeric,
numeric, numeric) .
That strikes me as a great candidate for a
new-developer-learning-PostgreSQL TODO.
A couple of other things I occasionally run into that'd fit the bill:
* A user-level elog(...) / ereport(...) functi
On Mon, Jun 23, 2014 at 6:25 PM, Jeff Janes wrote:
> On Mon, Jun 23, 2014 at 3:53 PM, Andres Freund
> wrote:
>> On 2014-06-23 13:10:34 -0400, Robert Haas wrote:
>>> On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner
>>> wrote:
>>> > I would be for excluding the pg_toast, pg_toast_temp_n, and
>>> >
At 2014-06-23 16:51:55 -0400, sfr...@snowman.net wrote:
>
> We can't control what gets audited through the catalog and have to
> manage that outside of PG, right?
Right. I understand now.
> Are both the connected user and the current role that the command is
> running under logged?
Yes, they are
On Tue, Jun 24, 2014 at 9:34 AM, Andrew Dunstan wrote:
>
> On 06/23/2014 07:34 PM, Tom Lane wrote:
>
>> Andrew Dunstan writes:
>>
>>> On 06/23/2014 11:43 AM, Tom Lane wrote:
>>>
However, it seems to me that these functions (json[b]_to_record[set])
are
handling the nested-json-obje
Tom Lane wrote:
> Stephen Frost writes:
> > That it's more-or-less a bulk 'ALTER TABLE' operation is why I had been
> > trying to think of a way to put it under that command. What if we had a
> > more general way to reference 'all objects in a tablespace'?
> > "tablespace.*" or "ALL:TABLESAPCE"?
On Tue, Jun 24, 2014 at 10:43 AM, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 06/23/2014 07:34 PM, Tom Lane wrote:
> >> I'm not following your comment about 9.3. The json[b]_to_record[set]
> >> functions are new in 9.4, which is what makes me feel it's not too
> >> late to redefine their be
On Mon, Jun 23, 2014 at 3:30 PM, Heikki Linnakangas
wrote:
>> load, then it might take quite a long time. I'm thinking we might
>> want a CHECK_FOR_INTERRUPTS() in the following two places:
>>
>> 1. Inside toast_save_datum, at the top of the loop that starts with
>> "while (data_todo > 0)".
>> 2.
Andrew Dunstan writes:
> On 06/23/2014 07:34 PM, Tom Lane wrote:
>> I'm not following your comment about 9.3. The json[b]_to_record[set]
>> functions are new in 9.4, which is what makes me feel it's not too
>> late to redefine their behavior. But changing behavior of stuff that
>> was in 9.3 see
On Mon, Jun 23, 2014 at 3:53 PM, Andres Freund > wrote:
> On 2014-06-23 13:10:34 -0400, Robert Haas wrote:
>> On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner > wrote:
>> > I would be for excluding the pg_toast, pg_toast_temp_n, and
>> > pg_temp_n schemas, and including public and pg_catalog.
>>
>>
Stephen Frost writes:
> That it's more-or-less a bulk 'ALTER TABLE' operation is why I had been
> trying to think of a way to put it under that command. What if we had a
> more general way to reference 'all objects in a tablespace'?
> "tablespace.*" or "ALL:TABLESAPCE"? Are there other places wh
On Wed, Jun 11, 2014 at 7:51 AM, Heikki Linnakangas
wrote:
>
>
> I did again the refactoring you did back in 2006, patch attached. One
thing
> I did differently: I moved the raw, non-encrypted, read/write functions to
> separate functions: pqsecure_raw_read and pqsecure_raw_write. Those
> function
On Mon, Jun 23, 2014 at 7:19 PM, Tom Lane wrote:
> Jeff Janes writes:
>> I didn't add this patch to the commitfest, because it was just a point
>> for discussion and not actually proposed for application. But It
>> doesn't seem to have provoked much discussion either.
>
>> Should I go add this t
On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark wrote:
> On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas wrote:
>> However, we don't know of anyone who has tried to do this in a very
>> long time, and are therefore considering removing the remaining
>> support for the VAX platform. Has anyone tried to
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
>
> > Any further thoughts on this? I haven't tried to go implement anything
> > yet but I'm definitely concerned that we may run into a keyword issue
> > with ALTER TABLE, but I don't really want to add 'TABLES' either.
>
On 06/23/2014 07:34 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 06/23/2014 11:43 AM, Tom Lane wrote:
However, it seems to me that these functions (json[b]_to_record[set]) are
handling the nested-json-objects case in a fairly brain-dead fashion to
start with. I would like to propose that we
Andrew Dunstan writes:
> On 06/23/2014 11:43 AM, Tom Lane wrote:
>> However, it seems to me that these functions (json[b]_to_record[set]) are
>> handling the nested-json-objects case in a fairly brain-dead fashion to
>> start with. I would like to propose that we should think about getting
>> rid
Jeff Janes writes:
> I didn't add this patch to the commitfest, because it was just a point
> for discussion and not actually proposed for application. But It
> doesn't seem to have provoked much discussion either.
> Should I go add this to the next commitfest?
> I do see it listed as a resolve
On Mon, Jun 23, 2014 at 1:17 PM, Robert Haas wrote:
>
> On Wed, Jun 18, 2014 at 9:39 PM, Matheus de Oliveira
> wrote:
> >> Then, to summarize Matheus must do:
> >> * use an option instead of change the syntax and catalog to indicate
that
> >> a tablespace is used to store temp objects
> >
> > Yes
On Mon, Jun 23, 2014 at 2:43 PM, John Lumby wrote:
> It is when some *other* backend gets there first with the ReadBuffer that
> things are a bit trickier.The current version of the patch did polling
> for that case
> but that drew criticism,and so an imminent new version of the patch
> u
On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas wrote:
> However, we don't know of anyone who has tried to do this in a very
> long time, and are therefore considering removing the remaining
> support for the VAX platform. Has anyone tried to build PostgreSQL
> for VAX lately?
Actually I tried a wh
On 2014-06-23 13:10:34 -0400, Robert Haas wrote:
> On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner wrote:
> > I would be for excluding the pg_toast, pg_toast_temp_n, and
> > pg_temp_n schemas, and including public and pg_catalog.
>
> +1.
Jeff, are you willing to update the patch that way? Seems
On 2014-06-23 13:19:47 -0700, Kevin Grittner wrote:
> >>> which already seems less clear (because the transaction belongs
> >>> to idle)
>
> I have no idea what that means.
It's "idle_in_transaction"_session_timeout. Not
"idle_in"_transaction_session_timeout.
> >>> and for another that distincti
Stephen Frost wrote:
> Any further thoughts on this? I haven't tried to go implement anything
> yet but I'm definitely concerned that we may run into a keyword issue
> with ALTER TABLE, but I don't really want to add 'TABLES' either.
> Anyone have any other suggestions or ideas?
I thought that t
Hi,
On 2014-06-23 13:00:11 -0700, Jeff Davis wrote:
> On Fri, 2014-06-20 at 09:10 +, Andres Freund wrote:
> > To fix, simply move all the all-visible handling outside the critical
> > section. Doing so means that the PD_ALL_VISIBLE on the page won't be
> > included in the full page image of th
On Thu, May 15, 2014 at 4:06 PM, Jeff Janes wrote:
> On Thu, May 15, 2014 at 12:55 PM, Alvaro Herrera
> wrote:
>>
>> Jeff Janes wrote:
>>
>> > If you have a database with a large table in it that has just passed
>> > autovacuum_freeze_max_age, all future workers will be funnelled into
>> > that
>
Hello VAX Enthusiasts:
PostgreSQL currently has some very minimal code to support the VAX
architecture. We have never supported OpenVMS, so this code would
only be used if someone were to compile PostgreSQL for VAX on an
operating system that we *do* support, such as NetBSD or OpenBSD.
However, w
On Fri, Mar 21, 2014 at 12:48 AM, Dilip kumar wrote:
> On 16 January 2014 19:53, Euler Taveira Wrote,
>
>> >
>> >> For the case where you have tables of varying size this would lead
>> to a reduced overall processing time as it prevents large (read: long
>> processing time) tables to be processed
> Date: Thu, 19 Jun 2014 15:43:44 -0300
> Subject: Re: Extended Prefetching using Asynchronous IO - proposal and patch
> From: klaussfre...@gmail.com
> To: st...@mit.edu
> CC: hlinnakan...@vmware.com; johnlu...@hotmail.com;
> pgsql-hackers@postgresql.org
On 15.5.2014 00:41, Tomas Vondra wrote:
> On 13.5.2014 20:42, Tomas Vondra wrote:
>> On 10.5.2014 20:21, Tomas Vondra wrote:
>>> On 9.5.2014 00:47, Tomas Vondra wrote:
>>>
>>> And I've requested 6 more animals - two for each compiler. One set for
>>> tests with basic CLOBBER, one set for recursive
On 06/18/2014 03:39 AM, Andreas Karlsson wrote:
On 06/18/2014 02:34 AM, Ian Barwick wrote:
On 14/06/18 7:51, Andreas Karlsson wrote:
On 06/17/2014 01:36 PM, Ian Barwick wrote:
One issue - the table's internal triggers will also be listed. which can
result in
something like this:
This is a bit
On 6/20/14, 5:12 PM, John Lumby wrote:
I also appreciate it is not easy to review the patch.
There are really 4 (or maybe 5) parts :
. async io (librt functions)
. buffer management (allocating, locking and pinning etc)
. scanners making prefetch calls
. statist
All,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Alvaro Herrera writes:
> > > ALTER TABLESPACE MOVE is a glorified ALTER TABLE. If ALTER TABLESPACE
> > > MOVE returned ALTER TABLE as a tag, I think it'd work well too; but not
> > > ALTER TABLESPACE.
* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
> At 2014-06-23 08:50:33 -0400, sfr...@snowman.net wrote:
> > I'm not a huge fan of adding this as a contrib module
>
> I added it to the CF because we're interested in auditing functionality
> for 9.5, and as far as I can tell, there's nothing bet
>
> > A long idle in transaction state pretty much always indicates a
> > problematic interaction with postgres.
>
> True. Which makes me wonder whether we shouldn't default this to
> something non-zero -- even if it is 5 or 10 days.
I guess it depends on how parental we want to be. But if we
>
>
> >>>
> >>> I think that'd be rather confusing. For one it'd need to be
> >>> idle_in_transaction_timeout
>
> Why? We're cancelling an idle transaction, not an "idle in
> transaction", whatever that is.
>
>
The confusion derives from the fact we are affecting a session whose state
is "idle in
Andres Freund wrote:
> On 2014-06-23 20:29:17 +0900, Fujii Masao wrote:
>> On Mon, Jun 23, 2014 at 7:48 PM, Andres Freund
>> wrote:
>>> On 2014-06-22 19:03:32 -0700, Kevin Grittner wrote:
Andres Freund wrote:
> I think we'll want a version of this that just fails the
> transac
On 04/21/2014 07:51 AM, Воронин Дмитрий wrote:
I put patch generated on git diffs to this letter. I make an a thread in
postgresql commit fest:
https://commitfest.postgresql.org/action/patch_view?id=1438
Thanks for the patch, it seems like a useful feature.
=== General ===
- Applies cleanly t
On 06/23/2014 11:43 AM, Tom Lane wrote:
Michael Paquier writes:
Digging more into that, I have found the issue and a fix for it. It happens
that populate_recordset_object_start, which is used to initialize the
process for the population of the record, is taken *each* time a json
object is foun
On Fri, 2014-06-20 at 09:10 +, Andres Freund wrote:
> To fix, simply move all the all-visible handling outside the critical
> section. Doing so means that the PD_ALL_VISIBLE on the page won't be
> included in the full page image of the HEAP2_CLEAN record anymore. But
> that's fine, the flag wil
On Thu, Jun 19, 2014 at 12:32 PM, Greg Stark wrote:
> On Wed, Jun 18, 2014 at 4:51 AM, Heikki Linnakangas
> wrote:
>> Implementing something is a good way to demonstrate how it would look like.
>> But no, I don't insist on implementing every possible design whenever a new
>> feature is proposed.
On 06/23/2014 08:07 PM, Robert Haas wrote:
While talking to Amit Kapila this morning, he mentioned to me that
there seem to be no CHECK_FOR_INTERRUPTS() calls anywhere in
heap_multi_insert() or the functions it calls. Should there be?
Haven't heard any complaints, but I guess..
By way of cont
On 06/23/2014 08:07 PM, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
With 8k block size, that's just enough to cover the full range of
2^32-1 blocks that you'll need if you set mm_pages_per_range=1. Each
regular revmap page can store about 8192/6 = 1365 item pointers,
each array revmap page c
At 2014-06-23 08:50:33 -0400, sfr...@snowman.net wrote:
>
> I'm not a huge fan of adding this as a contrib module
I added it to the CF because we're interested in auditing functionality
for 9.5, and as far as I can tell, there's nothing better available. At
the moment, the contrib module has the
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jun 18, 2014 at 2:18 PM, Stephen Frost wrote:
> > I'm also of the opinion that this isn't strictly necessary for the
> > initial RLS offering in PG- there's a clear way we could migrate
> > existing users to a multi-policy system from a single
On Mon, Jun 23, 2014 at 12:49 PM, Tom Lane wrote:
> Gurjeet Singh writes:
>> While I'd love to reduce the number of future installations without
>> this fix in place, I respect the decision to honor project policy. At
>> the same time, this change does not break anything. It introduces new
>> env
On 06/22/2014 09:02 PM, Abhijit Menon-Sen wrote:
> I (somewhat reluctantly) agree with Kevin that
> "idle_in_transaction_session_timeout" (for FATAL) and
> "idle_transaction_timeout" (for ERROR) would work.
Given that an IIT timeout has been a TODO for at least 6 years before
being addressed, I'm
2014-06-23 19:22 GMT+02:00 Kevin Grittner :
> Vik Fearing wrote:
> > On 06/23/2014 04:51 PM, rohtodeveloper wrote:
> >> 1.SQL statement support
> >> INSERT statement without INTO keyword
> >> DELETE statement without FROM keywork
> >
> > Why would we want this?
>
> I'm pretty sure that the on
Hello
I am sending little bit modified patch by Fujii' comments - but I am not
able to fix it more - it is task for someone with better English skill then
I have
Regards
Pavel
2014-06-23 10:02 GMT+02:00 Fujii Masao :
> On Mon, Jun 23, 2014 at 12:04 AM, Pavel Stehule
> wrote:
> > Hello
> >
>
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'd expect a catalog table or perhaps changes to pg_class (maybe other
> > things also..) to define what gets logged.
>
> How exactly will that work for log messages generated in contexts where
> we do not have working catal
Vik Fearing wrote:
> On 06/23/2014 04:51 PM, rohtodeveloper wrote:
>> 1.SQL statement support
>> INSERT statement without INTO keyword
>> DELETE statement without FROM keywork
>
> Why would we want this?
I'm pretty sure that the only argument for it is to ease migration
of software from other
On 2014-06-23 10:07:36 -0700, Tom Lane wrote:
> Andres Freund writes:
> > I wonder if it'd make sense to allow a signal to trigger a memory
> > context dump? I and others more than once had the need to examine memory
> > usage on production systems and using gdb isn't always realistic.
> > I wonde
On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner wrote:
> Andres Freund wrote:
>> On 2014-06-22 20:02:57 -0700, Tom Lane wrote:
>>> Ian Barwick writes:
On 23/06/14 00:58, Andres Freund wrote:
> I thought about committing this but couldn't get over this bit. If you
> type "SELECT * FR
Heikki Linnakangas wrote:
> Some comments, aside from the design wrt. bounding boxes etc. :
Thanks. I haven't commented on that sub-thread because I think it's
possible to come up with a reasonable design that solves the issue by
adding a couple of amprocs. I need to do some more thinking to ens
On 2014-06-23 12:46:11 -0400, Robert Haas wrote:
> On Mon, Jun 23, 2014 at 12:29 PM, Andres Freund
> wrote:
> >> > That we have support for platforms that we haven't even documented as
> >> > working (e.g. SuperH) or platforms that don't work in the realword
> >> > (m32r) means that that one has
Andres Freund writes:
> I wonder if it'd make sense to allow a signal to trigger a memory
> context dump? I and others more than once had the need to examine memory
> usage on production systems and using gdb isn't always realistic.
> I wonder if we could install a signal handler for some unused s
Hi,
While talking to Amit Kapila this morning, he mentioned to me that
there seem to be no CHECK_FOR_INTERRUPTS() calls anywhere in
heap_multi_insert() or the functions it calls. Should there be?
By way of contrast, heapgetpage() has this:
/*
* Be sure to check for interrupts at least o
Gurjeet Singh writes:
> On Mon, Jun 23, 2014 at 11:52 AM, Tom Lane wrote:
>> While this is clearly an improvement over what we had before, it's
>> impossible to argue that it's a bug fix, and we are way past the 9.4
>> feature freeze deadline. In particular, packagers who've already done
>> thei
On Mon, Jun 23, 2014 at 12:39 PM, Vik Fearing wrote:
> On 06/23/2014 06:21 PM, Robert Haas wrote:
>> On Sun, Jun 22, 2014 at 2:59 PM, Pavel Stehule
>> wrote:
>>> I found only one problem - first patch introduce a new property
>>> CONNECTION_LIMIT and replace previously used "CONNECTION LIMIT" in
On Mon, Jun 23, 2014 at 12:29 PM, Andres Freund wrote:
>> > That we have support for platforms that we haven't even documented as
>> > working (e.g. SuperH) or platforms that don't work in the realword
>> > (m32r) means that that one has to think about and research so many more
>> > edge cases tha
2014-06-23 18:39 GMT+02:00 Vik Fearing :
> On 06/23/2014 06:21 PM, Robert Haas wrote:
> > On Sun, Jun 22, 2014 at 2:59 PM, Pavel Stehule
> wrote:
> >> I found only one problem - first patch introduce a new property
> >> CONNECTION_LIMIT and replace previously used "CONNECTION LIMIT" in
> >> docum
On 06/23/2014 06:21 PM, Robert Haas wrote:
> On Sun, Jun 22, 2014 at 2:59 PM, Pavel Stehule
> wrote:
>> I found only one problem - first patch introduce a new property
>> CONNECTION_LIMIT and replace previously used "CONNECTION LIMIT" in
>> documentation. But "CONNECTION LIMIT" is still supported
On 06/23/2014 05:38 PM, Amit Kapila wrote:
While looking at function LWLockWaitForVar(), espacially below
code:
TRACE_POSTGRESQL_LWLOCK_ACQUIRE(T_NAME(l), T_ID(l), LW_EXCLUSIVE);
I think in this function tracing is done considering the Exclusive lock
is acquired, however it might have granted a
On 2014-06-23 09:28:19 -0700, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jun 23, 2014 at 11:16 AM, Andres Freund
> > wrote:
> >> Since fetch-and-add is trivially implemented using CAS, there's not much
> >> need to distinguish between CAS and CAS + fetch_and_add. From my POV the
> >> rest
On 06/17/2014 03:17 PM, Andres Freund wrote:
LWLockWaitForVar() doesn't set releaseOk to true when waiting
again. Isn't that a bug?
LWLockWaitForVar() waits in LW_WAIT_UNTIL_FREE mode, because it's not
interested in acquiring the lock, it just wants to be woken up when it's
released (or the "
On Wed, Jun 18, 2014 at 2:18 PM, Stephen Frost wrote:
> I'm also of the opinion that this isn't strictly necessary for the
> initial RLS offering in PG- there's a clear way we could migrate
> existing users to a multi-policy system from a single-policy system.
> Sure, to get the performance and op
On Mon, Jun 23, 2014 at 11:52 AM, Tom Lane wrote:
> Gurjeet Singh writes:
>> would it be possible to include this in 9.4 as well?
>
> While this is clearly an improvement over what we had before, it's
> impossible to argue that it's a bug fix, and we are way past the 9.4
> feature freeze deadline
On 2014-06-23 12:08:08 -0400, Robert Haas wrote:
> > That we still have !PG_USE_INLINE support although all buildfarm animals
> > support it since 4c8aa8b (fixing acc) causes absurd constructs
> > (STATIC_IF_INLINE) and fugly macro usage making it harder to read
> > and modify code. I spend a good
Robert Haas writes:
> On Mon, Jun 23, 2014 at 11:16 AM, Andres Freund
> wrote:
>> Since fetch-and-add is trivially implemented using CAS, there's not much
>> need to distinguish between CAS and CAS + fetch_and_add. From my POV the
>> restriction to just CAS/fetch_and_add isn't actually buying mu
On Sun, Jun 22, 2014 at 2:59 PM, Pavel Stehule wrote:
> I found only one problem - first patch introduce a new property
> CONNECTION_LIMIT and replace previously used "CONNECTION LIMIT" in
> documentation. But "CONNECTION LIMIT" is still supported, but it is not
> documented. So for some readers i
On Mon, Jun 23, 2014 at 11:28 AM, Andres Freund wrote:
>> Oh, great. Somehow I missed the fact that that had been addressed. I
>> had assumed that we still needed global identifiers in which case I
>> think they'd need to be 64+ bits (preferably more like 128). If they
>> only need to be locall
On 06/23/2014 04:51 PM, rohtodeveloper wrote:
> 1.SQL statement support
> INSERT statement without INTO keyword
> DELETE statement without FROM keywork
Why would we want this?
--
Vik
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
On Mon, Jun 23, 2014 at 10:43 AM, Tom Lane wrote:
> Michael Paquier writes:
>> Digging more into that, I have found the issue and a fix for it. It happens
>> that populate_recordset_object_start, which is used to initialize the
>> process for the population of the record, is taken *each* time a j
From: "Andres Freund"
I wonder if it'd make sense to allow a signal to trigger a memory
context dump? I and others more than once had the need to examine memory
usage on production systems and using gdb isn't always realistic.
+1
It would be nice if there's a generic infrastructure on which t
Robert Haas writes:
> You might find a sub-SELECT helpful:
> SELECT * FROM (SELECT json_data->>âplan'->>âid' as plan_id FROM
> orders) x WHERE plan_id = 1
> It might be a generally useful thing for WHERE-clause items to be able
> to reference items from the target list by alias, or maybe it'
On Wed, Jun 18, 2014 at 9:39 PM, Matheus de Oliveira
wrote:
>> Then, to summarize Matheus must do:
>> * use an option instead of change the syntax and catalog to indicate that
>> a tablespace is used to store temp objects
>
> Yes. I myself wasn't sure TEMPORARY syntax would be good, but I would ju
Heikki Linnakangas writes:
> Earlier in this thread, MauMau pointed out that we can't do encoding
> conversions until we have connected to the database because you need to
> read pg_conversion for that. That's because we support creating custom
> conversions with CREATE CONVERSION. Frankly, I d
On Mon, Jun 23, 2014 at 11:16 AM, Andres Freund wrote:
>> This criterion has been proposed before, but I'm not sure I really
>> agree with it. If having code around that targets obscure platforms
>> is hindering the development of new features, then that's a reason to
>> get rid of it.
>
> I thin
2014-06-23 18:00 GMT+02:00 Kevin Grittner :
> Andrew Dunstan wrote:
> > On 06/23/2014 10:51 AM, rohtodeveloper wrote:
>
> >> Our application will be switched from SQL Server to PostgreSQL.
> >> However, a few functions are not supported yet. So we decided to
> >> extend it.
> >>
> >> The function
Andrew Dunstan wrote:
> On 06/23/2014 10:51 AM, rohtodeveloper wrote:
>> Our application will be switched from SQL Server to PostgreSQL.
>> However, a few functions are not supported yet. So we decided to
>> extend it.
>>
>> The functions are as following:
>>
>> 1.SQL statement support
>> INSER
Stephen Frost writes:
> I'd expect a catalog table or perhaps changes to pg_class (maybe other
> things also..) to define what gets logged.
How exactly will that work for log messages generated in contexts where
we do not have working catalog access? (postmaster, crash recovery,
or pretty much a
Gurjeet Singh writes:
> would it be possible to include this in 9.4 as well?
While this is clearly an improvement over what we had before, it's
impossible to argue that it's a bug fix, and we are way past the 9.4
feature freeze deadline. In particular, packagers who've already done
their 9.4 dev
Michael Paquier writes:
> Digging more into that, I have found the issue and a fix for it. It happens
> that populate_recordset_object_start, which is used to initialize the
> process for the population of the record, is taken *each* time a json
> object is found, re-creating every time the hash t
On 2014-06-23 19:59:10 +0530, Amit Kapila wrote:
> On Tue, Jun 17, 2014 at 8:56 PM, Andres Freund
> wrote:
> > On 2014-06-17 20:47:51 +0530, Amit Kapila wrote:
> > > On Tue, Jun 17, 2014 at 6:35 PM, Andres Freund
> > > wrote:
> > >
> > > You have followed it pretty well as far as I can understand
On 06/23/2014 11:06 AM, Robert Haas wrote:
On Fri, Jun 20, 2014 at 11:26 AM, Joey Caughey
wrote:
I’m having an issue with JSON requests in Postgres and was wondering if
anyone had an answer.
I have an orders table with a field called “json_data”.
In the json data there is a plan’s array with
On 2014-06-23 10:45:51 -0400, Robert Haas wrote:
> On Mon, Jun 23, 2014 at 10:11 AM, Andres Freund
> wrote:
> >> > Why? Users and other systems only ever see the external ID. Everything
> >> > leaving the system is converted to the external form. The short id
> >> > basically is only used in shar
Some comments, aside from the design wrt. bounding boxes etc. :
On 06/15/2014 05:34 AM, Alvaro Herrera wrote:
Robert Haas wrote:
On Wed, Sep 25, 2013 at 4:34 PM, Alvaro Herrera
wrote:
Here's an updated version of this patch, with fixes to all the bugs
reported so far. Thanks to Thom Brown, J
On 06/23/2014 10:51 AM, rohtodeveloper wrote:
Dear all，
Our application will be switched from SQL Server to PostgreSQL.
However, a few functions are not supported yet. So we decided to
extend it.
The functions are as following:
1.SQL statement support
INSERT statement without INTO keyword
On Mon, Jun 23, 2014 at 11:15 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Similarly,
>> building a logging facility that meets the needs of real users is
>> going to require a configuration method more flexible than a total
>> order with four choices. I happen to th
On 2014-06-23 10:29:54 -0400, Robert Haas wrote:
> On Thu, Jun 19, 2014 at 10:43 AM, Merlin Moncure wrote:
> > On Thu, Jun 19, 2014 at 7:07 AM, Abhijit Menon-Sen
> > wrote:
> >> Let's not pretend to support platforms we have no practical way of
> >> verifying.
> >
> > This is key. The buildfarm
* Robert Haas (robertmh...@gmail.com) wrote:
> Similarly,
> building a logging facility that meets the needs of real users is
> going to require a configuration method more flexible than a total
> order with four choices. I happen to think a list of comma-separated
> tokens is a pretty good choice
1 - 100 of 147 matches
Mail list logo
