ids and timestamps so the data changes constantly.
This is of course based on the BDR work Andres, Craig and myself have
been doing.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
diff --git a/contrib/lrep/Makefile b
busy
schedule right now though, can it wait till next week? - I will post
some code documentation patches then.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers
row count estimation - given the dynamic
nature of parameters I think for we'll need to let the sampling method
do this, so there will have to be fifth function in the API.
- ruleutils support (it needs a bit of code in get_from_clause_item
function)
- docs are sparse at the moment
--
Petr
On 11/12/14 00:24, Petr Jelinek wrote:
Hello,
Attached is a basic implementation of TABLESAMPLE clause. It's SQL
standard clause and couple of people tried to submit it before so I
think I don't need to explain in length what it does - basically returns
random sample of a table using
this patch does that, along with the rename to recovery_target_action
and addition to the recovery.conf.sample.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml
On 08/12/14 02:03, Michael Paquier wrote:
On Mon, Dec 8, 2014 at 9:59 AM, Petr Jelinek p...@2ndquadrant.com wrote:
Ok this patch does that, along with the rename to recovery_target_action and
addition to the recovery.conf.sample.
This needs a rebase as at least da71632 and b8e33a8
On 08/12/14 02:06, Petr Jelinek wrote:
On 08/12/14 02:03, Michael Paquier wrote:
On Mon, Dec 8, 2014 at 9:59 AM, Petr Jelinek p...@2ndquadrant.com
wrote:
Ok this patch does that, along with the rename to
recovery_target_action and
addition to the recovery.conf.sample.
This needs a rebase
time for that, I will try to
setup something later...
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
CommitTransaction) time so the definition of
latest commit is last CommitTransaction call.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 04/12/14 12:26, Heikki Linnakangas wrote:
On 12/04/2014 01:16 PM, Petr Jelinek wrote:
On 04/12/14 10:42, Heikki Linnakangas wrote:
On 12/03/2014 04:54 PM, Alvaro Herrera wrote:
ir commit timestamp directly as they commit,
or an external transaction c
Sorry, I'm late to the party
On 02/12/14 18:59, Robert Haas wrote:
On Fri, Nov 28, 2014 at 11:59 AM, Petr Jelinek p...@2ndquadrant.com wrote:
I'm a bit late to the party, but wouldn't
recovery_target_action = ...
have been a better name for this? It'd be in line with the other
recovery_target_* parameters, and also a bit
that the custom columns for AM
approach prohibits future storage changes.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 03/12/14 15:54, Alvaro Herrera wrote:
Pushed with some extra cosmetic tweaks.
Cool, thanks!
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On 28/11/14 17:46, Alex Shulgin wrote:
Christoph Berg c...@df7cb.de writes:
Re: Petr Jelinek 2014-11-25 5474efea.2040...@2ndquadrant.com
Patch committed.
Before I go and rebase that recovery.conf - GUC patch on top of
this... is it final?
I think so, perhaps sans the name mentioned
discomforting.
I solved it for xids that are out of range by returning -infinity and
then changing that to NULL in sql interface, but no idea how to do that
for aborted transactions.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
On 25/11/14 16:30, Alvaro Herrera wrote:
Petr Jelinek wrote:
On 25/11/14 16:23, Alvaro Herrera wrote:
Robert Haas wrote:
Maybe 0 should get translated to a NULL return, instead of a bogus timestamp.
That's one idea --- surely no transaction is going to commit at 00:00:00
on 2000-01-01
timestamps that refer to the same xid and can
subtract to give us an exact replication lag.
Won't the pg_last_committed_xact() on slave + pg_xact_commit_timestamp()
on master with the xid returned by slave accomplish the same thing?
--
Petr Jelinek http://www
to do that.
Implemented.
Patch committed.
Thanks!
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
/test/something/commit_ts). Not sure what the something could
be, maybe something like standalone as those tests get their own pg
instance?
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing
record is found it's used to overwrite
the commit timestamp/nodeid for given xid.
Also, there is exactly one record in SLRU for each xid so there is no
point in making the SQL interfaces return multiple results.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL
On 19/11/14 12:20, Simon Riggs wrote:
On 19 November 2014 02:12, Petr Jelinek p...@2ndquadrant.com wrote:
Maybe we need better explanation of the LSN use-case(s) to understand why it
should be stored here and why the other solutions are significantly worse.
We should apply the same standard
On 19/11/14 14:13, Simon Riggs wrote:
On 18 November 2014 22:05, Petr Jelinek p...@2ndquadrant.com wrote:
OK, promote works for me as well, I attached patch that changes continue to
promote so you don't have to find and replace everything yourself. The
changed doc wording probably needs
to tell the difference between a crashed Startup
process and this usage.
As long as we can tell, I don't mind how we do it.
Suggestions please.
Different exit code?
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via
and will finish renaming the recovery.conf to recovery.done,
bumping timeline etc, and we don't want that since that prevents
resuming recovery in the future.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via
On 19/11/14 19:51, Simon Riggs wrote:
On 19 November 2014 16:11, Petr Jelinek p...@2ndquadrant.com wrote:
We need to be able to tell the difference between a crashed Startup
process and this usage.
As long as we can tell, I don't mind how we do it.
Suggestions please.
Different exit code
fun for someone, who
intensive use this pattern.
Personally, I see this as natural extension of the conditional block
control which we already have for loops with CONTINUE WHEN and EXIT
WHEN. This basically extends it to any block and it seems quite natural
to have it for me...
--
Petr
On 18/11/14 12:57, Simon Riggs wrote:
On 31 October 2014 15:18, Petr Jelinek p...@2ndquadrant.com wrote:
Attached is the v2 of the patch with the review comments addressed (see
below).
...
Done, there is now action_at_recovery_target which can be set to either
pause, continue or shutdown
table instead of SLRU - as people want to use it as filter in
WHERE clause, somebody mentioned exporting to different db, etc.
Maybe we need better explanation of the LSN use-case(s) to understand
why it should be stored here and why the other solutions are
significantly worse.
--
Petr
On 13/11/14 07:04, Michael Paquier wrote:
On Wed, Nov 12, 2014 at 10:06 PM, Petr Jelinek p...@2ndquadrant.com wrote:
Brief list of changes:
- the commit timestamp record now stores timestamp, lsn and nodeid
Now that not only the commit timestamp is stored, calling that commit
timestamp
us to do something that would be impossible otherwise.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 10/11/14 14:53, Robert Haas wrote:
On Mon, Nov 10, 2014 at 8:39 AM, Petr Jelinek p...@2ndquadrant.com wrote:
I did the calculation above wrong btw, it's actually 20 bytes not 24 bytes
per record, I am inclined to just say we can live with that.
If you do it as 20 bytes, you'll have to do
that dropping is allowed. Accordingly, the
attached patch should do it.
Yup, this patch seems to be much better and safer fix.
I can confirm that it works fine with both the test-case and my original
upgrade script. Thanks!
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL
On 09/11/14 23:36, Petr Jelinek wrote:
On 09/11/14 23:04, Tom Lane wrote:
I suspect this is actually a bug in the dependency search logic in DROP.
Don't have the energy to chase it right now though.
Yes that's where I started searching also and yes it is. The actual
situation
about it does not have either?
But anyway this patch is targeting extensions not DBAs - you could write
extension that will provide that feature on top of this patch (although
given what I wrote above I don't see how it's useful).
--
Petr Jelinek http://www.2ndQuadrant.com
On 09/11/14 17:57, Steve Singer wrote:
On 11/07/2014 07:07 PM, Petr Jelinek wrote:
The list of what is useful might be long, but we can't have everything
there as there are space constraints, and LSN is another 8 bytes and I
still want to have some bytes for storing the origin or whatever you
.
That's more useful than you'd think; if, by default, we make them fail,
and with an error messages such as
DDL request failed as it was not submitted using slonik DDL TOOL
You can do that already, it's even the example in the event trigger
documentation.
--
Petr Jelinek
instead of column/type one
- or record dependency between the column and extension for ALTER
TABLE ADD COLUMN and ALTER TABLE ALTER COLUMN TYPE statements
Thoughts?
Oh and btw looking at the code I think there is same issue with
column/collation dependencies.
--
Petr Jelinek
it when I looked manually
(I didn't use pg_describe_object).
But the problem with the extension persists, I will try to dig more to
find what is the real cause.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql
there, but that's not
exactly super pretty solution.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On 09/11/14 20:47, Heikki Linnakangas wrote:
On 11/08/2014 01:57 AM, Petr Jelinek wrote:
My main problem is actually not with having tuple per-seqAM, but more
with the fact that Heikki does not want to have last_value as compulsory
column/parameter. How is the new AM then supposed to know where
On 08/11/14 03:05, Robert Haas wrote:
On Fri, Nov 7, 2014 at 7:07 PM, Petr Jelinek p...@2ndquadrant.com wrote:
but we can't have everything there
as there are space constraints, and LSN is another 8 bytes and I still want
to have some bytes for storing the origin or whatever you want to call
On 08/11/14 03:10, Robert Haas wrote:
On Fri, Nov 7, 2014 at 7:26 PM, Petr Jelinek p...@2ndquadrant.com wrote:
My main problem is actually not with having tuple per-seqAM, but more
with the fact that Heikki does not want to have last_value as compulsory
column/parameter. How is the new AM
On 06/11/14 11:22, Craig Ringer wrote:
On 11/05/2014 05:01 AM, Petr Jelinek wrote:
I guess I could port BDR sequences to this if it would help (once we
have bit more solid agreement that the proposed API at least
theoretically seems ok so that I don't have to rewrite it 10 times if at
all
for the namespace and four for the actual
data. That's roughly how it works for advisory locks already.
I am not sure how would this solve problem of 2 extensions using the
extradata given that there can be only 1 record per txid anyway.
--
Petr Jelinek http://www.2ndQuadrant.com
besides replication just
like commit timestamps do.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
it there, as that's the one I personally have biggest
use-case for.
So this would be ~24bytes per txid already, hmm I wonder if we can pull
some tricks to lower that a bit.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via
On 08/11/14 00:57, Petr Jelinek wrote:
On 08/11/14 00:45, Robert Haas wrote:
On Nov 5, 2014, at 5:43 PM, Petr Jelinek p...@2ndquadrant.com wrote:
I don't see how to make that work with ALTER SEQUENCE USING to be
honest and I do care quite a lot about that use-case (I think the
ability
On 05/11/14 13:45, Heikki Linnakangas wrote:
On 11/04/2014 11:01 PM, Petr Jelinek wrote:
On 04/11/14 13:11, Heikki Linnakangas wrote:
On 10/13/2014 01:01 PM, Petr Jelinek wrote:
Only the alloc and reloptions methods are required (and implemented by
the local AM).
The caching, xlog writing
On 05/11/14 18:32, Heikki Linnakangas wrote:
On 11/05/2014 05:07 PM, Petr Jelinek wrote:
On 05/11/14 13:45, Heikki Linnakangas wrote:
In fact, if the seqam manages the current value outside the database
(e.g. a remote seqam that gets the value from another server),
nextval() never needs
On 04/11/14 13:11, Heikki Linnakangas wrote:
On 10/13/2014 01:01 PM, Petr Jelinek wrote:
Hi,
I rewrote the patch with different API along the lines of what was
discussed.
Thanks, that's better.
It would be good to see an alternative seqam to implement this API, to
see how it really works
On 04/11/14 09:05, Andres Freund wrote:
On 2014-11-02 19:27:25 +0100, Petr Jelinek wrote:
Well, Michael has point that the extradata is pretty much useless currently,
perhaps it would help to add the interface to set extradata?
Only accessible via C and useless aren't the same thing. But sure
be
consistent.
Most actually don't AFAICS.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On 04/11/14 09:25, Michael Paquier wrote:
On Tue, Nov 4, 2014 at 5:05 PM, Andres Freund and...@2ndquadrant.com
mailto:and...@2ndquadrant.com wrote:
On 2014-11-02 19:27:25 +0100, Petr Jelinek wrote:
Well, Michael has point that the extradata is pretty much useless
currently
On 04/11/14 22:20, Peter Eisentraut wrote:
On 11/3/14 5:17 PM, Petr Jelinek wrote:
Please don't name anything committs. That looks like a misspelling of
something.
There is nothing wrong with
pg_get_transaction_commit_timestamp()
If you want to reduce the length, lose the get.
I am fine
transaction metadata table.
Well, Michael has point that the extradata is pretty much useless
currently, perhaps it would help to add the interface to set extradata?
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent
are different though, one tests that the default (off) works
as expected the contrib one tests that the feature when turned on works
as expected. Since we can only set config values for contrib tests I
don't see how else to do this, but I am open to suggestions.
--
Petr Jelinek http
On 01/11/14 12:19, Petr Jelinek wrote:
Hi,
thanks for review.
On 01/11/14 05:45, Michael Paquier wrote:
Now here are a couple of comments at code level, this code seems not
enough baked for a commit:
1) The following renaming should be done:
- pg_get_transaction_committime
that is discussed in separate thread.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
overhead might be small, but it is most certainly not zero,
and people shouldn't be paying for it unless they need it.
Agreed, that's why it stayed 'off' in my version too.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent
Hi,
Attached is the v2 of the patch with the review comments addressed (see
below).
On 29/10/14 21:08, Petr Jelinek wrote:
On 29/10/14 20:27, Asif Naeem wrote:
1. It seems that following log message need to be more descriptive about
reason for shutdown i.e
Hi,
On 28/10/14 13:25, Simon Riggs wrote:
On 13 October 2014 10:05, Petr Jelinek p...@2ndquadrant.com 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
doubt that I'll have
time to do in depth review in this CF.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
, because either
nobody's using this yet, in which case back-patching it won't break
anything, or somebody is, in which case we'll cause less pain by
breaking it before release than a year on. But I don't care that much
either way, so I'll defer if others disagree.
+1
--
Petr Jelinek
be used as hot standby anymore and I
consider that an important feature to have.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
than perfect error message, but I really don't think it's worth the
trouble to have special handling for it as the message coming from the
server is clear enough IMHO.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
-no_synchronized_snapshots)
AH-sync_snapshot_id = get_synchronized_snapshot(AH);
And remove the else if for the if (dumpsnapshot) part.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers
better suggestion, if we
went with one of these, I would prefer taking the route of renaming the
dsm_keep_mapping to dsm_unregister_mapping.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing
why this should
be required to work cross version really.
Loading of the modules by bgworker is probably bigger issue than just
GUCs, and I think it's out of scope for the current patch(set).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
in the UPDATE? That seems like quite a bad
idea.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
to. DBA can turn off logging (and the plugin)
altogether or change logging config but we'd get the shutdown log when
that happens so 10.2.2 and 10.2.6 will be fulfilled in that case I think.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
On 16/10/14 13:29, Pavel Stehule wrote:
Hi
2014-10-14 22:57 GMT+02:00 Petr Jelinek p...@2ndquadrant.com
Short review of the patch. Note that this has nothing to do with
actual assertions, at the moment it's just enhancement of RAISE
statement to make it optionally conditional. As I
create untrusted-language functions
I often needed more granularity there (plproxy).
commands/functioncmds.c
execute DO blocks with untrusted languages
I am not sure if this is significantly different from untrusted-language
functions.
--
Petr Jelinek http://www
On 16/10/14 13:44, Stephen Frost wrote:
* Petr Jelinek (p...@2ndquadrant.com) wrote:
On 15/10/14 07:22, Stephen Frost wrote:
First though, the new privileges, about which the bikeshedding can
begin, short-and-sweet format:
BACKUP:
pg_start_backup()
pg_stop_backup
the snapshot as input parameter? I am not sure how much I like pg_dump
creating the slot. I am aware that you need to have the replication
connection open but that's IMHO just matter of scripting it together.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development
still get asynchronous transactions).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
for this feature.
Did some manual testing, seems to work as advertised.
There are no docs at the moment which is the only show-stopper that I
can see so far.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql
On 09/09/14 19:05, Petr Jelinek wrote:
Hi,
I worked bit on this patch to make it closer to committable state.
There are several bugs fixed, including ones mentioned by Jamie (writing
WAL during recovery).
Also support for pg_resetxlog/pg_upgrade has been implemented by Andres.
I added simple
is good enough for the review now, so I am adding it to October
commitfest.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
diff --git a/src/backend/access/Makefile b/src/backend/access/Makefile
index c32088f..aea4a14 100644
wants to
review. Still needs docs.
I'd like to see this one when it's updated since I lost track a little
about how the changes looks like exactly.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql
of INSERT (at least I haven't seen any
proposal that I would consider sane from the user point of view).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
connection configuration, it can get the it from the
output plugin as part of wire protocol, it can generate it based on some
internal logic, etc.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers
of solution is bad,
I don't know of any change that would invalidate the reasons for
deciding that way so I don't see why they would suddenly become
acceptable...
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent
resembling correct output.
I vote for ripping it out. There really isn't any justification for it
and it broke more than once.
Even though I really like YAML I say +1, mainly because any YAML 1.2
parser should be able to parse JSON output without problem...
--
Petr Jelinek
struct.
The reason for this is that _copyCreateEventTrigStmt uses
COPY_SCALAR_FIELD on eventname instead of COPY_STRING_FIELD.
Attached patch fixes this and also the same issue in
_equalCreateEventTrigStmt.
This should be back-patched to 9.3 where event triggers were introduced.
--
Petr
.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 16/09/14 14:17, Andres Freund wrote:
On 2014-09-15 01:38:52 +0200, Petr Jelinek wrote:
There is also more needed than this, you need:
- int64 value - first value allocated (value to be returned)
- int64 nvalues - number of values allocated
- int64 last - last cached value (used for cached
to get a new batch. The AM returns the new batch,
and updates its private state as necessary. Then the backend code
updates the relation file with the new values and the AM's private data.
WAL-logging and checkpointing is the backend's responsibility.
Agreed here.
--
Petr Jelinek
On 10/09/14 13:13, Fujii Masao wrote:
On Wed, Sep 10, 2014 at 1:45 AM, Petr Jelinek p...@2ndquadrant.com wrote:
Hi,
I recently wanted several times to have slave server prepared at certain
point in time to reduce the time it takes for it to replay remaining WALs
(say I have pg_basebackup -x
(*pq_flush_hook)(void);
Btw you forgot to remove the above.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
/ posted a new version of the patch
Except that the patch status was not updated, whis makes it really
difficult to spot patches that currently need a review :-(
I think that still means patch is 'waiting for author' as author is
responsible for changing this.
--
Petr Jelinek
discussion).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
usecase.
Otherwise I like the patch, and I am glad you also made the GUC
save/restore infrastructure.
Please don't forget to add this to next commitfest.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql
will still be able to continue
WAL replay if needed later or can be configured to start standalone.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml/recovery
contrib module to cover
both off and on settings.
The SLRU issue Heikki mentioned should be also gone mainly thanks to
638cf09e7 (I did test it too).
One notable thing missing is documentation for the three SQL level
interfaces provided, I plan to add that soon.
--
Petr Jelinek
On 09/09/14 18:49, Robert Haas wrote:
On Tue, Sep 9, 2014 at 12:33 PM, Petr Jelinek p...@2ndquadrant.com wrote:
I am also not sure that I like the pq_redirect_to_shm_mq being directly
exposed for use in bgworker, what I would like is to have elog interface to
which you tell that you want errors
On 09/09/14 22:48, Robert Haas wrote:
On Tue, Sep 9, 2014 at 1:18 PM, Petr Jelinek p...@2ndquadrant.com wrote:
I think that's completely wrong. As the patch series demonstrates,
it's not limited to propagating ErrorResponse and NoticeResponse. It
can also propagate NotifyResponse
On 04/09/14 21:16, Pavel Stehule wrote:
I did a review of last patch
Thanks
I found only one issue - float8 path has no own test in regress tests.
When this issue will be fixed, I will mark this patch as ready for commit
Ah yeah I forgot about those, fixed in attached patch.
--
Petr
that part of the thread and personally I disliked all the
other suggested names more than width_bucket.
Same here, that's why I didn't change it.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers
On 05/09/14 14:35, Jan Wieck wrote:
On 09/05/2014 04:40 AM, Pavel Stehule wrote:
Adding a WHEN clause to RAISE would have the benefit of not needing any
new keywords at all.
RAISE EXCEPTION 'format' [, expr ...] WHEN row_count 1;
+1
--
Petr Jelinek http://www
?
I am not sure if we care, probably not.
Anyway I attached patch that I am happy with. I am not yet sure what to
do with naming.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
diff --git a/doc/src/sgml/func.sgml b/doc
901 - 1000 of 1148 matches
Mail list logo
