On 02/13/2014 08:44 AM, Kyotaro HORIGUCHI wrote:
Wouldn't it be better to not archive the old segment, and instead
switch
to a new segment after writing the end-of-recovery checkpoint, so that
the segment on the new timeline is archived sooner?
It would be better to zero-fill and switch
Hi all,
On 02/12/2014 08:27 PM, Greg Stark wrote:
On Wed, Feb 12, 2014 at 6:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
For what it's worth I've confirmed the bug in wal-e caused the initial
problem.
Huh? Bug in wal-e? What bug?
WAL-E actually didn't
Dear all,
I need help to send hint message to erreport() in call_string_check_hook
function [src/backend/utils/misc/guc.c:8092]
In call_string_check_hook(), following parameter are resets
/* Reset variables that might be set by hook */
8100 GUC_check_errcode_value =
On 02/12/2014 01:24 PM, Christoph Berg wrote:
Re: Heikki Linnakangas 2014-01-13 52d3caff.3010...@vmware.com
Actually, why is the partially-filled 00010002 file
archived in the first place? Looking at the code, it's been like that
forever, but it seems like a bad idea. If the
Amul,
On Thu, Feb 13, 2014 at 5:59 PM, amul sul sul_a...@yahoo.co.in wrote:
I have basic questions,
1. Condition testing of GUC_check_errdetail_string or other GUC_* is
needed, even if we resting it?
A few lines before this conditional test, there is a call to the hook
function (using the
I think what you're arguing is that we should see WAL records filling the
rest of segment 1 before we see any references to segment 2, but if that's
the case then how did we get into the situation you reported? Or is it
just that it was a broken base backup to start with?
The scenario I
Hello Hackers,
I work on a foreign data wrapper for a legacy system. I generally find the hook
system very useful and flexible way to extend Postgres.
The post parse analyze hook almost fits what I need, but I have a few use cases
where I would need to tap right into the parsed queries but
On Thu, Feb 13, 2014 at 10:20:46AM +0530, Amit Kapila wrote:
Why not *only* prefix/suffix?
To represent prefix/suffix match, we atleast need a way to tell
that the offset and len of matched bytes and then how much
is the length of unmatched bytes we have copied.
I agree that a simpler
eFrom: Andres Freund and...@2ndquadrant.com
could you try if you get more readable dumps by using disassemble/m?
That might at least print line numbers if you have debug info installed.
Please find the attached file. I hope this will reveal something.
Regards
MauMau
Dump of assembler code
On Wed, Feb 12, 2014 at 10:53 PM, Peter Eisentraut pete...@gmx.net wrote:
On 2/12/14, 4:34 PM, Magnus Hagander wrote:
On Wed, Feb 12, 2014 at 10:28 PM, Peter Eisentraut pete...@gmx.net
mailto:pete...@gmx.net wrote:
On 2/12/14, 12:47 PM, Magnus Hagander wrote:
Since there were
Hello, I might have been misunderstood your words.
At Thu, 13 Feb 2014 10:11:22 +0200, Heikki Linnakangas
hlinnakan...@vmware.com wrote in 52fc7e2a.9060...@vmware.com
On 02/13/2014 08:44 AM, Kyotaro HORIGUCHI wrote:
Wouldn't it be better to not archive the old segment, and instead
switch
Hi Febien,
Thank you very much for your very detail and useful comments!
I read your comment, I agree most of your advice:)
Attached patch is fixed for your comment. That are...
- Remove redundant long-option.
- We can use --gaussian=NUM -S or --gaussian=NUMN -N options.
- Add sentence in
See the discussion of Custom-Scan API.
https://commitfest.postgresql.org/action/patch_view?id=1282
I believe my third patch is what you really want to do...
This rewritten query would be handled by the FDW table that I previously
added to the catalog.
The reason I want this new hook is that
On 02/13/2014 01:37 PM, Kyotaro HORIGUCHI wrote:
At Thu, 13 Feb 2014 10:11:22 +0200, Heikki Linnakangas hlinnakan...@vmware.com
wrote in 52fc7e2a.9060...@vmware.com
On 02/13/2014 08:44 AM, Kyotaro HORIGUCHI wrote:
Wouldn't it be better to not archive the old segment, and instead
switch
to a
Re: Heikki Linnakangas 2014-02-13 52fc9468.4050...@vmware.com
With 9.1, it works, but 9.2 and 9.3 don't archive anything until I
remove the test ! -f part. (An alternative fix would be to declare
the behavior ok and adjust that example in the config.)
Hmm, the behavior is the same in 9.1 and
Sorry, previos attached patch has small bug.
Please use latest one.
134 - return min + (int64) (max - min + 1) * rand;
134 + return min + (int64)((max - min + 1) * rand);
Regards,
--
Mitsumasa KONDO
NTT Open Source Software Center
*** a/contrib/pgbench/pgbench.c
---
Thanks for the link.
I want flexibility. Here is a situation: my hook knows the size of tableA and
tableB on the legacy side. It should be able to decide wether to offload the
join/filter onto the legacy side or not. At the same time it can start
transferring the data to real Postgres tables
On 02/13/2014 02:42 PM, Christoph Berg wrote:
Re: Heikki Linnakangas 2014-02-13 52fc9468.4050...@vmware.com
With 9.1, it works, but 9.2 and 9.3 don't archive anything until I
remove the test ! -f part. (An alternative fix would be to declare
the behavior ok and adjust that example in the
On 02/12/2014 06:10 PM, Ants Aasma wrote:
On Wed, Feb 12, 2014 at 4:04 PM, knizhnik knizh...@garret.ru wrote:
Even if reordering was not done by compiler, it still can happen while
execution.
There is no warranty that two subsequent assignments will be observed by all
CPU cores in the same
On Thu, Feb 13, 2014 at 4:10 AM, Bruce Momjian br...@momjian.us wrote:
On Thu, Oct 3, 2013 at 06:50:57AM +0200, Magnus Hagander wrote:
On Oct 3, 2013 2:47 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Wed, Oct 2, 2013 at 11:31 PM, Magnus Hagander mag...@hagander.net
wrote:
Re: Heikki Linnakangas 2014-02-13 52fcca40.3060...@vmware.com
I was testing this with streaming replication; 9.1 and 9.2 behave
the same in that scenario. But they differ when doing archive
recovery.
Is this an argument for back-patching the don't archive last
segment from old timeline
On 02/13/2014 03:53 PM, Christoph Berg wrote:
Is removing the test ! -f part and hence overwriting files in the
archive safe, i.e. are the files the same?
No. Not in general, anyway. If the old master keeps running, even for a
moment, after the partial file was copied, it will have created
On Wed, Feb 12, 2014 at 06:06:40PM -0500, Bruce Momjian wrote:
On Wed, Sep 11, 2013 at 02:10:45PM -0400, Robert Haas wrote:
On Tue, Sep 10, 2013 at 11:33 PM, Noah Misch n...@leadboat.com wrote:
I'm thinking to preserve postmaster.pid at immediate shutdown in all
released
versions, but
Re: Heikki Linnakangas 2014-02-13 52fcd02c.3060...@vmware.com
Is removing the test ! -f part and hence overwriting files in the
archive safe, i.e. are the files the same?
No. Not in general, anyway. If the old master keeps running, even
for a moment, after the partial file was copied, it
On 02/13/2014 04:07 PM, Christoph Berg wrote:
Re: Heikki Linnakangas 2014-02-13 52fcd02c.3060...@vmware.com
Is removing the test ! -f part and hence overwriting files in the
archive safe, i.e. are the files the same?
No. Not in general, anyway. If the old master keeps running, even
for a
On 2/13/14, 6:25 AM, Magnus Hagander wrote:
Are you sure you made that test after my fixup patch (the one suggested
by Andres)? Because that one was at least supposed to add signal.h...
works now
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Feb10, 2014, at 17:38 , Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-10 11:11:28 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
So what we need to do is to acquire a write barrier between the
assignments to lwWaitLink and lwWaiting, i.e.
On 02/12/2014 04:04 PM, Heikki Linnakangas wrote:
On 02/12/2014 10:50 PM, Andres Freund wrote:
On February 12, 2014 9:33:38 PM CET, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-12 14:39:37 -0500, Andrew Dunstan wrote:
On investigation I found
On Mon, Oct 7, 2013 at 08:43:27AM -0700, David Fetter wrote:
On Mon, Oct 07, 2013 at 07:51:44AM -0400, Andrew Dunstan wrote:
Given that we have not supported releases older than 8.3 for quite a
while, do we need to keep this in extend.sgml any longer?
caution
para
On 02/13/2014 05:40 PM, Andrew Dunstan wrote:
On 02/12/2014 04:04 PM, Heikki Linnakangas wrote:
On 02/12/2014 10:50 PM, Andres Freund wrote:
On February 12, 2014 9:33:38 PM CET, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-12 14:39:37 -0500,
On 02/13/2014 02:42 PM, Heikki Linnakangas wrote:
The behavior where we prefer a segment from archive with lower TLI over
a file with higher TLI in pg_xlog actually changed in commit
a068c391ab0. Arguably changing it wasn't a good idea, but the problem
your test script demonstrates can be fixed
While reading through src/backend/storage/buffer/README and looking at
the code that it describes, I noticed that the case is wrong for
nextVictimBuffer.
It's no big deal really, but the attached trivial patch makes the README
match the code.
--
Vik
*** a/src/backend/storage/buffer/README
---
On 02/13/2014 10:58 AM, Heikki Linnakangas wrote:
Perhaps we should use a lock to enforce that only one process tries to
clean up the pending list at a time.
Is that going to serialize all these inserts?
It will serialize the cleanup process, which moves entries from the
pending list to
On 2014-02-12 17:40:44 -0300, Alvaro Herrera wrote:
Also, AutoVacOpts (used as part of reloptions) gained three extra
fields. Since this is in the middle of StdRdOptions, it'd be somewhat
more involve to put these at the end of that struct. This might be a
problem if somebody has a
Please can someone tell me why this behavior? Thx!!
I know it's calculating over coordinates on same points, but the operations
of values (all double precision) differs even forcing with cast
(*) Here some double precision calculations and obtaining values
#Select
#
=?ISO-8859-1?Q?Daniel_V=E1zquez?= daniel2d2...@gmail.com writes:
Please can someone tell me why this behavior? Thx!!
You're confusing numeric and double precision; in particular this
calculation is *not* being done in float8, but numeric:
# select (0.766238989559398 * 0.766238989559398 * 1 +
Andres Freund escribió:
On 2014-02-12 17:40:44 -0300, Alvaro Herrera wrote:
Also, AutoVacOpts (used as part of reloptions) gained three extra
fields. Since this is in the middle of StdRdOptions, it'd be somewhat
more involve to put these at the end of that struct. This might be a
Alvaro Herrera escribió:
Yes, that's what I did --- see the attached patch, which I would apply
on top of the code for master and would be only in 9.3.
(Of course, these changes affect other parts of the code, in particular
autovacuum.c and reloptions.c. But that's not important here).
--
On 02/13/2014 06:47 PM, Heikki Linnakangas wrote:
On 02/13/2014 02:42 PM, Heikki Linnakangas wrote:
The behavior where we prefer a segment from archive with lower TLI over
a file with higher TLI in pg_xlog actually changed in commit
a068c391ab0. Arguably changing it wasn't a good idea, but the
On 2014-02-13 14:40:39 -0300, Alvaro Herrera wrote:
Andres Freund escribió:
On 2014-02-12 17:40:44 -0300, Alvaro Herrera wrote:
Also, AutoVacOpts (used as part of reloptions) gained three extra
fields. Since this is in the middle of StdRdOptions, it'd be somewhat
more involve to
Amit Langote amitlangot...@gmail.com writes:
On Thu, Feb 13, 2014 at 5:59 PM, amul sul sul_a...@yahoo.co.in wrote:
2. Can I pass hint message in above ereport(), how?
It could be done by setting the check hook related global variable
GUC_check_errhint_string inside your hook function.
You
Greg Stark st...@mit.edu writes:
I think what you're arguing is that we should see WAL records filling the
rest of segment 1 before we see any references to segment 2, but if that's
the case then how did we get into the situation you reported? Or is it
just that it was a broken base backup to
On Thu, Feb 13, 2014 at 7:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The scenario I could come up with that didn't require a broken base backup
was that there was an earlier truncate or vacuum. So the sequence is high
offset reference, truncate, growth, crash. All possibly on a single
database.
David Beck db...@starschema.net writes:
I have table like data structures in the source system for the FDW I work on.
These tables are sometimes too big and the source system is able to filter
and join them with limitations, thus it is not optimal to transfer the data
to Postgres.
At the
On Fri, Oct 11, 2013 at 03:39:51PM -0700, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
On 10/11/2013 01:11 PM, Bruce Momjian wrote:
In summary, I think we need to:
* decide on new defaults for work_mem and maintenance_work_mem
* add an initdb flag to allow
Alvaro Herrera escribió:
So here are two patches -- the first one, for 9.3 and HEAD, introduce
the new aging variables and use them throughout vacuum and autovacuum,
including per-table options; the second one adjusts the struct
declarations to avoid the ABI break in VacuumStmt and
dig...@126.com writes:
select t, t::bytea from convert_from('\xeec1', 'sql_ascii') as g(t);
[ fails to check that string is valid in database encoding ]
Hm, yeah. Normal input to the database goes through pg_any_to_server(),
which will apply a validation step if the source encoding is
Heikki Linnakangas hlinnakan...@vmware.com writes:
Perhaps we should use a lock to enforce that only one process tries to
clean up the pending list at a time.
Something like the attached? Can somebody who's seen this problem confirm
this improves matters?
(ginInsertCleanup's header comment
Alvaro Herrera escribió:
So here are two patches -- the first one, for 9.3 and HEAD, introduce
the new aging variables and use them throughout vacuum and autovacuum,
including per-table options; the second one adjusts the struct
declarations to avoid the ABI break in VacuumStmt and
On 2014-02-13 16:15:42 -0500, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
Perhaps we should use a lock to enforce that only one process tries to
clean up the pending list at a time.
Something like the attached? Can somebody who's seen this problem confirm
this
I noticed that current pgindent wants to do this to a recently-added
comment in psql/copy.c:
*** handleCopyIn(PGconn *conn, FILE *copystr
*** 627,633
/*
* This code erroneously assumes '\.'
on a
On Thu, Feb 13, 2014 at 06:14:17PM -0500, Tom Lane wrote:
I noticed that current pgindent wants to do this to a recently-added
comment in psql/copy.c:
*** handleCopyIn(PGconn *conn, FILE *copystr
*** 627,633
/*
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-13 16:15:42 -0500, Tom Lane wrote:
Something like the attached? Can somebody who's seen this problem confirm
this improves matters?
Hm. Won't that possiby lead to the fast tuple list growing unboundedly?
I think we would need to at
On 2014-02-13 18:49:21 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-13 16:15:42 -0500, Tom Lane wrote:
Something like the attached? Can somebody who's seen this problem confirm
this improves matters?
Hm. Won't that possiby lead to the fast tuple list
Greg Stark st...@mit.edu writes:
On Thu, Feb 13, 2014 at 7:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That's what's bothering me, too. On the other hand, if we can't think of
a scenario where it'd be necessary to replay the high-offset update, then
I'm disinclined to mess with the code
On Sun, Feb 9, 2014 at 2:22 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Sat, Jan 11, 2014 at 2:47 AM, Peter Eisentraut pete...@gmx.net wrote:
On Sat, 2014-01-11 at 00:48 -0200, Fabrízio de Royes Mello wrote:
Now, if bdr is installed but the validation doesn't happen
MauMau maumau...@gmail.com writes:
If the backend is terminated with SIGKILL while psql is running \copy
table_name from file_name, the \copy didn't end forever. I expected \copy
to be cancelled because the corresponding server process vanished.
I just noticed this CF entry pertaining to
(2014/02/13 9:51), Hiroshi Inoue wrote:
(2014/02/12 12:28), Inoue, Hiroshi wrote:
(2014/02/12 8:30), Tom Lane wrote:
I wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
I tried MINGW port with the attached change and successfully built
src and contrib and all pararell regression tests were OK.
Hiroshi Inoue in...@tpf.co.jp writes:
Rebuild with --disable-auto-import causes errors in contrib on
both machines. Errors occur in pg_buffercache, pg_stat_statements,
postgres_fdw and test_shm_mq.
Yeah, that's the idea: we want to get the same failures as on MSVC.
I'm going to put in
Greetings Hackers.
I'm aware of how a pg_hba.conf file can refer to other files for
including @lists of users, etc.
But there is currently no support for being able to pull in entire file
segments as can be done for postgresql.conf via the include directive.
In the environment that I'm
On Wed, Oct 16, 2013 at 02:17:11PM -0400, Bruce Momjian wrote:
You can see the UTF8 case is fine because \n is considered greater
than space, but in the C locale, where \n is less than space, the
false return value shows the problem with
internal_bpchar_pattern_compare() trimming the
On Thu, Feb 13, 2014 at 08:24:27PM -0600, Jerry Sievers wrote:
Greetings Hackers.
I'm aware of how a pg_hba.conf file can refer to other files for
including @lists of users, etc.
But there is currently no support for being able to pull in entire file
segments as can be done for
On Sun, 2014-01-19 at 15:31 +0100, Stefan Kaltenbrunner wrote:
/* followings are for client encoding only */
PG_SJIS,/* Shift JIS
(Winindows-932) */
while you have that file open: s/Winindows-932/Windows-932 maybe?
done
--
Sent
On Tue, Jan 7, 2014 at 12:33:33PM +0530, Amit Kapila wrote:
On Thu, Oct 31, 2013 at 8:58 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Wed, Oct 16, 2013 at 1:44 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Tue, Oct 15, 2013 at 6:28 PM, Magnus Hagander mag...@hagander.net
Bruce Momjian wrote:
On Thu, Feb 13, 2014 at 08:24:27PM -0600, Jerry Sievers wrote:
Greetings Hackers.
I'm aware of how a pg_hba.conf file can refer to other files for
including @lists of users, etc.
But there is currently no support for being able to pull in entire file
segments
I hadn't noticed this thread. I will give this a look. Thanks for
providing a patch.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Bruce Momjian wrote:
On Thu, Feb 13, 2014 at 08:24:27PM -0600, Jerry Sievers wrote:
Greetings Hackers.
I'm aware of how a pg_hba.conf file can refer to other files for
including @lists of users, etc.
But there is currently no
On 14/02/14 00:49, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-13 16:15:42 -0500, Tom Lane wrote:
Something like the attached? Can somebody who's seen this problem confirm
this improves matters?
Hm. Won't that possiby lead to the fast tuple list growing
68 matches
Mail list logo
