Hi,
On Mon, Jan 5, 2015 at 4:34 AM, Andres Freund and...@2ndquadrant.com wrote:
pg_receivexlog: could not create archive status file
mmm/archive_status/00010003.done: No such file or
directory
Dang. Stupid typo. And my tests didn't catch it, because I had
On Thu, Feb 12, 2015 at 11:13 AM, Andres Freund and...@2ndquadrant.com wrote:
I started getting these errors after upgrading from 9.2.8 to 9.2.10.
Is it something critical that requires version downgrade or I can just
ignore that errors?
What errors are you getting in precisely which
On Thu, Feb 12, 2015 at 11:40 AM, Andres Freund and...@2ndquadrant.com wrote:
This obviously should not be the case. I'll have a look in a couple of hours.
Until then you can likely just work around the problem by creating the
archive_status directory.
Thank you. Just let me know if you
On February 12, 2015 8:11:05 PM CET, Sergey Konoplev gray...@gmail.com wrote:
Hi,
On Mon, Jan 5, 2015 at 4:34 AM, Andres Freund and...@2ndquadrant.com
wrote:
pg_receivexlog: could not create archive status file
mmm/archive_status/00010003.done: No such file
or
directory
Hi.
This obviously should not be the case. I'll have a look in a couple of hours.
Until then you can likely just work around the problem by creating the
archive_status directory.
--
Please excuse brevity and formatting - I am writing this on my mobile phone.
Andres Freund
On 2/4/15 8:20 PM, Andrew Dunstan wrote:
On 02/04/2015 06:53 PM, Tom Lane wrote:
Or maybe use a make variable, like NO_DOC. I think that's preferable to
adding more targets.
Unless we can come up with a new target name that obviously means
world minus docs, the make-variable idea may be
On 02/11/2015 04:20 PM, Abhijit Menon-Sen wrote:
At 2015-02-11 13:20:29 +0200, hlinnakan...@vmware.com wrote:
I don't follow. I didn't change configure at all, compared to your
patch.
OK, I extrapolated a little too much. Your patch didn't actually include
crc_instructions.h;
Oh, I'm
Thanks for answer.
Now it seems to be applied correctly.
2015-02-12 3:12 GMT+04:00 Thom Brown t...@linux.com:
On 11 February 2015 at 22:50, Anastasia Lubennikova
lubennikov...@gmail.com wrote:
Finally there is a new version of patch (in attachments).
It provides multicolumn index-only scan
Andres Freund writes:
On 2015-02-12 09:31:27 +0100, Jan Urbański wrote:
That doesn't solve the problem of the Python deadlock, where you're not at
leisure to call a C function at the beginning of your module.
We could just never unload the hooks...
That's what we did before
On Thu, Feb 12, 2015 at 5:44 PM, Naoya Anzai anzai-na...@mxu.nes.nec.co.jp
wrote:
Hi, Michael-san
An updated patch is attached,
I'm sorry for confusing you.
I think you don't have to implement this code to disable this
feature with using value -2.Because this use case is a rare case,
On Thu, Feb 12, 2015 at 1:51 AM, Robert Haas robertmh...@gmail.com wrote:
I think we may want a dedicated parallel-safe property for functions
rather than piggybacking on provolatile, but that will probably also
be changeable via ALTER FUNCTION, and stored rules won't get
miraculously
On Thu, Feb 12, 2015 at 2:19 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 10, 2015 at 3:56 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2015-02-10 09:23:02 -0500, Robert Haas wrote:
On Tue, Feb 10, 2015 at 9:08 AM, Andres Freund and...@2ndquadrant.com
wrote:
As pointed
Thank you for comments. Please find attached the updated patch.
This patch fails to compile:
xlogreader.c:1049:46: error: extraneous ')' after condition, expected a
statement
blk-with_hole blk-hole_offset =
0))
This has been rectified.
Note as well
Hello, I changed the subject.
This mail is to address the point at hand, preparing for
registering this commitfest.
15 17:29:14 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote in
20150204.172914.52110711.horiguchi.kyot...@lab.ntt.co.jp
Tue, 03 Feb 2015
Ravi Kiran ravi.kolanp...@gmail.com writes:
I am sorry for the late reply, when I disabled the hash join command
enable_hashjoin=off in the postgresql.conf file, it was not working. But
I when I used the command set enable_hashjoin=off command in the back
end. It worked.
I am not able to
Jim Nasby-5 wrote
On 2/10/15 9:29 AM, Tom Lane wrote:
Ravi Kiran lt;
ravi.kolanpaka@
gt; writes:
yes sir, I did try the pg_ctl reload command, but its still using the
hash
join algorithm and not the nested loop algorithm. I even restarted the
server, even then its still using the hash
Hi,
gcc5 is lurking in Debian experimental, and it's breaking initdb.
There's bug reports for 9.1 and 9.4:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778070 (9.1)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778071 (9.4)
but I could reproduce it with 9.5devel (from last week) as well:
On Thu, Feb 12, 2015 at 3:52 PM, Amit Kapila amit.kapil...@gmail.com wrote:
Probably not, because many queries will scan multiple relations, and
we want to do all of this work just once per query.
By this, do you mean to say that if there is any parallel-unsafe
expression (function call) in
On 2/12/15 3:34 PM, Ravi Kiran wrote:
sorry for the inconvenience if caused to anyone, but as David G johnston
said, I was trying to change how the postgresql works and was not able
to figure out how it should be done. I will make sure it will be clear
from the next time. Thank you very much.
I am sorry for the late reply, when I disabled the hash join command
enable_hashjoin=off in the postgresql.conf file, it was not working. But
I when I used the command set enable_hashjoin=off command in the back
end. It worked.
I am not able to understand why it did not get disabled when I
On 2/12/15 3:20 PM, David G Johnston wrote:
Does show enable_hashjoin say it's off? If not, I think you must've
fat-fingered the postgresql.conf change somehow.
For future reference, posts like this belong on pgsql-performance.
but postgres is still using the hash join algorithm even after
On 12/2/15 18:29, Tom Lane wrote:
Ravi Kiran ravi.kolanp...@gmail.com writes:
I am sorry for the late reply, when I disabled the hash join command
enable_hashjoin=off in the postgresql.conf file, it was not working. But
I when I used the command set enable_hashjoin=off command in the back
Hi, dear pgsql-hackers
*1. environment*
*DB Master*
$ cat /etc/issue
CentOS release 6.5 (Final)
Kernel \r on an \m
$ uname -av
Linux l-x1.xx.cnx 3.14.29-3.centos6.x86_64 #1 SMP Tue Jan 20 17:48:32
CST 2015 x86_64 x86_64 x86_64 GNU/Linux
$ psql -U postgres
psql (9.3.5)
Type help for help.
Christoph Berg c...@df7cb.de writes:
gcc5 is lurking in Debian experimental, and it's breaking initdb.
Yeah, I just heard the same about Red Hat as well:
https://bugzilla.redhat.com/show_bug.cgi?id=1190978
Not clear if it's an outright compiler bug or they've just found some
creative new way
On 2/10/15 9:29 AM, Tom Lane wrote:
Ravi Kiran ravi.kolanp...@gmail.com writes:
yes sir, I did try the pg_ctl reload command, but its still using the hash
join algorithm and not the nested loop algorithm. I even restarted the
server, even then its still using the hash join algorithm
Does show
On Thu, Jan 15, 2015 at 4:05 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
We are soon entering in the money time for this CF. The last month has
been mainly a vacation period, the progress being fantomatic on many
fronts, still there are a couple of patches that are marked as ready
for
On 2/12/15 5:28 AM, Kyotaro HORIGUCHI wrote:
Hello, I changed the subject.
This mail is to address the point at hand, preparing for
registering this commitfest.
15 17:29:14 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote in
You mean that ...
Log_autovacuum_min_duration assumes a role of VACOPT_VERBOSE.
Even if this parameter never use currently for manual vacuum,
log_autovacuum_min_duration should be set zero(anytime output)
when we executes VACUUM(or ANALYZE) VERBOSE.
Is my understanding correct? If so,it
On Thu, Feb 12, 2015 at 6:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Christoph Berg c...@df7cb.de writes:
gcc5 is lurking in Debian experimental, and it's breaking initdb.
Yeah, I just heard the same about Red Hat as well:
https://bugzilla.redhat.com/show_bug.cgi?id=1190978
Not
On Sun, Feb 8, 2015 at 10:05 AM, Andreas Karlsson andr...@proxel.se wrote:
On 01/30/2015 07:48 AM, Michael Paquier wrote:
Looking at the latest patch, it seems that in
AlterTableGetLockLevel@tablecmds.c we ought to put AT_ReAddConstraint,
AT_AddConstraintRecurse and AT_ProcessedConstraint
I wrote:
Christoph Berg c...@df7cb.de writes:
gcc5 is lurking in Debian experimental, and it's breaking initdb.
Yeah, I just heard the same about Red Hat as well:
https://bugzilla.redhat.com/show_bug.cgi?id=1190978
Not clear if it's an outright compiler bug or they've just found some
On 2015-02-12 11:44:05 -0800, Sergey Konoplev wrote:
On Thu, Feb 12, 2015 at 11:40 AM, Andres Freund and...@2ndquadrant.com
wrote:
This obviously should not be the case. I'll have a look in a couple of
hours. Until then you can likely just work around the problem by creating
the
Andres Freund writes:
On 2015-02-09 18:17:14 +0100, Jan Urbański wrote:
First of all, the current behaviour is crazy. We're setting and unsetting the
locking callback every time a connection is made/closed, which is not how
OpenSSL is supposed to be used. The *application* using libpq should
On 2015-02-12 09:31:27 +0100, Jan Urbański wrote:
Andres Freund writes:
On 2015-02-09 18:17:14 +0100, Jan Urbański wrote:
First of all, the current behaviour is crazy. We're setting and unsetting
the
locking callback every time a connection is made/closed, which is not how
OpenSSL
Hi, Michael-san
An updated patch is attached,
I'm sorry for confusing you.
I think you don't have to implement this code to disable this
feature with using value -2.Because this use case is a rare case,
and there is a practical workaround using huge value like 2e9.
(You suggested 2e9 to me,
Hi all,
When calling vacuum(), there is the following assertion using VACOPT_FREEZE:
Assert((vacstmt-options VACOPT_VACUUM) ||
!(vacstmt-options (VACOPT_FULL | VACOPT_FREEZE)));
I think that this should be changed with sanity checks based on the
parameter values of freeze_* in VacuumStmt as
On 2015/02/11 4:06, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
On 2015/02/10 7:23, Dean Rasheed wrote:
Sorry, I didn't have time to look at this properly. My initial thought
is that expand_security_qual() needs to request a lock on rows coming
from the relation
On Fri, Feb 13, 2015 at 10:16 AM, Naoya Anzai
anzai-na...@mxu.nes.nec.co.jp wrote:
You mean that ...
Log_autovacuum_min_duration assumes a role of VACOPT_VERBOSE.
Even if this parameter never use currently for manual vacuum,
log_autovacuum_min_duration should be set zero(anytime output)
when
On Thu, Feb 12, 2015 at 10:07 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Feb 12, 2015 at 6:40 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
If we have to go this way, then isn't it better to evaluate the same
when we are trying to create parallel path (something like in the
sorry for the inconvenience if caused to anyone, but as David G johnston
said, I was trying to change how the postgresql works and was not able to
figure out how it should be done. I will make sure it will be clear from
the next time. Thank you very much.
@Tom lane Sir, I forgot to remove the #
On Sat, Jan 24, 2015 at 5:58 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Here's v0.5. (Why did you use that weird decimal versioning scheme? You
could just say v4 and save a couple of keystrokes). This patch makes
perfect sense to me now. I was ready to commit, but I checked the
On Sun, Nov 23, 2014 at 8:23 PM, David Rowley dgrowle...@gmail.com wrote:
As the patch stands there's still a couple of FIXMEs in there, so there's
still a bit of work to do yet.
Comments are welcome
Hm, if there is still work to do, we may as well mark this patch as
rejected as-is, also
On 2/13/15 8:52 AM, Michael Paquier wrote:
On Sun, Nov 23, 2014 at 8:23 PM, David Rowley dgrowle...@gmail.com wrote:
As the patch stands there's still a couple of FIXMEs in there, so there's
still a bit of work to do yet.
Comments are welcome
Hm, if there is still work to do, we may as well
On Thu, Dec 18, 2014 at 6:43 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Dec 16, 2014 at 3:51 AM, Simon Riggs si...@2ndquadrant.com
wrote:
Currently, WALReceiver writes and fsyncs data it receives. Clearly,
while we are waiting for an fsync we aren't doing any other useful
work.
On Thu, Jan 15, 2015 at 8:02 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
On Fri, Jan 9, 2015 at 10:51 AM, Kouhei Kaigai kai...@ak.jp.nec.com
wrote:
When custom-scan node replaced a join-plan, it shall have at least two
child plan-nodes. The callback handler of PlanCustomPath needs to
On Tue, Jan 6, 2015 at 10:51 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Jim, Thanks for your reviewing the patch.
The attached patch is revised one according to your suggestion,
and also includes bug fix I could found.
* Definitions of TIDOperator was moved to pg_operator.h
as
On Tue, Dec 23, 2014 at 9:43 AM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Dec 22, 2014 at 4:34 PM, Peter Geoghegan p...@heroku.com wrote:
To put it another way, creating a separate object obfuscates
scanRTEForColumn(), since it's the only client of
updateFuzzyAttrMatchState().
On Mon, Dec 22, 2014 at 10:26 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 19, 2014 at 8:40 AM, Petr Jelinek p...@2ndquadrant.com
wrote:
What I hope to get from this is agreement on the general approach and
protocol so that we can have common base which will both make it easier
On Thu, Jan 15, 2015 at 5:02 AM, Tomas Vondra tomas.von...@2ndquadrant.com
wrote:
Maybe we can try later again, but there's no poin in keeping this in the
current CF.
Any objections?
None, marked as rejected.
--
Michael
On Mon, Feb 2, 2015 at 10:42 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 20, 2015 at 4:01 AM, Fabien COELHO coe...@cri.ensmp.fr
wrote:
I had a look at this patch. This patch adds some text below a table
of functions. Immediately above that table, there is this existing
On Thu, Feb 12, 2015 at 4:18 PM, Andres Freund and...@2ndquadrant.com wrote:
No need for debugging. It's plain and simply a (cherry-pick) conflict I
resolved wrongly during backpatching. 9.3, 9.4 and master do not have
that problem. That whole fix was quite painful because every single
release
On Thu, Feb 12, 2015 at 3:59 AM, Robert Haas robertmh...@gmail.com wrote:
We're not seeing eye to eye here yet, since I don't accept your
example scenario and you don't accept mine. Let's keep discussing.
Meanwhile, here's an updated patch.
A lot of cool activity is showing up here, so
On Wed, Dec 17, 2014 at 5:39 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 15 December 2014 at 20:26, Jeff Janes jeff.ja...@gmail.com wrote:
I still get the compiler error in contrib:
pgstattuple.c: In function 'pgstat_heap':
pgstattuple.c:279: error: too few arguments to function
On Wed, Dec 17, 2014 at 5:35 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 16 December 2014 at 21:17, Simon Riggs si...@2ndquadrant.com wrote:
This patch is a WIP version of doing that, but only currently attempts
With the patch, XLogSendLogical uses the same logic to calculate
Hi,
On 2015-02-12 22:55:33 +0900, Tatsuo Ishii wrote:
Hi, I need help.
In 46.6.4.5 Change Callback
Note: Only changes in user defined tables that are not unlogged
(see UNLOGGED) and not temporary (see TEMPORARY or TEMP) can be
extracted using logical decoding.
I cannot parse
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 10, 2015 at 3:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, I'm not all that thrilled with the deserialized object terminology.
I found myself repeatedly tripping up on which form was serialized and
which de-. If anyone's got a better
Hi, I need help.
In 46.6.4.5 Change Callback
Note: Only changes in user defined tables that are not unlogged
(see UNLOGGED) and not temporary (see TEMPORARY or TEMP) can be
extracted using logical decoding.
I cannot parse the sentence above. Maybe logical decoding does not
On 02/06/2015 11:50 AM, Andres Freund wrote:
On 2015-02-05 16:45:50 +0200, Heikki Linnakangas wrote:
I propose the attached, which pulls all the wait-retry logic up to
secure_read() and secure_write(). This makes the code a lot more
understandable.
Generally a good idea. Especially if we get
Il 02/02/15 21:48, Robert Haas ha scritto:
On Sat, Jan 31, 2015 at 8:28 AM, Marco Nenciarini
marco.nenciar...@2ndquadrant.it wrote:
Il 30/01/15 03:54, Michael Paquier ha scritto:
On Fri, Jan 30, 2015 at 2:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
There is at least one other bug in that
On Tue, Feb 10, 2015 at 3:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I've now taken this idea as far as building the required infrastructure
and revamping a couple of array operators to use it. There's a lot yet
to do, but I've done enough to get some preliminary ideas about
performance (see
Hi, I need help.
In 46.6.4.5 Change Callback
Note: Only changes in user defined tables that are not unlogged
(see UNLOGGED) and not temporary (see TEMPORARY or TEMP) can be
extracted using logical decoding.
I cannot parse the sentence above. Maybe logical decoding does not
decode a
On Wed, Feb 11, 2015 at 12:55 PM, Thom Brown t...@linux.com wrote:
Today I witnessed a situation which appears to have gone down like this:
- The primary server starting streaming WAL data from segment 00A8 to the
standby
- The standby server started receiving that data
- Before 00A8 is
Jan Urbański writes:
Andres Freund writes:
On 2015-02-12 09:31:27 +0100, Jan Urbański wrote:
That doesn't solve the problem of the Python deadlock, where you're not at
leisure to call a C function at the beginning of your module.
We could just never unload the hooks...
That's what we
On 02/12/2015 01:33 AM, Andres Freund wrote:
On 2015-02-11 14:54:03 +0200, Heikki Linnakangas wrote:
Thoughts? Can you reproduce any errors with this?
I'm on battery right now, so I can't really test much.
Did you test having an actual standby instead of pg_receivexlog? I saw
some slightly
Hi,
I've attached an updated version of the patch. This fixes the issue on
checksum calculation for segments after the first one.
To solve it I've added an optional uint32 *segno argument to
parse_filename_for_nontemp_relation, so I can know the segment number
and calculate the block number
On Thu, Feb 12, 2015 at 12:16 AM, Noah Misch n...@leadboat.com wrote:
That is a major mark against putting the check in simplify_function(), agreed.
I do see one way to rescue that idea, which is this: put two flags,
parallelModeOK and parallelModeRequired, into PlannerGlobal. At the
beginning
Hi!
On Mon, Feb 9, 2015 at 11:52 PM, Thom Brown t...@linux.com wrote:
Google Summer of Code 2015 is approaching. I'm intending on registering
PostgreSQL again this year.
Before I do that, I'd like to have an idea of how many people are
interested in being either a student or a mentor.
On Thu, Feb 12, 2015 at 9:56 AM, Thom Brown t...@linux.com wrote:
On 12 February 2015 at 13:56, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 11, 2015 at 12:55 PM, Thom Brown t...@linux.com wrote:
Today I witnessed a situation which appears to have gone down like this:
- The
On 12 February 2015 at 13:56, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 11, 2015 at 12:55 PM, Thom Brown t...@linux.com wrote:
Today I witnessed a situation which appears to have gone down like this:
- The primary server starting streaming WAL data from segment 00A8 to the
On 12 February 2015 at 10:40, Anastasia Lubennikova lubennikov...@gmail.com
wrote:
Thanks for answer.
Now it seems to be applied correctly.
(please avoid top-posting)
Thanks for the updated patch. I can confirm that it now cleanly applies
and compiles fine. I've run the tested in the SQL
On Thu, Feb 12, 2015 at 9:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
My first thought is that we should form some kind of TOAST-like
backronym, like Serialization Avoidance Loading and Access Device
(SALAD) or Break-up, Read, Edit, Assemble, and Deposit (BREAD). I
don't think there is anything
On 12 February 2015 at 16:40, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 02/12/2015 12:40 PM, Anastasia Lubennikova wrote:
Thanks for answer.
Now it seems to be applied correctly.
* Documentation is missing.
Anastasia provided a documentation patch in the first email.
Thom
On Thu, Feb 12, 2015 at 3:07 PM, Thom Brown t...@linux.com wrote:
On 12 February 2015 at 16:40, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 02/12/2015 12:40 PM, Anastasia Lubennikova wrote:
Thanks for answer.
Now it seems to be applied correctly.
* Documentation is missing.
On 02/12/2015 12:40 PM, Anastasia Lubennikova wrote:
Thanks for answer.
Now it seems to be applied correctly.
Thanks, it would be great to get this completed.
This still leaks memory with the same test query as earlier. The leak
seems to be into a different memory context now; it used to be
On Thu, Feb 12, 2015 at 6:40 AM, Amit Kapila amit.kapil...@gmail.com wrote:
If we have to go this way, then isn't it better to evaluate the same
when we are trying to create parallel path (something like in the
parallel_seq scan patch - create_parallelscan_paths())?
Probably not, because many
On Wed, Feb 11, 2015 at 3:21 PM, Robert Haas robertmh...@gmail.com wrote:
I think we may want a dedicated parallel-safe property for functions
rather than piggybacking on provolatile ...
I went through the current contents of pg_proc and tried to assess how
much parallel-unsafe stuff we've got.
On 2/3/15 11:00 AM, Robert Haas wrote:
Crazy ideas: Could we make wal_level something other than
PGC_POSTMASTER? PGC_SIGHUP would be nice... Could we, maybe, even
make it a derived value rather than one that is explicitly configured?
Like, if you set max_wal_senders0, you automatically get
77 matches
Mail list logo