On 2014-10-31 14:55:11 +0900, Michael Paquier wrote:
> On Tue, Oct 28, 2014 at 9:25 PM, Simon Riggs wrote:
>
> > On 13 October 2014 10:05, Petr Jelinek wrote:
> >
> > >> I worked bit on this patch to make it closer to committable state.
> >
> > > Here is updated version that works with current H
Noah Misch writes:
> On Thu, Oct 30, 2014 at 10:49:33PM -0400, Tom Lane wrote:
>> I think the installs as such aren't the only reason for the sucky
>> performance. We need to also reduce the number of initdb cycles incurred
>> by the TAP tests. It's useless for example that the pg_controldata te
On Tue, Oct 28, 2014 at 9:25 PM, Simon Riggs wrote:
> On 13 October 2014 10:05, Petr Jelinek wrote:
>
> >> I worked bit on this patch to make it closer to committable state.
>
> > Here is updated version that works with current HEAD for the October
> > committfest.
>
> I've reviewed this and it
On Fri, Oct 31, 2014 at 2:52 AM, Heikki Linnakangas wrote:
> On 10/30/2014 06:02 PM, Andres Freund wrote:
>
>> On 2014-10-29 10:24:20 +0200, Heikki Linnakangas wrote:
>>
>>> On 10/06/2014 02:29 PM, Andres Freund wrote:
>>>
I've not yet really looked,
but on a quick readthrough XLogInser
On Thu, Oct 30, 2014 at 10:49:33PM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > There are other issues. I am not going to enable this in the buildfarm
> > until the check test can work from a single install. It's insane for the
> > bin tests to take an order of magnitude longer than the m
On Thu, Oct 30, 2014 at 2:28 PM, Simon Riggs wrote:
> On 30 October 2014 04:24, Amit Kapila wrote:
>
> >> Locking the toast table of any main tables we access seems easily
> >> done. Though perhaps we should make weak locking of the toast table
> >> presumed. Do we have cases where the toast tabl
I wrote:
> I took a quick look. I concur with Fabien that the dependency on
> MAKELEVEL seems pretty horrid: in particular, will that not break the
> ability to initiate "make check" from somewhere below the top directory?
Another use-case that seems to be broken both by Peter's patch and my
prop
Noah Misch writes:
> Looks like _bt_getstackbuf() is always called with some buffer lock held, so
> CHECK_FOR_INTERRUPTS() alone would not help:
> http://www.postgresql.org/message-id/flat/16519.1401395...@sss.pgh.pa.us
Oooh, good point. I never followed up on that idea, but we would have to
in
On Thu, Oct 30, 2014 at 03:52:01PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Robert Haas wrote:
> >> A colleague at EnterpriseDB today ran into a situation on PostgreSQL
> >> 9.3.5 where the server went into an infinite loop while attempting a
> >> VACUUM FREEZE; it couldn't escape _bt_g
Peter Eisentraut writes:
> On 10/7/14 1:57 PM, Tom Lane wrote:
>> Peter had a patch to eliminate the overhead of multiple subinstalls;
>> not sure where that stands, but presumably it would address your issue.
> It will need some cleverness to sort out the parallel make issues that
> were brought
On 10/29/14 10:48 AM, Robert Haas wrote:
> On Tue, Oct 28, 2014 at 8:29 PM, Peter Eisentraut wrote:
>> On 10/20/14 2:59 PM, Tom Lane wrote:
>>> My Salesforce colleague Thomas Fanghaenel observed that the TAP tests
>>> for pg_basebackup fail when run in a sufficiently deeply-nested directory
>>> tr
On Mon, Oct 27, 2014 at 4:15 AM, Rushabh Lathia
wrote:
>
> Hi All,
>
> - Patch got applied cleanly.
> - Regression make check run fine.
> - Patch covered the documentation changes
>
> Here are few comments:
>
> 1) What the need of following change:
>
> diff --git a/src/backend/storage/lmgr/lwlock.
Andrew Dunstan writes:
> There are other issues. I am not going to enable this in the buildfarm
> until the check test can work from a single install. It's insane for the
> bin tests to take an order of magnitude longer than the main regression
> suite.
I think the installs as such aren't the
On 10/28/2014 01:27 PM, Andres Freund wrote:
Hi,
On 2014-10-25 18:09:36 -0400, Steve Singer wrote:
I sometimes get the error "snapshot too large" from my logical replication
walsender process when in response to a CREATE_REPLICATION_SLOT.
Yes. That's possible if 'too much' was going on until a
On 10/30/2014 09:37 PM, Andres Freund wrote:
On 2014-10-30 21:24:04 -0400, Tom Lane wrote:
Andres Freund writes:
On 2014-10-30 21:03:43 -0400, Tom Lane wrote:
Meh. Right now, it's easy to dismiss these tests as unimportant,
figuring that they play little part in whether the completed build
On Thu, Oct 30, 2014 at 2:40 AM, Robert Haas wrote:
> On Tue, Oct 28, 2014 at 6:00 AM, Andres Freund
> wrote:
> >> Uhm. Obviously we didn't have jsonb when I started this and we do have
> >> them now, so I could perhaps see about updating the patch to do things
> >> this way; but I'm not totall
On Thu, Oct 30, 2014 at 12:11 PM, Fujii Masao wrote:
>
> On Tue, Oct 7, 2014 at 2:42 AM, Fabrízio de Royes Mello
> wrote:
> > On Mon, Oct 6, 2014 at 11:13 AM, Marti Raudsepp wrote:
> >>
> >> On Mon, Oct 6, 2014 at 4:27 PM, Fabrízio de Royes Mello
> >> wrote:
> >> > create_index_if_not_exists_v7
On 2014-10-30 21:24:04 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-10-30 21:03:43 -0400, Tom Lane wrote:
> >> Meh. Right now, it's easy to dismiss these tests as unimportant,
> >> figuring that they play little part in whether the completed build
> >> is reliable. But that may not
Andres Freund writes:
> On 2014-10-30 21:03:43 -0400, Tom Lane wrote:
>> Meh. Right now, it's easy to dismiss these tests as unimportant,
>> figuring that they play little part in whether the completed build
>> is reliable. But that may not always be true. If they do become
>> a significant par
On 2014-10-30 21:03:43 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-10-30 20:13:53 -0400, Tom Lane wrote:
> >> As I said upthread, that approach seems to me to be contrary to the
> >> project policy about how configure should behave.
>
> > I don't think that holds much water. There'
Peter Eisentraut writes:
> On 10/28/14 10:01 PM, Peter Eisentraut wrote:
>> On 10/28/14 9:16 PM, Tom Lane wrote:
>>> ISTM that the project policy for external components like this has been
>>> "don't rely on them unless user says to use them, in which case fail if
>>> they aren't present". So per
Andres Freund writes:
> On 2014-10-30 20:13:53 -0400, Tom Lane wrote:
>> As I said upthread, that approach seems to me to be contrary to the
>> project policy about how configure should behave.
> I don't think that holds much water. There's a fair amount of things
> that configure detects automat
On Fri, Oct 31, 2014 at 6:59 AM, Jim Nasby wrote:
> If we stick with this version I'd argue it makes more sense to just stick
> the sync_node = and priority = statements into the if block and ditch the
> continue.
>
Let's go with the cleaner version then, I'd prefer code that can be read
easily
On 2014-10-30 20:13:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-10-30 19:53:54 -0400, Tom Lane wrote:
> >> Well, for example, you don't have and don't want to install IPC::Run.
>
> > Well, that's what the hypothetical configure test is for. I see little
> > reason in this specif
On Thu, Oct 30, 2014 at 04:54:25PM +0100, Andres Freund wrote:
> On 2014-10-30 01:57:15 -0400, Noah Misch wrote:
> > On Wed, Oct 29, 2014 at 08:14:07PM -0400, Peter Eisentraut wrote:
> > > On 10/28/14 9:09 PM, Peter Eisentraut wrote:
> > > > I have looked into IPC::Cmd, but the documentation keeps
Andres Freund writes:
> On 2014-10-30 19:53:54 -0400, Tom Lane wrote:
>> Well, for example, you don't have and don't want to install IPC::Run.
> Well, that's what the hypothetical configure test is for. I see little
> reason in this specific case to do anything more complicated than check
> for p
On 10/28/14 10:01 PM, Peter Eisentraut wrote:
> On 10/28/14 9:16 PM, Tom Lane wrote:
>> ISTM that the project policy for external components like this has been
>> "don't rely on them unless user says to use them, in which case fail if
>> they aren't present". So perhaps what we ought to have is a
On 2014-10-30 19:53:54 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-10-30 19:30:04 -0400, Tom Lane wrote:
> >> At some point down the road that value judgement might (hopefully will)
> >> reverse, and then we could deal with it by making --enable-tap-tests the
> >> default. But even
On 30.10.2014 23:19, David G Johnston wrote:
> Tomas Vondra wrote
>> Also, the current phrasing "If the NOWAIT option is specified then
>> the command will fail if it is unable to acquire all of the locks
>> required immediately." seems a bit ambiguous to me. Maybe it's just
>> me, but I wasn't sur
Andres Freund writes:
> On 2014-10-30 19:30:04 -0400, Tom Lane wrote:
>> At some point down the road that value judgement might (hopefully will)
>> reverse, and then we could deal with it by making --enable-tap-tests the
>> default. But even then there would be a place for
>> --disable-tap-tests.
On 2014-10-30 19:30:04 -0400, Tom Lane wrote:
> Jim Nasby writes:
> > If our policy is that tests are there primarily for developers then I agree
> > with you.
>
> > If not, then would we be OK with make check being a no-op unless you'd
> > configured with --enable-make-check?
>
> > Making thi
On 2014-10-30 18:06:02 -0500, Jim Nasby wrote:
> On 10/30/14, 2:13 PM, Heikki Linnakangas wrote:
> >On 10/30/2014 08:56 PM, Andres Freund wrote:
> >>I actually think we should *always* use the new code and not
> >>add a separate wal_level=minimal branch. Maintaining this twice just
> >>isn't worth
Jim Nasby writes:
> If our policy is that tests are there primarily for developers then I agree
> with you.
> If not, then would we be OK with make check being a no-op unless you'd
> configured with --enable-make-check?
> Making this something you have to enable will seriously limit the number
Hi,
On 2014-10-30 18:03:27 -0400, Robert Haas wrote:
> On Wed, Oct 29, 2014 at 4:58 PM, Andres Freund wrote:
> >> That's true. I don't know what to do about it. I'm somewhat inclined
> >> to think that, if this remains in contrib, it's OK to ignore those
> >> issues until such time as people co
On 10/30/14, 5:32 PM, Tom Lane wrote:
Jim Nasby writes:
On 10/30/14, 4:55 PM, Tom Lane wrote:
I think it should be. You should not have to have either prove or
IPC::Run (or, IIRC, even Perl) in order to do make check-world.
Could configure detect if we have IPC::Run? ISTM it'd be nice to m
On 10/30/14, 2:13 PM, Heikki Linnakangas wrote:
On 10/30/2014 08:56 PM, Andres Freund wrote:
I actually think we should *always* use the new code and not
add a separate wal_level=minimal branch. Maintaining this twice just
isn't worth the effort. minimal is used *far* less these days.
I wouldn
Jim Nasby writes:
> On 10/30/14, 4:55 PM, Tom Lane wrote:
>> I think it should be. You should not have to have either prove or
>> IPC::Run (or, IIRC, even Perl) in order to do make check-world.
> Could configure detect if we have IPC::Run? ISTM it'd be nice to make this
> automatic instead of r
Tomas Vondra wrote
> Also, the current phrasing "If the NOWAIT option is specified then the
> command will fail if it is unable to acquire all of the locks required
> immediately." seems a bit ambiguous to me. Maybe it's just me, but I
> wasn't sure if that means "locks for all objects immediately,
On 10/30/14, 4:55 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 10/30/2014 05:23 PM, Tom Lane wrote:
Anyway, I can confirm Peter's statement that the current tests work even
on quite old platforms, as long as you install IPC::Run.
So, I'm a bit confused. Is the --enable-tap-tests config set
On Wed, Oct 29, 2014 at 4:58 PM, Andres Freund wrote:
>> That's true. I don't know what to do about it. I'm somewhat inclined
>> to think that, if this remains in contrib, it's OK to ignore those
>> issues until such time as people complain about them, because anybody
>> who dislikes the things
On 10/30/14, 8:05 AM, Michael Paquier wrote:
This switches from using a single if() with multiple conditions &&'d
together to a bunch of if() continue's. I don't know if those will perform
the same, and AFAIK this is pretty performance critical.
Well, we could still use the old notation with a s
Andrew Dunstan writes:
> On 10/30/2014 05:23 PM, Tom Lane wrote:
>> Anyway, I can confirm Peter's statement that the current tests work even
>> on quite old platforms, as long as you install IPC::Run.
> So, I'm a bit confused. Is the --enable-tap-tests config setting still
> on the table?
I thi
On 10/30/2014 05:23 PM, Tom Lane wrote:
I wrote:
Yup, you read that right, it took 32 seconds to run those dozen utterly
trivial tests. As far as I could tell by eyeball, pretty much all of the
time went into test 11, which is odd since it seems not significantly
different from the others. I
On 10/30/14, 3:19 AM, Michael Paquier wrote:
Thanks for your input, Jim!
On Wed, Oct 29, 2014 at 7:59 AM, Jim Nasby mailto:jim.na...@bluetreble.com>> wrote:
> Patch applies against current HEAD and builds, but I'm getting 37 failed
> tests (mostly parallel, but also misc and WITH; results atta
On 10/30/14, 3:19 AM, Michael Paquier wrote:
On Wed, Oct 29, 2014 at 7:59 AM, Jim Nasby mailto:jim.na...@bluetreble.com>> wrote:
> Patch applies against current HEAD and builds, but I'm getting 37 failed
> tests (mostly parallel, but also misc and WITH; results attached). Is that
> expected?
T
Hi,
while preparing an overview of features new in 9.4, I noticed that while
we provide NOWAIT for the "ALTER ... ALL IN TABLESPACE" commands, we
don't support that for the 'single object' case. Is that on purpose? I
assume it makes, as with a single object you can't get stuck half-way
through, bu
I wrote:
> Yup, you read that right, it took 32 seconds to run those dozen utterly
> trivial tests. As far as I could tell by eyeball, pretty much all of the
> time went into test 11, which is odd since it seems not significantly
> different from the others. I think there's something wacky about
Adam Brightwell writes:
> FWIW, I found the following in the archives:
> http://www.postgresql.org/message-id/15516.1038718...@sss.pgh.pa.us
> Now this is from 2002 and it appears it wasn't necessary to change at the
> time, but I haven't yet found anything else related (it's a big archive).
> T
Stephen Frost writes:
> The other idea which comes to mind is- could we try to actually resolve
> what the 'right' answer is here, instead of setting a special value and
> then having to detect and fix it later?
No, absolutely not. Read the NOTES at the head of gram.y. Or if you
need it spelled
Alvaro Herrera writes:
> Robert Haas wrote:
>> A colleague at EnterpriseDB today ran into a situation on PostgreSQL
>> 9.3.5 where the server went into an infinite loop while attempting a
>> VACUUM FREEZE; it couldn't escape _bt_getstackbuf(), and it couldn't
>> be killed with ^C. I think we sho
Hi,
On 2014-09-15 15:41:22 +0300, Heikki Linnakangas wrote:
> The second patch contains the interesting changes.
Heikki's pushed the newest version of this to the git tree.
Some things I noticed while reading the patch:
* potential mismerge:
+++ b/src/bin/pg_basebackup/pg_receivexlog.c
@@ -408,7
On 10/30/2014 08:56 PM, Andres Freund wrote:
I actually think we should *always* use the new code and not
add a separate wal_level=minimal branch. Maintaining this twice just
isn't worth the effort. minimal is used *far* less these days.
I wouldn't go that far. Doing the wal_level=minimal optim
On 10/30/2014 08:51 PM, Robert Haas wrote:
On Wed, Oct 29, 2014 at 2:36 PM, Tomas Vondra wrote:
I would tend not to worry too much about this case. I'm skeptical
that there are a lot of people using large template databases. But
if there are, or if some particular one of those people hits this
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> > | RoleId_or_curruser: RoleId{ $$ = $1; }
> > | | CURRENT_USER { $$ = "\x00\x01";};
[...]
> > This is ugly but needs no additional struct member or special
> > logics. (Macros c
Arthur Silva wrote:
> This is slight off topic but please bear with me.
>
> I came across this post:
> http://pauleveritt.wordpress.com/2014/10/29/faster-relevance-ranking-didnt-make-it-into-postgresql-9-4/
> I was curious about it so I checked several commit fest pages and searched
> the mailing
On 2014-10-30 14:51:54 -0400, Robert Haas wrote:
> On Wed, Oct 29, 2014 at 2:36 PM, Tomas Vondra wrote:
> >> I would tend not to worry too much about this case. I'm skeptical
> >> that there are a lot of people using large template databases. But
> >> if there are, or if some particular one of tho
On Wed, Oct 29, 2014 at 2:36 PM, Tomas Vondra wrote:
>> I would tend not to worry too much about this case. I'm skeptical
>> that there are a lot of people using large template databases. But
>> if there are, or if some particular one of those people hits this
>> problem, then they can raise check
This is slight off topic but please bear with me.
I came across this post:
http://pauleveritt.wordpress.com/2014/10/29/faster-relevance-ranking-didnt-make-it-into-postgresql-9-4/
I was curious about it so I checked several commit fest pages and searched
the mailing lists but I wasn't able to locat
Robert Haas wrote:
> A colleague at EnterpriseDB today ran into a situation on PostgreSQL
> 9.3.5 where the server went into an infinite loop while attempting a
> VACUUM FREEZE; it couldn't escape _bt_getstackbuf(), and it couldn't
> be killed with ^C. I think we should add a check for interrupts
Kyotaro,
Zero-length identifiers are rejected in scanner so RoleId cannot
> be a valid pointer to a zero-length string. (NULL is used as
> PUBLIC in auth_ident)
>
> | postgres=# create role "";
> | ERROR: zero-length delimited identifier at or near
> | postgres=# create role U&"\00";
> | ERR
+ BRIN indexes can satisfy queries via the bitmap
+ scanning facility, and will return all tuples in all pages within
"The bitmap scanning facility?" Does this mean a bitmap index scan?
Or something novel to BRIN? I think this could be clearer.
+ This enables them to work as very fast seq
On 10/30/2014 06:02 PM, Andres Freund wrote:
On 2014-10-29 10:24:20 +0200, Heikki Linnakangas wrote:
On 10/06/2014 02:29 PM, Andres Freund wrote:
I've not yet really looked,
but on a quick readthrough XLogInsertRecData() staying in xlog.c doesn't
make me happy...
Ok.. Can you elaborate?
To
A colleague at EnterpriseDB today ran into a situation on PostgreSQL
9.3.5 where the server went into an infinite loop while attempting a
VACUUM FREEZE; it couldn't escape _bt_getstackbuf(), and it couldn't
be killed with ^C. I think we should add a check for interrupts into
that loop somewhere;
I wrote:
> Yup, you read that right, it took 32 seconds to run those dozen utterly
> trivial tests. As far as I could tell by eyeball, pretty much all of the
> time went into test 11, which is odd since it seems not significantly
> different from the others. I think there's something wacky about
On 2014-10-29 10:24:20 +0200, Heikki Linnakangas wrote:
> On 10/06/2014 02:29 PM, Andres Freund wrote:
> >On 2014-10-06 14:19:39 +0300, Heikki Linnakangas wrote:
> >>Barring objections, I'll commit this, and then continue benchmarking the
> >>second patch with the WAL format and API changes.
> >
>
On 2014-10-30 01:57:15 -0400, Noah Misch wrote:
> On Wed, Oct 29, 2014 at 08:14:07PM -0400, Peter Eisentraut wrote:
> > On 10/28/14 9:09 PM, Peter Eisentraut wrote:
> > > I have looked into IPC::Cmd, but the documentation keeps telling me that
> > > to do anything interesting I have to have IPC::Ru
Noah Misch writes:
> Ick; I concur with your judgment on those aspects of the IPC::Cmd design.
> Thanks for investigating. So, surviving options include:
> 1. Require IPC::Run.
> 2. Write our own run() that reports the raw exit code.
> 3. Distill the raw exit code from the IPC::Cmd::run() error
On Fri, Sep 12, 2014 at 6:12 PM, Amit Kapila
wrote:
>
> On Fri, Sep 12, 2014 at 5:07 PM, Dilip kumar
wrote:
> >
> > On 12 September 2014 14:34, Amit Kapila Wrote
>
> > >Please find updated patch to include those documentation changes.
> >
> >
> >
> > Looks fine, Moved to Ready for committer.
>
>
Hi,
I've just once more looked at the WAL stream ans was briefly confused
about all the XLOG_FPI records. Since 54685338e3
log_newpage/log_newpage_buffer and XLogSaveBufferForHint() use the same
WAL record. I personally find that a bad idea because they're used in
quite different situations.
Can
On Tue, Oct 7, 2014 at 2:42 AM, Fabrízio de Royes Mello
wrote:
> On Mon, Oct 6, 2014 at 11:13 AM, Marti Raudsepp wrote:
>>
>> On Mon, Oct 6, 2014 at 4:27 PM, Fabrízio de Royes Mello
>> wrote:
>> > create_index_if_not_exists_v7.patch
>>
>> Looks good to me. Marking ready for committer.
>>
>
> Tha
On 2014-10-30 19:05:06 +0530, Amit Kapila wrote:
> On Thu, Oct 30, 2014 at 6:58 PM, Andres Freund
> wrote:
> > On 2014-10-30 18:54:57 +0530, Amit Kapila wrote:
> > > On Thu, Oct 30, 2014 at 5:52 PM, Andres Freund
> > > wrote:
> > > > Hm. What commit did you apply the series ontop? I managed to
>
On 2014-10-30 15:27:13 +0200, Heikki Linnakangas wrote:
> The comment on PGPROC.procLatch in storage/proc.h says just this:
>
> > Latch procLatch; /* generic latch for process */
>
> This needs a lot more explaining. It's now used by signal handlers to
> interrupt a rea
On Thu, Oct 30, 2014 at 6:58 PM, Andres Freund
wrote:
> On 2014-10-30 18:54:57 +0530, Amit Kapila wrote:
> > On Thu, Oct 30, 2014 at 5:52 PM, Andres Freund
> > wrote:
> > > Hm. What commit did you apply the series ontop? I managed to
reproduce a
> > > hang, but it was just something that heikki h
On 2014-10-30 18:54:57 +0530, Amit Kapila wrote:
> On Thu, Oct 30, 2014 at 5:52 PM, Andres Freund
> wrote:
> > On 2014-10-21 12:40:56 +0530, Amit Kapila wrote:
> > > I have ran it for half an hour, but it doesn't came out even after
> > > ~2 hours. It doesn't get reproduced every time, currently
On 10/03/2014 06:29 PM, Heikki Linnakangas wrote:
On 10/03/2014 05:26 PM, Andres Freund wrote:
On 2014-10-03 17:12:18 +0300, Heikki Linnakangas wrote:
On 09/28/2014 01:54 AM, Andres Freund wrote:
0003 Sinval/notify processing got simplified further. There really isn't
any need for Disab
On Thu, Oct 30, 2014 at 5:52 PM, Andres Freund
wrote:
>
> On 2014-10-21 12:40:56 +0530, Amit Kapila wrote:
> > While doing performance tests, I noticed a hang at higher client
> > counts with patch. I have tried to check call stack for few of
> > processes and it is as below:
> >
> > #0 0x008
I think you're looking for the pgsql-general mailing list. This list is
for PostgreSQL extensions and core database engine software development.
On 10/30/2014 07:44 PM, rohtodeveloper wrote:
> Dear
>
> I'm doing a job about converting an expression of one data type to another.
> In SQLServer, the
Thanks for your review! (No worries for creating a new thread, I don't
mind as this is not a huge patch. I think you could have downloaded
the mbox from postgresql.org btw).
On Thu, Oct 30, 2014 at 8:24 AM, Jim Nasby wrote:
> SyncRepGetSynchronousNode():
> IMHO, the top comment should mention tha
On Thu, Oct 30, 2014 at 7:30 PM, Etsuro Fujita
wrote:
> (2014/10/09 11:49), Etsuro Fujita wrote:
>>
>> (2014/10/08 22:51), Fujii Masao wrote:
>>>
>>> On Wed, Sep 24, 2014 at 11:10 AM, Etsuro Fujita
>>> wrote:
>
> On Wed, Sep 10, 2014 at 10:37 PM, Alvaro Herrera
> wrote:
>>
>>
On 2014-10-21 12:40:56 +0530, Amit Kapila wrote:
> While doing performance tests, I noticed a hang at higher client
> counts with patch. I have tried to check call stack for few of
> processes and it is as below:
>
> #0 0x008010933e54 in .semop () from /lib64/libc.so.6
> #1 0x10286e4
On Wed, Oct 29, 2014 at 3:09 PM, Andres Freund wrote:
>> But if it is, then how about
>> adding a flag that is 4 bytes wide or less alongside bgwriterLatch,
>> and just checking the flag instead of checking bgwriterLatch itself?
>
> Yea, that'd be nicer. I didn't do it because it made the patch sl
Dear
I'm doing a job about converting an expression of one data type to another.In
SQLServer, there'are two functions to do this job.
1. CAST ( expression AS data_type [ ( length ) ] )2. CONVERT ( data_type [ (
length ) ] , expression )
However, In PostgreSQL, there's only the CAST ( expression A
Le mercredi 29 octobre 2014 14:16:23 Demai Ni a écrit :
> Robert and Ronan,
>
> many thanks for your response.
>
> I realized there is no clean way/api for it. maybe a hacking of ptree can
> do the trick.. :-)
>
> I will also take a look at IMPORT FOREIGN SCHEMA. However, for this
> requirement,
On 2014-10-30 10:23:56 +0530, Amit Kapila wrote:
> I have a feeling that this might also have some regression at higher
> loads (like scale_factor = 5000, shared_buffers = 8GB,
> client_count = 128, 256) for the similar reasons as bgreclaimer patch,
> means although both reduces contention around s
(2014/10/09 11:49), Etsuro Fujita wrote:
(2014/10/08 22:51), Fujii Masao wrote:
On Wed, Sep 24, 2014 at 11:10 AM, Etsuro Fujita
wrote:
On Wed, Sep 10, 2014 at 10:37 PM, Alvaro Herrera
wrote:
Fujii Masao wrote:
On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
wrote:
PENDING_LIST_CLEANUP_S
Dne 30 Říjen 2014, 10:17, David Rowley napsal(a):
> On Thu, Oct 30, 2014 at 12:48 AM, Tomas Vondra wrote:
>
>> Dne 29 Říjen 2014, 12:31, Petr Jelinek napsal(a):
>> >> I've not really gotten around to looking at the patch yet, but I'm
>> also
>> >> wondering if it would be simple include allowing f
Hello,
At Tue, 28 Oct 2014 09:05:20 -0400, Stephen Frost wrote in
<20141028130520.gl28...@tamriel.snowman.net>
> > As well, the
> > originally proposed "RoleId_or_curruser" suffers from the same issue. I'm
> > going to go out on a limb here, but is it not possible to consider
> > "current_user"
2014-10-30 9:30 GMT+01:00 Szymon Guz :
> On 30 October 2014 09:04, Pavel Stehule wrote:
>
>>
>>
>> 2014-10-29 12:23 GMT+01:00 Szymon Guz :
>>
>>>
>>>
>>> On 17 October 2014 09:01, Pavel Stehule wrote:
>>>
Hi Szymon
I found a small bug - it doesn't escape "|" well
postgre
On Thu, Oct 30, 2014 at 12:21 AM, Tomas Vondra wrote:
> Dne 29 Říjen 2014, 10:41, David Rowley napsal(a):
> > I'm quite interested in reviewing your work on this, but it appears that
> > some of your changes are not C89:
> >
> > src\backend\commands\analyze.c(3774): error C2057: expected constan
On Thu, Oct 30, 2014 at 12:48 AM, Tomas Vondra wrote:
> Dne 29 Říjen 2014, 12:31, Petr Jelinek napsal(a):
> >> I've not really gotten around to looking at the patch yet, but I'm also
> >> wondering if it would be simple include allowing functional statistics
> >> too. The pg_mv_statistic name see
At 2014-09-29 11:54:10 +0200, and...@2ndquadrant.com wrote:
>
> On 2014-09-29 14:09:01 +0530, Abhijit Menon-Sen wrote:
> >
> > I just noticed that initdb -S ("Safely write all database files to disk
> > and exit") does (only) the following in perform_fsync:
> >
> > pre_sync_fname(pdir, true);
On 30 October 2014 04:24, Amit Kapila wrote:
>> Locking the toast table of any main tables we access seems easily
>> done. Though perhaps we should make weak locking of the toast table
>> presumed. Do we have cases where the toast table can be accessed when
>> the main table is not also strong lo
On Mon, Oct 27, 2014 at 10:38 PM, Rajeev rastogi
wrote:
> On 26 October 2014 10:42, Haribabu Kommi wrote:
>> I have a question regarding setting of key flags matched. Only the
>> first key was set as matched even if we have multiple index conditions.
>> Is there any reason behind that?
>
> Actuall
On 30 October 2014 09:04, Pavel Stehule wrote:
>
>
> 2014-10-29 12:23 GMT+01:00 Szymon Guz :
>
>>
>>
>> On 17 October 2014 09:01, Pavel Stehule wrote:
>>
>>> Hi Szymon
>>>
>>> I found a small bug - it doesn't escape "|" well
>>>
>>> postgres=# select * from mytab ;
>>> a | numeric_b |
On 29 October 2014 13:04, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Wed, Oct 29, 2014 at 8:16 AM, Stephen Frost wrote:
>> > suggestions. If the user does not have table-level SELECT rights,
>> > they'll see for the "Failing row contains" case, they'll get:
>> >
>>
Thanks for your input, Jim!
On Wed, Oct 29, 2014 at 7:59 AM, Jim Nasby wrote:
> Patch applies against current HEAD and builds, but I'm getting 37 failed
> tests (mostly parallel, but also misc and WITH; results attached). Is that
> expected?
This is caused by the recent commit 7b1c2a0 (that I act
2014-10-29 12:23 GMT+01:00 Szymon Guz :
>
>
> On 17 October 2014 09:01, Pavel Stehule wrote:
>
>> Hi Szymon
>>
>> I found a small bug - it doesn't escape "|" well
>>
>> postgres=# select * from mytab ;
>> a | numeric_b | c
>> --+---+
>> Ahoj |1
97 matches
Mail list logo
