date:20140602

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

2014-06-02 Thread Robert Haas

On Wed, May 28, 2014 at 8:22 AM, ash a...@commandprompt.com wrote:
 None of that involves answering hypothetical questions; but what you
 want to do does, and that I think is the problem in a nutshell.

 In a nutshell I'd like PostgreSQL to just re-parse the *current* view
 definition.  Should that throw an error, user intervention will be
 required anyway, but most of the time it should just work.

What exactly do you mean by re-parse the current view definition?
The only form of the view definition we actually have is already
parsed into an internal form (see pg_rewrite) which, for the reasons
I've attempted to explain, is not easy to adapt to new column types.
I suppose we could deparse that definition and then reparse the
results, but that could lead to some very surprising consequences
(some of which are security-relevant).

-- 
Robert Haas
EnterpriseDB: 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/mailpref/pgsql-hackers

Re: [HACKERS] replication protocol documentation inconsistencies

2014-06-02 Thread Robert Haas

On Wed, May 28, 2014 at 6:51 PM, Andres Freund and...@2ndquadrant.com wrote:
 On 2014-05-21 07:29:53 -0400, Peter Eisentraut wrote:
 Looking at
 http://www.postgresql.org/docs/devel/static/protocol-replication.html
 under START_REPLICATION it goes

 
 The payload of each CopyData message from server to the client contains
 a message of one of the following formats:

 If a slot's name is provided via slotname, it will be updated as
 replication progresses so that the server knows which WAL segments - and
 if hot_standby_feedback is on which transactions - are still needed by
 the standby.

 XLogData (B)
 ...

 Primary keepalive message (B)
 ...
 

 That second paragraph was inserted recently and doesn't make sense
 there.  It should be moved somewhere else.

 Hm. I am not sure why it doesn't make sense there? It's about the SLOT
 $slotname parameter to START_REPLICATION?

I think it would probably read better if we added that into the first
paragraph about START_REPLICATION, instead of having it down at the
end.  i.e. Instructs server to start streaming WAL, starting at WAL
position XXX/XXX. If TIMELINE option is specified, streaming starts on
timeline tli; otherwise, the server's current timeline is selected.
The server can reply with an error, e.g. if the requested section of
WAL has already been recycled.  On success, server responds with a
CopyBothResponse message, and then starts to stream WAL to the
frontend.  If a slot's name is provided via slotname, it will be
updated as replication progresses so that the server knows which WAL
segments - and if hot_standby_feedback is on which transactions - are
still needed by the standby.

This bit here:

The payload of each CopyData message from server to the client
contains a message of one of the following formats:

...is followed by a colon and needs to immediately proceed the list to
which it refers.

 More generally, it is weird that the message formats are described
 there, even though the rest of the protocol documentation only mentions
 the messages by name and then describes the formats later
 (http://www.postgresql.org/docs/devel/static/protocol-message-types.html
 and
 http://www.postgresql.org/docs/devel/static/protocol-message-formats.html).
  For example, the meaning of the (B) code isn't described until two
 sections later.

 I am not sure that makes sense. These messages cannot be sent as
 toplevel messages - they're just describing the contents of the CopyBoth
 stream after START_REPLICATION has begun. It seems wierd to add these
 'subprotocol' messages to the toplevel protocol description.

I see your point, but I think Peter has a good point, too.  It would
be weird to document this mini-protocol mixed in with the main
protocol, and it's so short that adding a separate section for it
hardly makes sense, but it's still strange to have the mini-protocol
being documented before we've explained our conventions for how we
document wire protocol messages.  Forward references are best avoided,
especially implicit ones.

-- 
Robert Haas
EnterpriseDB: 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/mailpref/pgsql-hackers

Re: [HACKERS] Documenting the Frontend/Backend Protocol update criteria

2014-06-02 Thread Koichi Suzuki

Jan Urbański made a presentation titled 'Postgres on the wire',
subtitle 'A look at the PostgreSQL wire protocol'. I hope this
covers some of your interest. Presentation slide deck is available
at
http://www.pgcon.org/2014/schedule/attachments/330_postgres-for-the-wire.pdf

Hope it helps;
---
Koichi Suzuki

2014-06-02 7:22 GMT+09:00 Mikko Tiihonen mikko.tiiho...@nitorcreations.com:
Hi,

Currently the criteria on updating the F/B protocol is undefined. This makes
it hard to update the protocol going forward. It makes it also hard to write
library/driver/application implementations that will be more future proof to
future server versions.

Ideally the documentation for 9.4 (backport?) would say what kind of things
are allowed to change within the v3 protocol, and thus implies what kind of
changes need a new v4 protocol. Is there some wishlist page of items to do
differently for v4 already?

I did find the following text in the documentation: binary representations
for complex data types might change across server versions. But having more
specific rules would help, especially since it seems to be there just to
scare: so far changes have been strongly discouraged.

An example to consider: some binary formats have flags (arrays) or version
(jsonb) field. We should explicitly say that clients must reject any unknown
bits/versions that they do not know about. This guarantees they detect small
format updates instead of silently accepting then and possibly returning
corrupt data.

My motivation:

Two years ago accidentally I opened a discussion on how to do updates to the
binary encoding of data in the protocol [1]. I would like to reopen the
discussion now since the jsonb 'binary' encoding is just a version '1' +
text json. The result from the last discussion was that having a version or
flags as part of the binary format is not enough, since drivers/libraries
(fixable) and applications (unfixable) are depending on the current
encoding.
And if we add a new bit to the flags or bump the version number we will
break backward compatibility.

To summarize the previous discussion:
- there are currently no written rules for modifying the binary encoding
formats
- bytea modification was done with a GUC, but GUC was seen as a bad solution
in general
- my proposal was to add a minor format version number was not good either
since any per session state would be problematic for connection poolers

[1]:
http://grokbase.com/t/postgresql/pgsql-hackers/11bwhv1esa/add-minor-version-to-v3-protocol-to-allow-changes-without-breaking-backwards-compatibility

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

49 matches

Mail list logo