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
> >prob
Jim Nasby 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 the code so that we ask
mariem 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 you insistent on extrac
On Wed, Nov 5, 2014 at 2:56 PM, Heikki Linnakangas
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 up
> * both
On Sat, Sep 13, 2014 at 11:02 PM, Fabrízio de Royes Mello
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 this patch:
1) Reading it
On Wed, Nov 5, 2014 at 5:36 PM, philip taylor 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
>
> http://docs.aws.amazon.com/redshift/latest/dg/JS
On Thu, Oct 30, 2014 at 5:19 PM, Michael Paquier
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 index_concurrent_swap to
ensure that the
>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
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:
http://postgresql.1045698.n5.nab
On Mon, Nov 3, 2014 at 11:44 AM, Adam Brightwell
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 consensus on this one yet and I di
On Sun, Nov 2, 2014 at 7:31 AM, Simon Riggs 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
attached it here as
On 11/05/2014 05:41 PM, Michael Paquier wrote:
> On Thu, Nov 6, 2014 at 10:00 AM, Greg Stark wrote:
>> On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus wrote:
>>> When the recovery_target_time is reached, switch to streaming
>>> replication and stay a standby.
>>
>> Then shouldn't he just not specify
On Thu, Nov 6, 2014 at 10:41 AM, Michael Paquier
wrote:
> On Thu, Nov 6, 2014 at 10:00 AM, Greg Stark wrote:
>> On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus wrote:
>>> When the recovery_target_time is reached, switch to streaming
>>> replication and stay a standby.
>>
>> Then shouldn't he just n
On Thu, Nov 6, 2014 at 10:00 AM, Greg Stark wrote:
> On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus 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 behavi
On 11/05/2014 05:00 PM, Greg Stark wrote:
> On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus 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 s
On Tue, Nov 4, 2014 at 6:48 PM, Tom Lane 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 accidentall
Thanks for the review.
On Wed, Nov 5, 2014 at 4:33 PM, Andreas Karlsson 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 a common funct
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
On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus 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
recovery_target i
* 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 sur
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 (an
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* a
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.
I
On 06/11/14 00:42, Robert Haas wrote:
On Mon, Nov 3, 2014 at 2:14 PM, Álvaro Hernández Tortosa
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 d
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 (AF
On Thu, Nov 6, 2014 at 5:41 AM, Peter Eisentraut 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
different t
On Mon, Nov 3, 2014 at 2:14 PM, Álvaro Hernández Tortosa
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
> transaction. Thi
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 CH
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 poin
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 Be
On Wed, Nov 5, 2014 at 12:54 PM, Alvaro Herrera
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 with some rows no longer be
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
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 wr
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 on
>>> 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
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 u
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 a/
On 11/5/14, 3:42 PM, Kevin Grittner wrote:
philip taylor 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.
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
wher
philip taylor 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 to go through
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.
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 c
On Mon, Oct 27, 2014 at 5:15 PM, Peter Geoghegan 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 those
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 st
Jim Nasby 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 transaction" as soon as
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 t
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:
http://www.postgresql.org/mailpref/pgsql
Jim Nasby 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 systems wouldn't have to
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 d
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 NextXID
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/04/2014 04:04 PM, Marko Tiikkaja wrote:
> On 11/5/14, 12:59 AM, Tom Lane wrote:
>> Marko Tiikkaja 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 p
On Wed, Nov 5, 2014 at 8:36 AM, Jim Nasby 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 abbreviated
keys (hope
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 Tue, Nov 4, 2014 at 2:28 PM, Alvaro Herrera
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 you see anything wron
On Nov 5, 2014 5:27 PM, "Kevin Grittner" wrote:
>
> Tom Lane 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 11/05/2014 10:10 AM, Tom Lane wrote:
Andrew Dunstan 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_coer
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 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
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: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).
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
Tom Lane 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:
http://www.postgresql.org/m
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 t
Magnus Hagander 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 second to last?
>
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 pg_stat_re
Andrew Dunstan 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 than
>> taki
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, up
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
client
2014-11-04 22:16 GMT+07:00 Peter Eisentraut :
>
> 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 s
On 11/04/2014 01:45 PM, Tom Lane wrote:
Andrew Dunstan 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
also use it twice.
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 col
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 form
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,
th
On Wed, Nov 5, 2014 at 5:24 PM, Anssi Kääriäinen
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 think it should also
2014-11-04 22:16 GMT+07:00 Peter Eisentraut :
> 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 small mo
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() sta
On 11/05/2014 09:06 AM, Amit Kapila wrote:
1.
+XLogRecPtr
+XLogInsert(RmgrId rmid, uint8 info, XLogRecData *rdata)
{
..
+ /* info's high bits are reserved for use by me */
+ if (info & XLR_INFO_MASK)
+ elog(PANIC, "invalid xlog info mask %02X", info);
..
}
Earlier before this check, we use to ch
Hello,
> Adam Brightwell writes:
> > FWIW, I found the following in the archives:
>
> > http://www.postgresql.org/message-id/15516.1038718...@sss.pgh.pa.us
>
> > Now this is from 2002 and it appears it wasn't necessary to change at the
> > time, but I haven't yet found anything else related (it
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
80 matches
Mail list logo
