(2014/02/21 15:23), Kyotaro HORIGUCHI wrote:
NOTICE: Child foregn table child01 is affected.
NOTICE: Child foregn table child02 is affected
NOTICE: Child foregn table child03 rejected 'alter tempmin set
default'
What do you think about this? It looks a bit too loud for me
though...
I think tha
Hi,
While compiling on clang, I noticed the following warning:
pg_backup_archiver.c:1950:32: warning: comparison of constant -1 with
expression of type 'ArchiveFormat' (aka 'enum _archiveFormat') is always
false
[-Wtautological-constant-out-of-range-compare]
if ((AH->format =
Hello,
> > Then the second issue, however I don't have enough idea of how
> > ALTER TABLE works, the complexity would be reduced if acceptance
> > chek for alter "action"s would done on foreign server or data
> > wrapper side, not on the core of ALTER TABLE. It would also be a
> > help to output e
Hi,
> >> NOTICE: Child foregn table child01 is affected.
> >> NOTICE: Child foregn table child02 is affected
> >> NOTICE: Child foregn table child03 rejected 'alter tempmin set
> >> default'
> >>
> >> What do you think about this? It looks a bit too loud for me
> >> though...
> >
> > I think that'
On Fri, Feb 14, 2014 at 5:35 PM, Andres Freund wrote:
> Hi,
>
> In WalSndLoop() we do:
>
> wakeEvents = WL_LATCH_SET | WL_POSTMASTER_DEATH | WL_TIMEOUT |
> WL_SOCKET_READABLE;
>
> if (pq_is_send_pending())
> wakeEvents |= WL_SOCKET_WRITEABLE;
> else if (wal_sender_timeo
On Thu, Feb 20, 2014 at 9:00 PM, Bernd Helmle wrote:
>
>
> --On 20. Februar 2014 09:51:47 -0500 Tom Lane wrote:
>
> Yeah. The other reason that you can't just transparently change the
>> behavior is error handling: people are used to seeing either all or
>> none of the output of a query. In s
(2014/02/20 19:55), Etsuro Fujita wrote:
(2014/02/20 15:47), Kyotaro HORIGUCHI wrote:
Although my concerns here are only two points,
unanticipated application and "maintenancibility". I gave a
consideration on these issues again.
Sorry, I misunderstood what you mean by "unanticipated applicat
On Thu, Jan 30, 2014 at 11:07 AM, Andrew Dunstan wrote:
> Updated patches for both pieces. Included is some tidying done by Teodor,
> and fixes for remaining whitespace issues. This now passes "git diff --check
> master" cleanly for me.
So one thing that isn't clear from these patches is how jso
On 09/02/14 17:11, Jeremy Harris wrote:
On 06/02/14 18:21, Jeff Janes wrote:
Did you try sorting already-sorted, reverse
sorted, or pipe-organ shaped data sets? We will also need to test it on
strings. I usually use md5(random()::text) to generate strings for such
purposes, at least for a fi
On Wed, Feb 19, 2014 at 1:42 PM, Heikki Linnakangas wrote:
> On 02/19/2014 11:15 PM, Neil Thombre wrote:
>
>> And that is where I have a question. I noticed that in pg_standby.c when
>> we
>> detect the word "fast" in the trigger file we truncate the file.
>>
>> https://github.com/postgres/postgr
On Wed, Feb 19, 2014 at 08:29:38PM +0200, Marti Raudsepp wrote:
> On Sun, Feb 16, 2014 at 10:41 PM, Tom Lane wrote:
> > Shore up GRANT ... WITH ADMIN OPTION restrictions (Noah Misch)
>
> I'm not familiar with the phrase "Shore up", I think it should use
> more precise language: are the privilege
Hi,
On 2014-02-20 13:25:35 +, Greg Stark wrote:
> I have a database where a a couple rows don't appear in index scans
> but do appear in sequential scans. It looks like the same problem as
> Peter reported but this is a different database. I've extracted all
> the xlogdump records and below ar
Robert Haas escribió:
> On Thu, Feb 20, 2014 at 9:43 AM, Simon Riggs wrote:
> > The design choice of making the limit only apply to bulk ops is
> > because that is where the main problem lies. Rate limiting will cause
> > a loss of performance in the main line for non-bulk operations, so
> > addin
On 02/20/2014 04:16 PM, Robert Haas wrote:
> On Thu, Feb 20, 2014 at 9:43 AM, Simon Riggs wrote:
>> The design choice of making the limit only apply to bulk ops is
>> because that is where the main problem lies. Rate limiting will cause
>> a loss of performance in the main line for non-bulk operat
--On 20. Februar 2014 09:51:47 -0500 Tom Lane wrote:
Yeah. The other reason that you can't just transparently change the
behavior is error handling: people are used to seeing either all or
none of the output of a query. In single-row mode that guarantee
fails, since some rows might get outp
On Thu, Feb 20, 2014 at 10:10 AM, Greg Stark wrote:
> On Thu, Feb 20, 2014 at 2:43 PM, Simon Riggs wrote:
>> The design choice of making the limit only apply to bulk ops is
>> because that is where the main problem lies. Rate limiting will cause
>> a loss of performance in the main line for non-b
On Thu, Feb 20, 2014 at 9:43 AM, Simon Riggs wrote:
> The design choice of making the limit only apply to bulk ops is
> because that is where the main problem lies. Rate limiting will cause
> a loss of performance in the main line for non-bulk operations, so
> adding tests there will not be valuab
On Thu, Feb 20, 2014 at 2:43 PM, Simon Riggs wrote:
> The design choice of making the limit only apply to bulk ops is
> because that is where the main problem lies. Rate limiting will cause
> a loss of performance in the main line for non-bulk operations, so
> adding tests there will not be valuab
Marti Raudsepp writes:
> On Thu, Feb 20, 2014 at 12:07 PM, Ashutosh Bapat
> wrote:
>> That seems a good idea. We will get rid of FETCH_COUNT then, wouldn't we?
> No, I don't think we want to do that. FETCH_COUNT values greater than
> 1 are still useful to get reasonably tabulated output without
On 19 February 2014 13:28, Greg Stark wrote:
> On Mon, Jan 20, 2014 at 5:37 PM, Simon Riggs wrote:
>
>> Agreed; that was the original plan, but implementation delays
>> prevented the whole vision/discussion/implementation. Requirements
>> from various areas include WAL rate limiting for replicati
On Thu, Feb 20, 2014 at 1:45 PM, Simon Riggs wrote:
> On 19 February 2014 16:04, Robert Haas wrote:
>
>> Well, *I* don't think this is ready to go. A WAL rate limit that only
>> limits WAL sometimes still doesn't impress me.
>
> Could you be specific in your criticism? "Sometimes" wouldn't impre
On 19 February 2014 16:04, Robert Haas wrote:
> Well, *I* don't think this is ready to go. A WAL rate limit that only
> limits WAL sometimes still doesn't impress me.
Could you be specific in your criticism? "Sometimes" wouldn't impress
anybody, but we need to understand whether you are referri
2014-02-20 01:37, Tom Lane :
> Perhaps it would be acceptable to drop the btree_gist implementation
> and teach pg_upgrade to refuse to upgrade if the old database contains
> any such indexes. I'm not sure that solves the problem, though, because
> I think pg_upgrade will still fail if the opclas
I have a database where a a couple rows don't appear in index scans
but do appear in sequential scans. It looks like the same problem as
Peter reported but this is a different database. I've extracted all
the xlogdump records and below are the ones I think are relevant. You
can see that lp 2 gets a
On Thu, Feb 20, 2014 at 12:07 PM, Ashutosh Bapat
wrote:
> That seems a good idea. We will get rid of FETCH_COUNT then, wouldn't we?
No, I don't think we want to do that. FETCH_COUNT values greater than
1 are still useful to get reasonably tabulated output without hogging
too much memory. For exam
From: "Heikki Linnakangas"
Hmm, why do this only on Windows? If "postgres -C" is safe enough to run
as Administrator on Windows, why not allow running it as root on Unix as
well? Even if there's no particular need to allow it as root on Unix,
fewer #ifdefs is good.
Yes, I limited the change
On Thu, Feb 20, 2014 at 10:23 AM, Haribabu Kommi
wrote:
> On Thu, Feb 20, 2014 at 2:26 PM, Amit Kapila wrote:
>
>> On Thu, Feb 20, 2014 at 6:24 AM, Haribabu Kommi
>> wrote:
>> > On Thu, Feb 20, 2014 at 11:38 AM, Tom Lane wrote:
>> >> > I want to propose a new feature called "priority table" or "
(2014/02/20 15:47), Kyotaro HORIGUCHI wrote:
Although my concerns here are only two points,
unanticipated application and "maintenancibility". I gave a
consideration on these issues again.
Sorry, I misunderstood what you mean by "unanticipated application".
Then, I think it could be enough b
On 02/01/2014 12:28 PM, Christian Kruse wrote:
On 31/01/14 22:17, MauMau wrote:
Thanks for reviewing the patch. Fixed. I'll add this revised patch to the
CommitFest entry soon.
Looks fine for me. Set it to „waiting for commit.“
Hmm, why do this only on Windows? If "postgres -C" is safe eno
On Thu, Feb 20, 2014 at 3:26 PM, Bernd Helmle wrote:
>
>
> --On 20. Februar 2014 14:49:28 +0530 Ashutosh Bapat <
> ashutosh.ba...@enterprisedb.com> wrote:
>
> If I set some positive value for this variable, psql runs smoothly with
>> any size of data. But unset that variable, and it gets killed.
--On 20. Februar 2014 14:49:28 +0530 Ashutosh Bapat
wrote:
If I set some positive value for this variable, psql runs smoothly with
any size of data. But unset that variable, and it gets killed. But it's
nowhere written explicitly that psql can run out of memory while
collecting the result s
On 02/09/2014 12:11 PM, Alexander Korotkov wrote:
I've rebased catalog changes with last master. Patch is attached. I've
rerun my test suite with both last master ('committed') and attached
patch ('ternary-consistent').
Thanks!
method | sum
+---
Ian, Pavan,
That's correct, OS is killing the process
You are correct, the OS is killing the process
3766 Feb 20 14:30:14 ubuntu kernel: [23820.175868] Out of memory: Kill
process 34080 (psql) score 756 or sacrifice child
3767 Feb 20 14:30:14 ubuntu kernel: [23820.175871] Killed process 34080
(ps
Hi,
On 18.02.2014 22:02, Andres Freund wrote:
> Not really sure which way is better.
One dev against it, one dev not sure. Enough for me to change it :)
Will post a new patch this evening.
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development, 24x
On Thu, Feb 20, 2014 at 2:32 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
>
> May be each setup has it's own breaking point. So trying with larger
> number might reproduce the issue.
>
> I tried to debug it with gdb, but all it showed me was that psql received
> a SIGKILL signal.
2014-02-20 16:16 GMT+09:00 Ashutosh Bapat :
> Hi All,
> Here is a strange behaviour with master branch with head at
(...)
> Looks like a bug in psql to me. Does anybody see that behaviour?
It's not a bug, it's your VM's OS killing off a process which is using
up too much memory.
Check /var/log/me
I found a very simple repro on my machine
postgres=# select x, x, lpad('string', 100, x::text) from
generate_series(1, 1000) x;
Killed
So this is just about fetching huge data through psql.
But if I reduce the number of rows by 10 times, it gives result without
getting killed.
[ashutosh@ubun
On 02/20/2014 04:15 AM, Peter Geoghegan wrote:
On Wed, Feb 19, 2014 at 4:49 PM, Michael Paquier
wrote:
+1 for back-patching.
Back-patching would be interesting for existing applications, but -1
as it is a new feature :)
I think that it rises to the level of an omission in 9.3 that now
requir
I am sorry,
My Ubuntu info was wrong in previous mail, correct one as follow
>UBUNTU:
>[amul@localhost postgresql]$ uname -a
>Linux localhost.localdomain 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23
>19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
amul@amul:~/work/postgresql$ uname -a
Linux a
On 18 February 2014 21:47, MauMau Wrote:
> > We already have two different versions of make_absolute_path() in the
> > tree
> > - one in src/backend/utils/init/miscinit.c and one in
> > src/test/regress/pg_regress.c.
> >
> > I don't think we need a third one.
> >
> > If we put it in port/ like t
(2014/02/18 0:02), Dave Page wrote:
On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane wrote:
Dave Page writes:
On Fri, Feb 14, 2014 at 5:32 PM, Tom Lane wrote:
(BTW, narwhal is evidently not trying to build plpython. I wonder
why not?)
Not sure - it's certainly installed on the box. I've enable
Hi,
I tried reproduce this bug on CENTOS 6.4 as well as on UBUNTU 13.04.
My Base machine is Window 7 and CentOs, Ubuntu is in VM.
CENTOS :
[amul@localhost postgresql]$ uname -a
Linux localhost.localdomain 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23
19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linu
(Top post, on phone)
The @number part is optional. It indicates an export ordinal. (You don't want
to know, if you do, see MSDN).
If you remove them or change them then binaries linked to the older version
will fail to link to the newer; it breaks binary compat. The ordinals are part
of the li
Hello
updated patch without timetz support
Regards
Pavel
2014-02-19 21:20 GMT+01:00 Alvaro Herrera :
> Pavel Stehule escribió:
>
> > I though about it, and now I am thinking so timezone in format
> > 'Europe/Prague' is together with time ambiguous
> >
> > We can do it, but we have to expect s
44 matches
Mail list logo
