On Tue, 2014-11-04 at 23:43 -0600, Jim Nasby wrote:
I'm worried about 2 commits in the same microsecond on the same
system, not on 2 different systems. Or, put another way, if we're
going to expose this I think it should also provide a guaranteed
unique commit ordering for a single cluster.
On 2014-11-04 18:33:34 +0200, 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 XLogInsertRecData() staying in
On Wed, Nov 5, 2014 at 5:24 PM, Anssi Kääriäinen anssi.kaariai...@thl.fi
wrote:
On Tue, 2014-11-04 at 23:43 -0600, Jim Nasby wrote:
I'm worried about 2 commits in the same microsecond on the same
system, not on 2 different systems. Or, put another way, if we're
going to expose this I
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, updating the page, etc is handled by backend,
Michael Paquier wrote:
Now, do we really want this feature in-core? That's somewhat a duplicate of
what is mentioned here:
http://www.postgresql.org/message-id/CAB7nPqQMq=4ejak317mxz4has0i+1rslbqu29zx18jwlb2j...@mail.gmail.com
Of course both things do not have the same coverage as the former
Hi,
I am working on something that requires representing a SRF return column in
pg_proc and being able to retrieve it, retrieve the name of the column and
make a ColumnRef node from it.
The catch here are aliases:
SELECT generate_series(1,100) AS a ORDER BY a;
I need to know that the return
On 11/04/2014 01:45 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
here's a patch for a utility function to look up the cast function for
a from/to pair of types, as recently suggested by Alvaro. Although it
only contains one use (in json.c), the upcoming jsonb generators would
2014-11-04 22:16 GMT+07:00 Peter Eisentraut pete...@gmx.net:
On 10/6/14 10:24 PM, Ali Akbar wrote:
While reviewing the patch myself, i spotted some formatting problems in
the code. Fixed in this v5 patch.
Also, this patch uses context patch format (in first versions, because
of the
There's a thread over in pgsql-admin
http://www.postgresql.org/message-id/flat/1317404836.812502.1415174912912.javamail.ya...@jws11120.mail.ir2.yahoo.com
suggesting that the server-side autocommit GUC causes more confusion
than it's worth, because newbies think it should reflect the state of
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,
Andrew Dunstan and...@dunslane.net writes:
On 11/04/2014 01:45 PM, Tom Lane wrote:
In short, I'd rather see this addressed through functions with slightly
higher-level APIs that are capable of covering more cases. In most cases
it'd be best if callers were using find_coercion_pathway() rather
http://www.postgresql.org/docs/9.3/static/monitoring-stats.html, table 27-1.
Can somebody find or explain the order of the views in there? It's not
actually alphabetical, but it's also not logical. In particular, what
is pg_stat_replication doing second to last?
I would suggest we move
Magnus Hagander mag...@hagander.net writes:
http://www.postgresql.org/docs/9.3/static/monitoring-stats.html, table 27-1.
Can somebody find or explain the order of the views in there? It's not
actually alphabetical, but it's also not logical. In particular, what
is pg_stat_replication doing
On 11/5/14, 6:10 AM, Michael Paquier wrote:
In addition, I wonder if this feature would be misused. Record
transaction ids to a table to find out commit order (use case could be
storing historical row versions for example). Do a dump and restore on
another cluster, and all the
Tom Lane t...@sss.pgh.pa.us wrote:
ISTM that by now we could just flat-out remove it.
+1
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 11/5/14, 10:30 AM, Andres Freund wrote:
Except that commit time is not guaranteed unique *even on a single
system*. That's my whole point. If we're going to bother with all the
commit time machinery it seems really silly to provide a way to
uniquely order every commit.
Well. I think that's
On 2014-11-05 10:23:15 -0600, Jim Nasby wrote:
On 11/5/14, 6:10 AM, Michael Paquier wrote:
In addition, I wonder if this feature would be misused. Record
transaction ids to a table to find out commit order (use case could be
storing historical row versions for example). Do a
On 10/10/14, 7:26 PM, Peter Geoghegan wrote:
Both Robert and Heikki expressed dissatisfaction with the fact that
B-Tree index builds don't use sortsupport. Because B-Tree index builds
cannot really use the onlyKey optimization, the historic oversight
of not supporting B-Tree builds (and CLUSTER)
On 2014-11-05 10:34:40 -0600, Jim Nasby wrote:
On 11/5/14, 10:30 AM, Andres Freund wrote:
Except that commit time is not guaranteed unique *even on a single
system*. That's my whole point. If we're going to bother with all the
commit time machinery it seems really silly to provide a way to
On 11/4/14, 6:11 PM, Álvaro Hernández Tortosa wrote:
Should we improve then the docs stating this more clearly? Any objection
to do this?
If we go that route we should also mention that now() will no longer be doing
what you probably hope it would (AFAIK it's driven by BEGIN and not the
On 11/05/2014 10:10 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/04/2014 01:45 PM, Tom Lane wrote:
In short, I'd rather see this addressed through functions with slightly
higher-level APIs that are capable of covering more cases. In most cases
it'd be best if callers
On Nov 5, 2014 5:27 PM, Kevin Grittner kgri...@ymail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
ISTM that by now we could just flat-out remove it.
+1
+1.
I thought we had already removed it years ago :-)
/Magnus
On Tue, Nov 4, 2014 at 2:28 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
I was clearly too careless about testing the xlog code --- it had
numerous bugs. This version should be a lot better, but there might be
problems lurking still as I don't think I covered it all. Let me know
if
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 to write a WAL record.
Sure it does, you need to
On Wed, Nov 5, 2014 at 8:36 AM, Jim Nasby jim.na...@bluetreble.com wrote:
Did anything ever happen with this?
I consider this to be related to the abbreviated keys stuff, although
it is clearly independently valuable (so it could be reviewed
independently). Since Robert ran out of time to work
On 11/04/2014 04:04 PM, Marko Tiikkaja wrote:
On 11/5/14, 12:59 AM, Tom Lane wrote:
Marko Tiikkaja ma...@joh.to writes:
So I got into thinking whether it would make sense to provide a new
function, say, to_char_at_timezone() to solve this problem. For
example:
...
Any thoughts? The patch
On 11/5/14, 7:36 PM, Josh Berkus wrote:
On 11/04/2014 04:04 PM, Marko Tiikkaja wrote:
In my example, the input is a timestamptz, and the output is converted
to the target time zone the same way timestamptz_out() does, except
based on the input timezone instead of TimeZone.
Not sure whether it
On 11/3/14, 7:40 PM, Josh Berkus wrote:
On 11/03/2014 05:24 PM, Josh Berkus wrote:
BTW, the reason I started poking into this was a report from a user that
they have a pg_multixact directory which is 21GB in size, and is 2X the
size of the database.
Here's XID data:
Latest checkpoint's
On 11/05/2014 10:40 AM, Jim Nasby wrote:
On 11/3/14, 7:40 PM, Josh Berkus wrote:
On 11/03/2014 05:24 PM, Josh Berkus wrote:
BTW, the reason I started poking into this was a report from a user that
they have a pg_multixact directory which is 21GB in size, and is 2X the
size of the database.
Jim Nasby jim.na...@bluetreble.com wrote:
for a single system AIUI all we need to do is expose the LSN of
each commit record and that will give you the exact and unique
order in which transactions committed.
This isn't a hypothetical feature either; if we had this,
logical replication
On 11/4/14 10:50 PM, Michael Paquier wrote:
Except pg_upgrade, are there other tests using bash?
There are a few obscure things under src/test/.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 11/5/14 10:57 AM, Tom Lane wrote:
However, should we consider the possibility of changing the table to
straight alphabetical ordering? I'm not as much in love with that
approach as some folks, but it does have the merit that it's always clear
where you ought to put a new item.
Yes, I
Jim Nasby jim.na...@bluetreble.com wrote:
If we go that route we should also mention that now() will no
longer be doing what you probably hope it would (AFAIK it's
driven by BEGIN and not the first snapshot).
There is also the fact that pg_stat_activity shows a connection as
being idle in
On 10/30/2014 09:19 PM, Andres Freund wrote:
Some things I noticed while reading the patch:
A lot of good comments, but let me pick up just two that are related:
* There's a couple record types (e.g. XLOG_SMGR_TRUNCATE) that only
refer to the relation, but not to the block number. These
On Mon, Oct 27, 2014 at 5:15 PM, Peter Geoghegan p...@heroku.com wrote:
Let's see if we can link these two thoughts.
1. You think the biggest problem is the lack of attention to the design.
2. I keep asking you to put the docs in a readable form.
If you can't understand the link between
On 10/31/14 6:19 AM, Simon Riggs wrote:
Various ways of tweaking Foreign Keys are suggested that are helpful
for larger databases.
*INITIALLY NOT ENFORCED
FK created, but is not enforced during DML.
Will be/Must be marked NOT VALID when first created.
We can run a VALIDATE on the
Hackers,
do you think we should implement some of the functions offered by Amazon Redshift?
http://docs.aws.amazon.com/redshift/latest/dg/c_SQL_functions.html
Amazon Redshift is completely based on PostgreSQL, but they have implemented some features not currently available in PostgreSQL.
philip taylor philta...@mail.com wrote:
do you think we should implement some of the functions offered by
Amazon Redshift?
http://docs.aws.amazon.com/redshift/latest/dg/c_SQL_functions.html
Well, obviously we already have many of the functions linked from
that page. I think that if you want
On 11/5/14, 2:43 PM, Peter Eisentraut wrote:
On 11/5/14 10:57 AM, Tom Lane wrote:
However, should we consider the possibility of changing the table to
straight alphabetical ordering? I'm not as much in love with that
approach as some folks, but it does have the merit that it's always clear
On 11/5/14, 3:42 PM, Kevin Grittner wrote:
philip taylor philta...@mail.com wrote:
do you think we should implement some of the functions offered by
Amazon Redshift?
http://docs.aws.amazon.com/redshift/latest/dg/c_SQL_functions.html
Well, obviously we already have many of the functions
Attached is two separate patches to address previous
comments/recommendations:
* superuser-cleanup-shortcuts_11-5-2014.patch
* has_privilege-cleanup_11-5-2014.patch
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git
On 11/05/2014 11:23 AM, Jim Nasby wrote:
Except that commit time is not guaranteed unique *even on a single
system*. That's my whole point. If we're going to bother with all the
commit time machinery it seems really silly to provide a way to
uniquely order every commit.
Clearly trying to
do you think we should implement some of the functions offered by
Amazon Redshift?
http://docs.aws.amazon.com/redshift/latest/dg/c_SQL_functions.html
Well, obviously we already have many of the functions linked from
that page. I think that if you want to go through them and pick
out a few
On 2014-11-05 23:08:31 +0200, Heikki Linnakangas wrote:
On 10/30/2014 09:19 PM, Andres Freund wrote:
Some things I noticed while reading the patch:
A lot of good comments, but let me pick up just two that are related:
* There's a couple record types (e.g. XLOG_SMGR_TRUNCATE) that only
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 to
On 2014-11-05 17:17:05 -0500, Steve Singer wrote:
It isn't just 'replication' systems that have a need for getting the commit
order of transactions on a single system. I have a application (not slony)
where we want to query a table but order the output based on the transaction
commit order of
On Wed, Nov 5, 2014 at 12:54 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Thanks for the updated patch.
Now when I run the test program (version with better error reporting
attached), it runs fine until I open a psql session and issue:
reindex table foo;
Then it immediately falls over
On 11/05/2014 02:36 PM, philip taylor wrote:
Ok, this is a summary of what they have that we don't (of course, I could
have missed something):
I can't see any functions on that list I'd want.
For example, DATEADD is there just to be compatible with MSSQL. It's
useless to us.
--
Josh
9.4 introduced a function numeric_normalize() whose charter is to
produce a string representing a numeric, such that two numerics' string
representations will compare equal if and only if the numeric values
compare equal. (This is used, so far, only by GIN indexes on JSONB.)
Thomas Fanghaenel
Hi,
git branch also available at:
http://git.postgresql.org/gitweb/?p=users/rhaas/postgres.git;a=shortlog;h=refs/heads/chash2014
A minor review of this:
* Should be rebased ontop of the atomics API
* In benchmarks it becomes apparent that the dynamic element width makes
some macros like
On Mon, Nov 3, 2014 at 2:14 PM, Álvaro Hernández Tortosa a...@8kdata.com
wrote:
Given a transaction started with BEGIN (REPEATABLE READ |
SERIALIZABLE), if a concurrent session commits some data before *any* query
within the first transaction, that committed data is seen by the
On Thu, Nov 6, 2014 at 5:41 AM, Peter Eisentraut pete...@gmx.net wrote:
On 11/4/14 10:50 PM, Michael Paquier wrote:
Except pg_upgrade, are there other tests using bash?
There are a few obscure things under src/test/.
Oh, I see. There is quite a number here, and each script is doing quite
On 05/11/14 17:46, Jim Nasby wrote:
On 11/4/14, 6:11 PM, Álvaro Hernández Tortosa wrote:
Should we improve then the docs stating this more clearly? Any
objection to do this?
If we go that route we should also mention that now() will no longer
be doing what you probably hope it would
On 06/11/14 00:42, Robert Haas wrote:
On Mon, Nov 3, 2014 at 2:14 PM, Álvaro Hernández Tortosa a...@8kdata.com
wrote:
Given a transaction started with BEGIN (REPEATABLE READ |
SERIALIZABLE), if a concurrent session commits some data before *any* query
within the first transaction,
On 11/05/2014 05:43 PM, Andres Freund wrote:
On 2014-11-05 17:17:05 -0500, Steve Singer wrote:
Imo that's essentially a different feature. What you essentially would
need here is a 'commit sequence number' - but no timestamps. And
probably to be useful that number has to be 8 bytes in itself.
Hackers,
Someone brought me an issue that recovery_target_time and standby_mode
weren't working as they expected. I think that the way they work now
makes sense, but we do need to clarify it in the docs. However, I'm
posting this to hackers first in case the way these two work together
*isn't*
On 10/11/2014 02:26 AM, Peter Geoghegan wrote: Both Robert and Heikki
expressed dissatisfaction with the fact that
B-Tree index builds don't use sortsupport. Because B-Tree index builds
cannot really use the onlyKey optimization, the historic oversight
of not supporting B-Tree builds (and
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think there's no choice but to fix this in 9.4. The only reason
it even needs discussion is that this would invalidate index entries
in beta testers' JSONB GIN indexes, such that queries would not find
entries that they did find before. I'm not sure
On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus j...@agliodbs.com wrote:
When the recovery_target_time is reached, switch to streaming
replication and stay a standby.
Then shouldn't he just not specify a recovert_target at all? That's
the default behaviour for standby_mode on, the whole point of
On 11/5/14, 6:04 PM, Álvaro Hernández Tortosa wrote:
On 05/11/14 17:46, Jim Nasby wrote:
On 11/4/14, 6:11 PM, Álvaro Hernández Tortosa wrote:
Should we improve then the docs stating this more clearly? Any objection
to do this?
If we go that route we should also mention that now() will
Thanks for the review.
On Wed, Nov 5, 2014 at 4:33 PM, Andreas Karlsson andr...@proxel.se wrote:
I looked at the changes to the code. The new code is clean and there is more
code re-use and improved readability. On possible further improvement would
be to move the preparation of SortSupport to
On Tue, Nov 4, 2014 at 6:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
An alternative that just occurred to me is to put the no-volatile-
I/O-functions check into CREATE TYPE, but make it just WARNING not
ERROR. That would be nearly as good as an ERROR in terms of nudging
people who'd
On 11/05/2014 05:00 PM, Greg Stark wrote:
On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus j...@agliodbs.com wrote:
When the recovery_target_time is reached, switch to streaming
replication and stay a standby.
Then shouldn't he just not specify a recovert_target at all? That's
the default
On Thu, Nov 6, 2014 at 10:00 AM, Greg Stark st...@mit.edu wrote:
On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus j...@agliodbs.com wrote:
When the recovery_target_time is reached, switch to streaming
replication and stay a standby.
Then shouldn't he just not specify a recovert_target at all?
On Thu, Nov 6, 2014 at 10:41 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Nov 6, 2014 at 10:00 AM, Greg Stark st...@mit.edu wrote:
On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus j...@agliodbs.com wrote:
When the recovery_target_time is reached, switch to streaming
replication and
On 11/05/2014 05:41 PM, Michael Paquier wrote:
On Thu, Nov 6, 2014 at 10:00 AM, Greg Stark st...@mit.edu wrote:
On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus j...@agliodbs.com wrote:
When the recovery_target_time is reached, switch to streaming
replication and stay a standby.
Then shouldn't
On Sun, Nov 2, 2014 at 7:31 AM, Simon Riggs si...@2ndquadrant.com wrote:
The procgloballist stuff should be the subject of a separate patch
which I agree with.
Yes, I think that's probably a net improvement in robustness quite
apart from what we decide to do about any of the rest of this. I've
On Mon, Nov 3, 2014 at 11:44 AM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com wrote:
That said, I don't feel very strongly about that position, so if you and
Robert (and others on the thread) agree that's the right approach then
I'll see about getting it done.
We haven't reached
wrote:
I don't think SQL can express the information the plan contains. For
example,
join methods (hash, nest loop, merge).
I don't need the way the query will be executed, so there is no need for
(hash, nest loop, merge).
--
View this message in context:
May be you want to check how it's done in Postgres-XC. Postgres-XC works on
plans being created by PostgreSQL and reverse-engineers queries (for
parts of the plans which are shippable.) The notions of shippability
may not be of interest to you, but the code to reverse-engineer most of
the plan
On Thu, Oct 30, 2014 at 5:19 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Updated patch is attached.
Please find attached an updated patch with the following things changed:
- Addition of tab completion in psql for all new commands
- Addition of a call to WaitForLockers in
On Wed, Nov 5, 2014 at 5:36 PM, philip taylor philta...@mail.com wrote:
do you think we should implement some of the functions offered by
Amazon Redshift?
http://docs.aws.amazon.com/redshift/latest/dg/c_SQL_functions.html
JSON Functions
On Sat, Sep 13, 2014 at 11:02 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
Patch rebased and added to commitfest [1].
It looks like a good thing to remove ATChangeIndexesPersistence, this
puts the persistence switch directly into reindex process.
A couple of minor comments about
On Wed, Nov 5, 2014 at 2:56 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 11/05/2014 09:06 AM, Amit Kapila wrote:
2.
XLogRecPtr
XLogInsertRecord(XLogRecData *rdata, XLogRecPtr fpw_lsn)
So the scenario is that:
* XLogRecordAssemble decides that a page doesn't need to be backed
mariem mariem.benfad...@gmail.com writes:
I don't think SQL can express the information the plan contains. For example,
join methods (hash, nest loop, merge).
I don't need the way the query will be executed, so there is no need for
(hash, nest loop, merge).
If you don't need that, why are
Jim Nasby jim.na...@bluetreble.com writes:
Hmm... we do have transaction_timestamp(); perhaps we could leave that as the
time BEGIN executed and shift everything else to use the snapshot time.
It's not possible to take a timestamp that *exactly* matches the snapshot
time. We could rearrange
On 2014-11-05 19:31:52 -0500, Steve Singer wrote:
On 11/05/2014 05:43 PM, Andres Freund wrote:
On 2014-11-05 17:17:05 -0500, Steve Singer wrote:
Imo that's essentially a different feature. What you essentially would
need here is a 'commit sequence number' - but no timestamps. And
probably to
77 matches
Mail list logo
